Skip to main content
Glama
SmartBear

SmartBear MCP server

Official
by SmartBear

QMetry: Fetch Builds

qmetry_fetch_builds
Read-onlyIdempotent

Fetch builds from a QMetry project with pagination and filters for test execution planning, reporting, and CI/CD integration.

Instructions

Fetch QMetry builds from the current project

Toolset: Projects

Parameters:

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

  • baseUrl (string): The base URL for the QMetry instance (must be a valid URL)

  • 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)

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

Output Description: JSON object with builds list and pagination metadata

Use Cases: 1. Fetch all from the current project 2. Fetch all available builds for test execution planning 3. Get build metadata for test run assignments 4. List builds for reporting and analytics 5. Filter builds by name or archive status 6. Get paginated build results for large projects 7. Retrieve build information for CI/CD integration 8. Search for specific builds using filters 9. Get build details for test execution history

Examples:

  1. Get all builds (default behavior)

{}

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

  1. Get builds with custom pagination

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

Expected Output: List of builds with custom pagination settings

  1. Filter builds by name

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

Expected Output: Filtered list of builds matching the name criteria

  1. Filter builds by archive status

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

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

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. Common filter fields: 'name' (string), 'isArchived' (list of 0,1) 5. Empty payload {} is sent when no parameters are provided 6. Builds are also known as 'drops' in QMetry terminology 7. Use builds for associating test executions with specific software versions

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number to return (starts from 1)
limitNoNumber of records (default 10).
startNoStart index for pagination - defaults to 0
filterNoFilter criteria as JSON string (default '[]')[]
baseUrlNoThe base URL for the QMetry instance (must be a valid URL)
projectKeyNoProject key - unique identifier for the projectdefault
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it returns a JSON object with builds list and pagination metadata, and notes that builds are also known as 'drops'. No contradictions with annotations.

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 quite verbose, containing a long list of use cases (9 items), 4 examples with JSON, and 7 hints. While examples are helpful, the overall length is excessive for the tool's simplicity. It could be streamlined. The use cases list is redundant and not necessary.

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 a simple fetch operation. The description explains pagination, filtering, and output format vaguely. No output schema is provided, so the description only says 'JSON object with builds list and pagination metadata'. For a simple tool, this is adequate but not highly detailed. The examples help, but more specifics on output structure 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 coverage is 100%, meaning all 6 parameters have descriptions in the schema. The description repeats parameter info but adds default values and example usage in the 'Examples' section. It provides some extra context (e.g., filter as JSON string) but not significant new semantics 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 'Fetch QMetry builds from the current project', with a specific verb and resource. Among many qmetry_* sibling tools, this one is uniquely for builds, so it distinguishes well.

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 lists multiple use cases (e.g., 'Fetch all from the current project', 'Get build metadata for test run assignments'), which imply usage scenarios. However, it does not explicitly state when not to use this tool or mention alternatives. The hints provide some guidance but no exclusions.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

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

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

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