Skip to main content
Glama
SmartBear

SmartBear MCP server

Official
by SmartBear
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Hybrid

QMetry: Fetch Issue Details

qmetry_fetch_issue_details
Read-onlyIdempotent

Fetch complete QMetry issue details, including all UDF field values, by defect ID to inspect custom fields before updating.

Instructions

Fetch full detail data for a QMetry issue including UDF field values

Toolset: Issues

Parameters:

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

  • defectId (number) required: Issue DefectId (numeric ID) — use data[].id from Fetch Issues/Defects response. The field in the list API response is named 'id', not 'DefectId'.

Output Description: JSON object with data property containing full issue details including UDFTypeData map and all UDF field values

Use Cases: 1. Get UDF field values for a specific issue 2. Retrieve full issue metadata including custom fields 3. Inspect issue details before updating UDF values

Examples:

  1. Fetch details for issue with DefectId 1430676

{
  "defectId": 1430676
}

Expected Output: Full issue detail object with UDFTypeData map and all UDF field values including MUL1, TCR_STR, etc.

Hints: 1. CRITICAL: Use 'data[].id' from Fetch Issues/Defects response as 'defectId'. The list API response field is named 'id' — there is no 'DefectId' field in the list response. Do NOT guess or derive defectId from the entity key suffix. 2. AUTO-RESOLVE: If user provides an issue entity key (e.g. VKMCP2-IS-1, MAC-IS-10), first call Fetch Defects or Issues with filter '[{"type":"string","value":"VKMCP2-IS-1","field":"entityKeyId"}]', then use 'data[].id' as defectId. 3. UDF VALUES: Response includes a 'UDFTypeData' map with all UDF field values for the issue. 4. WORKFLOW: To fetch issue UDF values — (1) Fetch Issues with entityKey filter → get data[0].id, (2) in parallel Fetch UDF Layout entityType='IS' pageName='DETAIL' → get field labels/types, (3) call this tool with defectId=data[0].id → read UDFTypeData.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
defectIdYesIssue DefectId (numeric ID) — use data[<index>].id from Fetch Issues/Defects response. The field in the list API response is named 'id', not 'DefectId'.
projectKeyNoProject key - unique identifier for the projectdefault

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changedv0.40.0
    • removedInput schema / properties / baseUrl
      Removed value: -{
-  "description": "The base URL for the QMetry instance (must be a valid URL)",
-  "format": "uri",
-  "type": "string"
-}
  2. Addedv0.37.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: the response shape (JSON object with data property), the presence of a UDFTypeData map, and the important warning that DefectId must be sourced from data[<index>].id rather than guessed from entity keys.

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 long but well-structured with clear sections (Toolset, Parameters, Output, Use Cases, Examples, Hints). The critical disambiguation information justifies the length, though some points like UDFTypeData are repeated more than necessary.

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?

With no output schema, the description's output description fills that gap. It covers the key parameter, workflow, example invocation, expected output shape, and the entity-key resolution path. For a two-parameter read-only tool with strong annotations, this is complete enough for an agent to call it correctly.

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?

Even though schema coverage is 100%, the description adds substantial meaning: it explains the critical source of defectId, warns against deriving it from the entity key suffix, provides an AUTO-RESOLVE workflow for entity keys, and gives a concrete example. This goes well beyond the schema's 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 opens with a specific verb and resource: 'Fetch full detail data for a QMetry issue including UDF field values.' This clearly distinguishes the tool from list-oriented siblings like qmetry_fetch_defects_or_issues and mutation tools like qmetry_update_issue, while also signaling it is single-issue detail retrieval.

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 use cases ('Get UDF field values', 'Retrieve full issue metadata', 'Inspect issue details before updating') and a detailed workflow for resolving entity keys. It does not explicitly name alternatives to avoid, but the context and workflow make the intended usage clear.

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