Skip to main content
Glama
SmartBear

SmartBear MCP server

Official
by SmartBear

QMetry: Fetch QMetry list Projects

qmetry_fetch_qmetry_list_projects
Read-onlyIdempotent

Retrieve available QMetry projects with IDs, keys, archive status, and view IDs to validate access and prepare data for other operations.

Instructions

Fetch QMetry projects list including projectID, name, projectKey, isArchived, viewIds and folderPath needed for other operations

Toolset: Projects

Parameters:

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

  • params (object) required

  • 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 containing list of projects details, including Version, Build Number(if greater than or equal to 1), Project ID, name, Project Key and Date Format

Use Cases: 1. Get project list to check user how many project access to particular apikey 2. Retrieve available fields of each project list including projectID, name, projectKey, isArchived, viewIds and folderPath needed for other operations 3. Validate project access and permissions

Examples:

  1. Get list of project available to user

{
  "params": {
    "showArchive": false
  }
}

Expected Output: Project active/non archived list including some important fields like projectID, name, projectKey, isArchived, viewIds and folderPath needed for other operations

  1. Get projects with custom pagination

{
  "params": {
    "showArchive": false
  },
  "page": 1,
  "limit": 10,
  "start": 0
}

Expected Output: List of projects with custom pagination settings

  1. Get not active/archived projects

{
  "params": {
    "showArchive": true
  }
}

Expected Output: List of all projects including archived ones (showArchive: true sent in payload)

  1. Filter projects by name

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

Expected Output: Filtered list of projects matching the name criteria

  1. Filter projects by project key

{
  "filter": "[{\"value\":\"MAC\",\"type\":\"string\",\"field\":\"projectKey\"}]"
}

Expected Output: List of projects filtered by project key (e.g. 'MAC', 'UT', etc.)

Hints: 1. Fetch list of projects available to user 2. Use 'default' project key when user doesn't specify one 3. Use params.showArchive: true/false to get archived/non-archived projects, default is false when not provided 4. Pagination supported for large result sets (start, page, limit parameters) 5. Filter parameter should be a JSON string with filter criteria 6. Common filter fields: 'name' (string), 'projectKey' (string)

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 '[]')[]
paramsYes
projectKeyNoProject key - unique identifier for the projectdefault
Install Server

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the read-only safety profile is covered. The description adds meaningful context beyond that: showArchive behavior, pagination semantics, filter-as-JSON-string, projectKey defaulting, and approximate output fields. There is a minor inconsistency between the fields listed in the opening line and the Output Description, but overall the behavioral picture is strong.

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 longer than average, but it is well structured with Parameters, Output Description, Use Cases, Examples, and Hints sections. It is front-loaded with the core purpose. There is some redundancy between the parameter list, examples, and hints, but the organization makes the length manageable for an agent.

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?

There is no output schema, so the description compensates with an Output Description, expected-output examples, and hints about filtering and pagination. It covers the main things an agent needs to call this tool correctly. The slight mismatch between the opening field list and Output Description prevents a perfect score.

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 description coverage is 83%, so the schema already documents most parameters well. The description adds value by giving concrete examples of filter payloads, clarifying showArchive true/false behavior, and explaining how start/page/limit work together. This goes beyond the schema without needing to restate everything.

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 projects list', and enumerates the exact fields returned (projectID, name, projectKey, isArchived, viewIds, folderPath). This clearly separates it from sibling tools like qmetry_fetch_qmetry_project_info and qtm4j_get_projects, which are singular/context-setting operations rather than project-list fetches.

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 concrete contexts: checking how many projects an API key can access, retrieving project fields needed for other operations, and validating project access/permissions. This is clear usage context, though it does not explicitly name alternatives or state when not to use this tool, so it stops short of a 5.

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