Skip to main content
Glama

Fixter

by dev.fixter.mcp
OverviewDiscussionsAdmin

List API Tests

list_api_tests
Read-onlyIdempotent

List your API tests one page at a time, each with its current configuration and health state (UP, DOWN, RATE_LIMITED or PAUSED) and consecutive-failure count. Use this to see what is being watched. For MCP tests, 'currentRevision' is the protocol revision the latest run spoke; null until the first run. RATE_LIMITED means the target is rate limiting the monitor (HTTP 429), not that it is down; the fix is on the customer's side (allowlist the Fixter prober). The result is a page, not the full list: 'apiTests' holds at most 'size' tests (default 50, max 200), 'totalElements' is how many tests match the filters in total, and 'page' is the zero-based page you got. Fetch page+1 until page*size+apiTests.length reaches totalElements. 'upCount', 'downCount', 'rateLimitedCount' and 'pausedCount' always cover all of your tests regardless of filters or paging. Narrow with 'search' (name contains, case-insensitive) and/or 'state' instead of paging through everything when you are looking for specific tests or only for failing ones.

Input Schema

NameRequiredDescriptionDefault
pageNoZero-based page number. Omit or 0 for the first page.
sizeNoTests per page, 1-200. Omit for 50.
stateNoOnly tests currently in this health state: 'UP', 'DOWN', 'RATE_LIMITED' or 'PAUSED'. Omit for all states.
searchNoOnly tests whose name contains this text (case-insensitive). Omit for all names.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / state / description
      Previous value: -"Only tests currently in this health state: 'UP', 'DOWN' or 'PAUSED'. Omit for all states."New value: +"Only tests currently in this health state: 'UP', 'DOWN', 'RATE_LIMITED' or 'PAUSED'. Omit for all states."
  2. Changed4 schema fields changed
    • addedInput schema / $schema
      Added value: +"https://json-schema.org/draft/2020-12/schema"
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / page / format
      Added value: +"int32"
    • addedInput schema / properties / size / format
      Added value: +"int32"
  3. Changed4 schema fields changed
    • addedInput schema / properties / page
      Added value: +{
+  "description": "Zero-based page number. Omit or 0 for the first page.",
+  "type": "integer"
+}
    • addedInput schema / properties / search
      Added value: +{
+  "description": "Only tests whose name contains this text (case-insensitive). Omit for all names.",
+  "type": "string"
+}
    • addedInput schema / properties / size
      Added value: +{
+  "description": "Tests per page, 1-200. Omit for 50.",
+  "type": "integer"
+}
    • addedInput schema / properties / state
      Added value: +{
+  "description": "Only tests currently in this health state: 'UP', 'DOWN' or 'PAUSED'. Omit for all states.",
+  "type": "string"
+}
  4. Added
  5. Removed
  6. Added

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already declare a safe read, and the description goes well beyond them: it explains that results are a page not the full list, that the count fields always cover all tests regardless of filters or paging, that 'currentRevision' is null until the first MCP run, and that RATE_LIMITED means the target throttled the prober rather than being down. That is exactly the interpretive context an agent needs.

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?

It is dense but front-loaded: purpose first, then state semantics, then pagination mechanics, then filtering advice. A few clauses restate schema defaults (size, page) and could be trimmed, but almost every sentence carries information the agent would otherwise have to guess.

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?

There is no output schema, and the description fully covers the return shape ('apiTests', 'totalElements', 'page', the four aggregate counters) and how to iterate pages to completion. Nothing an agent needs to call this correctly is missing.

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%, so baseline is 3, but the description adds real meaning: the default 50 / max 200 sizing, the zero-based paging loop termination condition, and that 'search' is a case-insensitive name-contains plus combinable with 'state'. It slightly restates the schema's defaults but adds the interaction 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?

States a specific verb+resource ('List your API tests') plus the scope (paged, with configuration and health state), which is clearly distinct from the sibling get_api_test. It never names a sibling explicitly, so the differentiation is inferred from the paged-list framing rather than stated.

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?

Gives concrete guidance: 'Use this to see what is being watched' and 'Narrow with search and/or state instead of paging through everything when you are looking for specific tests or only for failing ones.' It covers when to filter vs. page, but offers no explicit alternative such as get_api_test for a single test's detail.

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

All Fixter toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources