Skip to main content
Glama
SmartBear

SmartBear MCP server

Official
by SmartBear

QMetry: Fetch Platforms

qmetry_fetch_platforms
Read-onlyIdempotent

Retrieve QMetry platform records from a project, using filters, sorting, and pagination, to get metadata for test execution planning and environment selection.

Instructions

Fetch QMetry platforms from the current project

Toolset: Projects

Parameters:

  • projectKey (string): Project key - unique identifier for the project (default: "default")

  • start (number): Start index for pagination - defaults to 0 (default: 0)

  • page (number): Page number to return (starts from 1) (default: 1)

  • limit (number): Number of records (default 10). (default: 10)

  • sort (string): Sort criteria as JSON string (default '[{"property":"platformID","direction":"DESC"}]') (default: "[{"property":"platformID","direction":"DESC"}]")

  • filter (string): Filter criteria as JSON string (default '[]') (default: "[]")

Output Description: JSON object with platforms list and pagination metadata

Use Cases: 1. Fetch all platforms from the current project 2. Get platform metadata for test execution planning 3. List platforms for test environment selection 4. Filter platforms by name or properties 5. Get paginated platform results for large projects 6. Retrieve platform information for cross-platform testing 7. Search for specific platforms using filters 8. Get platform details for test execution assignment

Examples:

  1. Get all platforms (default behavior)

{}

Expected Output: List of all platforms with default pagination (10 items per page)

  1. Get platforms with custom pagination

{
  "page": 1,
  "limit": 10,
  "start": 0
}

Expected Output: List of platforms with custom pagination settings

  1. Filter platforms by name

{
  "filter": "[{\"value\":\"Chrome\",\"type\":\"string\",\"field\":\"name\"}]"
}

Expected Output: Filtered list of platforms matching the name criteria

  1. Filter platforms by archive status

{
  "filter": "[{\"value\":[1,0],\"type\":\"list\",\"field\":\"isArchived\"}]"
}

Expected Output: List of platforms filtered by archive status (archived and non-archived)

  1. Get only archived platforms

{
  "filter": "[{\"value\":[1],\"type\":\"list\",\"field\":\"isArchived\"}]"
}

Expected Output: List of only archived platforms

  1. Get only active/non-archived platforms

{
  "filter": "[{\"value\":[0],\"type\":\"list\",\"field\":\"isArchived\"}]"
}

Expected Output: List of only active/non-archived platforms

  1. Get platforms with custom sorting

{
  "sort": "[{\"property\":\"name\",\"direction\":\"ASC\"}]"
}

Expected Output: List of platforms sorted by name in ascending order

Hints: 1. Use 'default' project key when user doesn't specify one 2. Default pagination: start=0, page=1, limit=10 3. Filter parameter should be a JSON string with filter criteria 4. Sort parameter should be a JSON string with sort criteria 5. Default sort: platformID descending 6. Common filter fields: 'name' (string), 'isArchived' (list of 0,1) for archive status 7. IMPORTANT: Always use 'isArchived' field for filtering by archive status, even though response shows 'isPlatformArchived' 8. Archive status values: 0 = active/non-archived, 1 = archived 9. Empty payload {} is sent when no parameters are provided 10. Use platforms for cross-platform testing and environment selection

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number to return (starts from 1)
sortNoSort criteria as JSON string (default '[{"property":"platformID","direction":"DESC"}]')[{"property":"platformID","direction":"DESC"}]
limitNoNumber of records (default 10).
startNoStart index for pagination - defaults to 0
filterNoFilter criteria as JSON string (default '[]')[]
projectKeyNoProject key - unique identifier for the projectdefault
Install Server

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already indicate readOnly, idempotent, and non-destructive behavior, and the description adds substantial behavioral context: default project key, default pagination, default sort order, JSON-string filter/sort syntax, and the important gotcha that filtering must use 'isArchived' even though responses show 'isPlatformArchived'. It also clarifies archive status value meanings.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is heavily over-long and repetitive: parameter defaults are restated from the schema, eight overlapping use cases are listed, seven examples cover mostly the same scenarios, and ten hints repeat earlier information. It is well-sectioned, but many sentences do not earn their place.

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?

Despite lacking an output schema, the description provides enough through its output description, examples, and hints: expected output shape, pagination behavior, filtering patterns, archive-status handling, and default behavior. An agent can confidently select and call this tool without external lookups.

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

Parameters5/5

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

Though the schema already documents all six parameters with 100% coverage, the description adds significant practical meaning beyond it: concrete JSON examples for filter and sort, common filter fields, archive status semantics, and the empty-payload convention for defaults. This is exactly the kind of extra guidance agents need to invoke it correctly.

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 opens with a specific verb and resource: 'Fetch QMetry platforms from the current project.' It clearly distinguishes this tool from sibling fetch tools (releases, builds, test cases) by naming the exact resource and 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?

The 'Use Cases' section gives clear context for when to call this tool, such as fetching all platforms, filtering by name or archive status, and retrieving paginated results. It does not explicitly name alternatives or exclusions, but the fetch-versus-link sibling tools are distinct enough that the intended usage is unambiguous.

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

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/SmartBear/smartbear-mcp'

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