@smartbear/mcp 0.8.0 → 0.10.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (66) hide show
  1. package/README.md +29 -4
  2. package/dist/api-hub/client/api.js +239 -10
  3. package/dist/api-hub/client/configuration.js +5 -0
  4. package/dist/api-hub/client/index.js +1 -0
  5. package/dist/api-hub/client/portal-types.js +126 -0
  6. package/dist/api-hub/client/registry-types.js +8 -0
  7. package/dist/api-hub/client/tools.js +78 -15
  8. package/dist/api-hub/client/user-management-types.js +24 -0
  9. package/dist/api-hub/client.js +34 -0
  10. package/dist/bugsnag/client/api/CurrentUser.js +12 -49
  11. package/dist/bugsnag/client/api/Error.js +29 -142
  12. package/dist/bugsnag/client/api/Project.js +52 -113
  13. package/dist/bugsnag/client/api/api.js +3743 -0
  14. package/dist/bugsnag/client/api/base.js +97 -34
  15. package/dist/bugsnag/client/api/configuration.js +26 -0
  16. package/dist/bugsnag/client/api/index.js +2 -0
  17. package/dist/bugsnag/client/filters.js +28 -0
  18. package/dist/bugsnag/client.js +104 -155
  19. package/dist/collaborator/client.js +364 -0
  20. package/dist/common/server.js +73 -23
  21. package/dist/common/types.js +6 -1
  22. package/dist/index.js +9 -1
  23. package/dist/pactflow/client/prompt-utils.js +2 -1
  24. package/dist/pactflow/client/tools.js +4 -4
  25. package/dist/pactflow/client/utils.js +5 -4
  26. package/dist/pactflow/client.js +10 -9
  27. package/dist/qmetry/client/api/client-api.js +21 -16
  28. package/dist/qmetry/client/api/error-handler.js +329 -0
  29. package/dist/qmetry/client/auto-resolve.js +96 -0
  30. package/dist/qmetry/client/handlers.js +33 -2
  31. package/dist/qmetry/client/issues.js +123 -0
  32. package/dist/qmetry/client/project.js +73 -0
  33. package/dist/qmetry/client/requirement.js +76 -0
  34. package/dist/qmetry/client/testcase.js +122 -6
  35. package/dist/qmetry/client/testsuite.js +272 -0
  36. package/dist/qmetry/client/tools/index.js +17 -0
  37. package/dist/qmetry/client/tools/issue-tools.js +545 -0
  38. package/dist/qmetry/client/tools/project-tools.js +348 -0
  39. package/dist/qmetry/client/tools/requirement-tools.js +530 -0
  40. package/dist/qmetry/client/tools/testcase-tools.js +526 -0
  41. package/dist/qmetry/client/tools/testsuite-tools.js +772 -0
  42. package/dist/qmetry/client/tools/types.js +1 -0
  43. package/dist/qmetry/client/utils.js +16 -0
  44. package/dist/qmetry/client.js +27 -17
  45. package/dist/qmetry/config/constants.js +28 -0
  46. package/dist/qmetry/config/rest-endpoints.js +30 -0
  47. package/dist/qmetry/types/common.js +599 -9
  48. package/dist/qmetry/types/issues.js +16 -0
  49. package/dist/qmetry/types/project.js +17 -0
  50. package/dist/qmetry/types/requirements.js +19 -0
  51. package/dist/qmetry/types/testcase.js +20 -0
  52. package/dist/qmetry/types/testsuite.js +44 -0
  53. package/dist/reflect/client.js +7 -6
  54. package/dist/zephyr/client.js +7 -1
  55. package/dist/zephyr/common/api-client.js +8 -0
  56. package/dist/zephyr/common/auth-service.js +1 -0
  57. package/dist/zephyr/common/rest-api-schemas.js +5173 -0
  58. package/dist/zephyr/tool/project/get-project.js +39 -0
  59. package/dist/zephyr/tool/project/get-projects.js +7 -13
  60. package/dist/zephyr/tool/test-cycle/get-test-cycles.js +72 -0
  61. package/package.json +1 -1
  62. package/dist/bugsnag/client/api/filters.js +0 -167
  63. package/dist/bugsnag/client/configuration.js +0 -10
  64. package/dist/bugsnag/client/index.js +0 -2
  65. package/dist/qmetry/client/tools.js +0 -222
  66. package/dist/zephyr/common/types.js +0 -35
@@ -0,0 +1,526 @@
1
+ import { QMetryToolsHandlers } from "../../config/constants.js";
2
+ import { CreateTestCaseArgsSchema, TestCaseDetailsArgsSchema, TestCaseExecutionsArgsSchema, TestCaseListArgsSchema, TestCaseStepsArgsSchema, TestCaseVersionDetailsArgsSchema, UpdateTestCaseArgsSchema, } from "../../types/common.js";
3
+ export const TESTCASE_TOOLS = [
4
+ {
5
+ title: "Create Test Case",
6
+ summary: "Create a new test case in QMetry with steps, metadata, and release/cycle mapping.",
7
+ handler: QMetryToolsHandlers.CREATE_TEST_CASE,
8
+ inputSchema: CreateTestCaseArgsSchema,
9
+ purpose: "Allows users to create a new test case in QMetry, including steps, custom fields, and release/cycle mapping. " +
10
+ "Supports all major test case fields and step-level UDFs. " +
11
+ "For fields like priority, owner, component, etc., fetch their valid values using the project info tool. " +
12
+ "If tcFolderID is not provided, it will be auto-resolved to the root test case folder using project info.",
13
+ useCases: [
14
+ "Create a basic test case with just a name and folder",
15
+ "Add detailed steps with custom fields (UDFs) to a test case",
16
+ "Associate test case with specific release/cycle for planning",
17
+ "Set priority, owner, component, and other metadata using valid IDs from project info",
18
+ "Create test cases for automation or manual testing types",
19
+ "Add test case to a specific folder using tcFolderID",
20
+ "Include estimated execution time and description",
21
+ "Map test case to multiple cycles/releases",
22
+ ],
23
+ examples: [
24
+ {
25
+ description: "Create a test case in the root folder (auto-resolved)",
26
+ parameters: {
27
+ name: "Login Test Case",
28
+ },
29
+ expectedOutput: "Test case created in the root test case folder with ID and summary details",
30
+ },
31
+ {
32
+ description: "Create a simple test case in folder 102653",
33
+ parameters: {
34
+ tcFolderID: "102653",
35
+ name: "Login Test Case",
36
+ },
37
+ expectedOutput: "Test case created with ID and summary details",
38
+ },
39
+ {
40
+ description: "Create a test case with steps and metadata",
41
+ parameters: {
42
+ tcFolderID: "102653",
43
+ name: "Test Case 1",
44
+ steps: [
45
+ {
46
+ orderId: 1,
47
+ description: "First Step",
48
+ inputData: "First Data",
49
+ expectedOutcome: "First Outcome",
50
+ UDF: {
51
+ customField1: "Custom Field Data A",
52
+ customField2: "Custom Field Data B",
53
+ },
54
+ },
55
+ ],
56
+ priority: 2025268,
57
+ component: [2025328],
58
+ testcaseOwner: 1467,
59
+ testCaseState: 2025271,
60
+ testCaseType: 2025282,
61
+ estimatedTime: 10,
62
+ description: "Description",
63
+ testingType: 2025275,
64
+ associateRelCyc: true,
65
+ releaseCycleMapping: [
66
+ {
67
+ release: 14239,
68
+ cycle: [21395],
69
+ version: 1,
70
+ },
71
+ ],
72
+ },
73
+ expectedOutput: "Test case created with steps and metadata",
74
+ },
75
+ ],
76
+ hints: [
77
+ "If tcFolderID is not provided, it will be auto-resolved to the root test case folder using project info (rootFolders.TC.id).",
78
+ "To get valid values for priority, owner, component, etc., call the project info tool and use the returned customListObjs IDs.",
79
+ "If the user provides a priority name (e.g. 'Blocker'), fetch project info, find the matching priority in customListObjs.priority[index].name, and use its ID in the payload. If the name is not found, skip the priority field (it is not required) and show a user-friendly message: 'Test case created without priority, as given priority is not available in the current project.'",
80
+ "If the user provides a component name, fetch project info, find the matching component in customListObjs.component[index].name, and use its ID in the payload. If the name is not found, skip the component field (it is not required) and show a user-friendly message: 'Test case created without component, as given component is not available in the current project.'",
81
+ "If the user provides an owner name, fetch project info, find the matching owner in customListObjs.owner[index].name, and use its ID in the payload as testcaseOwner. If the name is not found, skip the testcaseOwner field (it is not required) and show a user-friendly message: 'Test case created without owner, as given owner is not available in the current project.'",
82
+ "If the user provides a test case state name, fetch project info, find the matching state in customListObjs.testCaseState[index].name, and use its ID in the payload as testCaseState. If the name is not found, skip the testCaseState field (it is not required) and show a user-friendly message: 'Test case created without test case state, as given state is not available in the current project.'",
83
+ "If the user provides a test case type name, fetch project info, find the matching type in customListObjs.testCaseType[index].name, and use its ID in the payload as testCaseType. If the name is not found, skip the testCaseType field (it is not required) and show a user-friendly message: 'Test case created without test case type, as given type is not available in the current project.'",
84
+ "If the user provides a testing type name, fetch project info, find the matching type in customListObjs.testingType[index].name, and use its ID in the payload as testingType. If the name is not found, skip the testingType field (it is not required) and show a user-friendly message: 'Test case created without testing type, as given testing type is not available in the current project.'",
85
+ "Example: If user says 'Create test case with title \"High priority test case\" and set priority to \"Blocker\"', first call project info, map 'Blocker' to its ID, and use that ID for the priority field in the create payload. If user says 'set priority to \"Urgent\"' and 'Urgent' is not found, skip the priority field and show: 'Test case created without priority, as given priority is not available in the current project.'",
86
+ "tcFolderID is required; use the root folder ID from project info or a specific folder.",
87
+ "Steps are optional but recommended for manual test cases.",
88
+ "If the user provides a prompt like 'create test case with steps as step 1 - Go to login page, step 2 - give credential, step 3 - go to test case page, step 4 - create test case', LLM should parse each step and convert it into the steps payload array, mapping each step to an object with orderId, description, and optionally inputData and expectedOutcome.",
89
+ "Example mapping: 'step 1 - Go to login page' → { orderId: 1, description: 'Go to login page' }.",
90
+ "LLM should increment orderId for each step, use the step text as description, and optionally infer inputData/expectedOutcome if provided in the prompt.",
91
+ "Demo steps payload: steps: [ { orderId: 1, description: 'First Step', inputData: 'First Data', expectedOutcome: 'First Outcome', UDF: { customField1: 'Custom Field Data A', customField2: 'Custom Field Data B' } }, ... ]",
92
+ "UDF fields in steps must match your QMetry custom field configuration.",
93
+ "Release/cycle mapping is optional but useful for planning.",
94
+ "If the user wants to link or associate a release and cycle to the test case, set associateRelCyc: true in the payload.",
95
+ "If the user provides a release ID, map it from projects.releases[index].releaseID in the project info response, and use that ID in releaseCycleMapping.",
96
+ "If the user provides both release and cycle IDs, validate both against the current project's releases and cycles; if valid, use them in releaseCycleMapping.",
97
+ "When adding releaseCycleMapping, always include the 'version' field (usually set to 1) in each mapping object. The correct format is: { release: <releaseID>, cycle: [<cycleID>], version: 1 }. If 'version' is missing, the request will fail.",
98
+ "If the user provides a release name, map it to its ID from project info; if a cycle name is provided, map it to its ID from the associated release's builds list.",
99
+ "Example payload: releaseCycleMapping: [ { release: <releaseID>, cycle: [<cycleID>], version: 1 } ]",
100
+ "LLM should ensure that provided release/cycle names or IDs exist in the current project before using them in the payload. If not found, skip and show a user-friendly message: 'Test case created without release/cycle association, as given release/cycle is not available in the current project.'",
101
+ "All IDs (priority, owner, etc.) must be valid for your QMetry instance.",
102
+ "If a custom field is mandatory, include it in the UDF object.",
103
+ "Estimated time is in minutes.",
104
+ "Description and testingType are optional but recommended for clarity.",
105
+ ],
106
+ outputDescription: "JSON object containing the new test case ID, summary, and creation metadata.",
107
+ readOnly: false,
108
+ idempotent: false,
109
+ },
110
+ {
111
+ title: "Update Test Case",
112
+ summary: "Update an existing QMetry test case by tcID and tcVersionID, with auto-resolution from entityKey.",
113
+ handler: QMetryToolsHandlers.UPDATE_TEST_CASE,
114
+ inputSchema: UpdateTestCaseArgsSchema,
115
+ purpose: "Update a QMetry test case's metadata, steps, or other fields. " +
116
+ "Requires tcID and tcVersionID, which can be auto-resolved from the test case entityKey using the test case list and version detail tools. " +
117
+ "Supports updating summary, priority, owner, component, state, type, description, steps, and more. Only fields provided will be updated.",
118
+ useCases: [
119
+ "Update test case summary (name)",
120
+ "Change priority, owner, or state of a test case",
121
+ "Edit, add, or remove test steps",
122
+ "Update only metadata (no steps)",
123
+ "Bulk update using entityKey auto-resolution",
124
+ "Modify test case description or estimated time",
125
+ "Change test case type or component",
126
+ "Update testing type or custom fields",
127
+ "Update, add and remove test case steps",
128
+ ],
129
+ examples: [
130
+ {
131
+ description: "Update test case summary (updated name)",
132
+ parameters: {
133
+ tcID: 4519260,
134
+ tcVersionID: 5448492,
135
+ name: "MAC Test11",
136
+ },
137
+ expectedOutput: "Test case summary updated. tcID and tcVersionID auto-resolved from entityKey. Only 'name' field changed.",
138
+ },
139
+ {
140
+ description: "Update priority to High and owner to john.doe",
141
+ parameters: {
142
+ tcID: 4519260,
143
+ tcVersionID: 5448492,
144
+ priority: 505015,
145
+ testcaseOwner: 6963,
146
+ },
147
+ expectedOutput: "Priority and owner updated. Field IDs auto-resolved from project info. tcID/tcVersionID resolved from entityKey.",
148
+ },
149
+ {
150
+ description: "Update steps (edit, add, remove)",
151
+ parameters: {
152
+ tcID: 4519260,
153
+ tcVersionID: 5448492,
154
+ steps: [
155
+ {
156
+ orderId: 1,
157
+ description: "Step 22",
158
+ inputData: "Input 22",
159
+ expectedOutcome: "Outcome 22",
160
+ tcStepID: 3014032,
161
+ },
162
+ {
163
+ orderId: 2,
164
+ description: "Step3",
165
+ inputData: "Input 3",
166
+ expectedOutcome: "Outcome 3",
167
+ },
168
+ ],
169
+ removeSteps: [
170
+ { tcStepID: 3014031, description: "Step 1", orderId: 1 },
171
+ ],
172
+ isStepUpdated: true,
173
+ },
174
+ expectedOutput: "Steps updated: Step 22 edited, Step3 added, Step 1 removed. tcID/tcVersionID auto-resolved.",
175
+ },
176
+ {
177
+ description: "Update only metadata (no steps)",
178
+ parameters: {
179
+ tcID: 4519260,
180
+ tcVersionID: 5448492,
181
+ updateOnlyMetadata: true,
182
+ name: "New Name",
183
+ },
184
+ expectedOutput: "Metadata updated only. Steps unchanged. tcID/tcVersionID auto-resolved.",
185
+ },
186
+ ],
187
+ hints: [
188
+ "If user provides entityKey (e.g., MAC-TC-1684), first call FETCH_TEST_CASES with a filter on entityKeyId to resolve the tcID and tcVersionID.",
189
+ "To get valid values for priority, owner, component, etc., call the project info tool and use the returned customListObjs IDs.",
190
+ "If the user provides a priority name (e.g. 'Blocker'), fetch project info, find the matching priority in customListObjs.priority[index].name, and use its ID in the payload. If the name is not found, skip the priority field (it is not required) and show a user-friendly message: 'Test case updated without priority, as given priority is not available in the current project.'",
191
+ "If the user provides a component name, fetch project info, find the matching component in customListObjs.component[index].name, and use its ID in the payload. If the name is not found, skip the component field (it is not required) and show a user-friendly message: 'Test case updated without component, as given component is not available in the current project.'",
192
+ "If the user provides an owner name, fetch project info, find the matching owner in customListObjs.owner[index].name, and use its ID in the payload as testcaseOwner. If the name is not found, skip the testcaseOwner field (it is not required) and show a user-friendly message: 'Test case updated without owner, as given owner is not available in the current project.'",
193
+ "If the user provides a test case state name, fetch project info, find the matching state in customListObjs.testCaseState[index].name, and use its ID in the payload as testCaseState. If the name is not found, skip the testCaseState field (it is not required) and show a user-friendly message: 'Test case updated without test case state, as given state is not available in the current project.'",
194
+ "If the user provides a test case type name, fetch project info, find the matching type in customListObjs.testCaseType[index].name, and use its ID in the payload as testCaseType. If the name is not found, skip the testCaseType field (it is not required) and show a user-friendly message: 'Test case updated without test case type, as given type is not available in the current project.'",
195
+ "If the user provides a testing type name, fetch project info, find the matching type in customListObjs.testingType[index].name, and use its ID in the payload as testingType. If the name is not found, skip the testingType field (it is not required) and show a user-friendly message: 'Test case updated without testing type, as given testing type is not available in the current project.'",
196
+ "Example: If user says 'Update test case with title \"High priority test case\" and set priority to \"Blocker\"', first call project info, map 'Blocker' to its ID, and use that ID for the priority field in the update payload. If user says 'set priority to \"Urgent\"' and 'Urgent' is not found, skip the priority field and show: 'Test case updated without priority, as given priority is not available in the current project.'",
197
+ "To update test case steps, use the following rules:",
198
+ "- For steps to be added: omit tcStepID in the step object.",
199
+ "- For steps to be updated: include tcStepID (from the existing step) in the step object.",
200
+ "- For steps to be removed: add a full removeSteps object for each step to be deleted, matching the removeTestCaseStep interface.",
201
+ "- Always set isStepUpdated: true if steps are added, updated, or removed.",
202
+ "- Example: If user says 'Edit step 1 to say ...', find the tcStepID for step 1 and include it in the steps array with updated fields.",
203
+ "- Example: If user says 'Add a new step after step 2', add a new object to steps array with no tcStepID.",
204
+ "- Example: If user says 'Remove step 3', add the full step object to removeSteps array, including tcStepID and all required fields.",
205
+ "- The payload should look like: { steps: [...], removeSteps: [...], isStepUpdated: true }.",
206
+ "- If only metadata is updated (no steps), set updateOnlyMetadata: true and do not include steps/removeSteps.",
207
+ "- Always increment orderId for new steps and preserve order for updates.",
208
+ "- If user prompt is ambiguous, ask for clarification or show a user-friendly error.",
209
+ "Steps are optional but recommended for manual test cases.",
210
+ "If the user provides a prompt like 'update test case with steps as step 1 - Go to login page, step 2 - give credential, step 3 - go to test case page, step 4 - create test case', LLM should parse each step and convert it into the steps payload array, mapping each step to an object with orderId, description, and optionally inputData and expectedOutcome.",
211
+ "Example mapping: 'step 1 - Go to login page' → { orderId: 1, description: 'Go to login page' }.",
212
+ "LLM should increment orderId for each step, use the step text as description, and optionally infer inputData/expectedOutcome if provided in the prompt.",
213
+ "Demo steps payload: steps: [ { orderId: 1, description: 'First Step', inputData: 'First Data', expectedOutcome: 'First Outcome', UDF: { customField1: 'Custom Field Data A', customField2: 'Custom Field Data B' } }, ... ]",
214
+ "UDF fields in steps must match your QMetry custom field configuration.",
215
+ "All IDs (priority, owner, etc.) must be valid for your QMetry instance.",
216
+ "If a custom field is mandatory, include it in the UDF object.",
217
+ "executionMinutes time is in minutes.",
218
+ "Description and testingType are optional but recommended for clarity.",
219
+ ],
220
+ outputDescription: "JSON object containing the new test case ID, summary, and creation metadata.",
221
+ readOnly: false,
222
+ idempotent: false,
223
+ },
224
+ {
225
+ title: "Fetch Test Cases",
226
+ summary: "Fetch QMetry test cases - automatically handles viewId resolution based on project",
227
+ handler: QMetryToolsHandlers.FETCH_TEST_CASES,
228
+ inputSchema: TestCaseListArgsSchema,
229
+ purpose: "Get test cases from QMetry. System automatically gets correct viewId from project info if not provided.",
230
+ useCases: [
231
+ "List all test cases in a project",
232
+ "Search for specific test cases using filters",
233
+ "Browse test cases in specific folders",
234
+ "Get paginated test case results",
235
+ ],
236
+ examples: [
237
+ {
238
+ description: "Get all test cases from default project - system will auto-fetch viewId",
239
+ parameters: {},
240
+ expectedOutput: "List of test cases from default project with auto-resolved viewId",
241
+ },
242
+ {
243
+ description: "Get all test cases from UT project - system will auto-fetch UT project's viewId",
244
+ parameters: { projectKey: "UT" },
245
+ expectedOutput: "List of test cases from UT project using UT's specific TC viewId",
246
+ },
247
+ {
248
+ description: "Get test cases with manual viewId (skip auto-resolution)",
249
+ parameters: { projectKey: "MAC", viewId: 167136, folderPath: "" },
250
+ expectedOutput: "Test cases using manually specified viewId 167136",
251
+ },
252
+ {
253
+ description: "List test cases from specific project (ex: project key can be anything (VT, UT, PROJ1, TEST9)",
254
+ parameters: {
255
+ projectKey: "use specific given project key",
256
+ viewId: "fetch specific project given projectKey Test Case ViewId",
257
+ folderPath: "",
258
+ },
259
+ expectedOutput: "Test cases using manually specified viewId 167136 or projectKey",
260
+ },
261
+ {
262
+ description: "Get test cases by release/cycle filter",
263
+ parameters: {
264
+ projectKey: "MAC",
265
+ filter: '[{"value":[55178],"type":"list","field":"release"},{"value":[111577],"type":"list","field":"cycle"}]',
266
+ },
267
+ expectedOutput: "Test cases associated with Release 8.12 (ID: 55178) and Cycle 8.12.1 (ID: 111577)",
268
+ },
269
+ {
270
+ description: "Get test cases by release only",
271
+ parameters: {
272
+ projectKey: "MAC",
273
+ filter: '[{"value":[55178],"type":"list","field":"release"}]',
274
+ },
275
+ expectedOutput: "All test cases associated with Release 8.12 (ID: 55178)",
276
+ },
277
+ {
278
+ description: "Get test cases by cycle only",
279
+ parameters: {
280
+ projectKey: "MAC",
281
+ filter: '[{"value":[111577],"type":"list","field":"cycle"}]',
282
+ },
283
+ expectedOutput: "All test cases associated with Cycle 8.12.1 (ID: 111577)",
284
+ },
285
+ {
286
+ description: "Search for specific test case by entity key",
287
+ parameters: {
288
+ projectKey: "MAC",
289
+ filter: '[{"type":"string","value":"MAC-TC-1684","field":"entityKeyId"}]',
290
+ },
291
+ expectedOutput: "Test cases matching the entity key criteria",
292
+ },
293
+ {
294
+ description: "Search for multiple test cases by comma-separated entity keys",
295
+ parameters: {
296
+ projectKey: "MAC",
297
+ filter: '[{"type":"string","value":"MAC-TC-1684,MAC-TC-1685,MAC-TC-1686","field":"entityKeyId"}]',
298
+ },
299
+ expectedOutput: "Test cases matching any of the specified entity keys",
300
+ },
301
+ ],
302
+ hints: [
303
+ "CRITICAL WORKFLOW: Always use the SAME projectKey for both project info and test case fetching",
304
+ "Step 1: If user specifies projectKey (like 'UT', 'MAC'), use that EXACT projectKey for project info",
305
+ "Step 2: Get project info using that projectKey, extract latestViews.TC.viewId",
306
+ "Step 3: Use the SAME projectKey and the extracted TC viewId for fetching test cases",
307
+ "Step 4: If user doesn't specify projectKey, use 'default' for both project info and test case fetching",
308
+ "NEVER mix project keys - if user says 'MAC project', use projectKey='MAC' for everything",
309
+ 'For search by test case key (like MAC-TC-1684), use filter: \'[{"type":"string","value":"MAC-TC-1684","field":"entityKeyId"}]\'',
310
+ "RELEASE/CYCLE FILTERING: Use release and cycle IDs, not names, for filtering",
311
+ 'For release filter: \'[{"value":[releaseId],"type":"list","field":"release"}]\'',
312
+ 'For cycle filter: \'[{"value":[cycleId],"type":"list","field":"cycle"}]\'',
313
+ 'For combined release+cycle: \'[{"value":[releaseId],"type":"list","field":"release"},{"value":[cycleId],"type":"list","field":"cycle"}]\'',
314
+ "Get release/cycle IDs from FETCH_RELEASES_AND_CYCLES tool before filtering",
315
+ "FILTER FIELDS: entityKeyId, priorityAlias, createdByAlias, updatedByAlias, testCaseStateAlias, testingTypeAlias, testCaseTypeAlias, componentAlias, owner, release, cycle",
316
+ "SORT FIELDS: entityKey, name, associatedVersion, priorityAlias, createdDate, createdByAlias, updatedDate, updatedByAlias, testCaseStateAlias, testingTypeAlias, executionMinutes",
317
+ "For multiple entity keys, use comma-separated values in filter",
318
+ "Use empty string '' as folderPath for root directory",
319
+ ],
320
+ outputDescription: "JSON object with 'data' array containing test cases and pagination info",
321
+ readOnly: true,
322
+ idempotent: true,
323
+ openWorld: false,
324
+ },
325
+ {
326
+ title: "Fetch Test Case Details",
327
+ summary: "Get detailed information for a specific QMetry test case by numeric ID",
328
+ handler: QMetryToolsHandlers.FETCH_TEST_CASE_DETAILS,
329
+ inputSchema: TestCaseDetailsArgsSchema,
330
+ purpose: "Retrieve comprehensive test case information including metadata, status, and basic properties",
331
+ useCases: [
332
+ "Get test case details by numeric ID",
333
+ "Retrieve test case metadata for reporting",
334
+ "Get test case summary and properties",
335
+ "Fetch test case details before accessing steps or version details",
336
+ ],
337
+ examples: [
338
+ {
339
+ description: "Get test case details by numeric ID",
340
+ parameters: { tcID: 4468020 },
341
+ expectedOutput: "Detailed test case information including summary, description, status",
342
+ },
343
+ ],
344
+ hints: [
345
+ "This API requires a numeric tcID parameter",
346
+ "If user provides entityKey (e.g., MAC-TC-1684), first call FETCH_TEST_CASES with a filter on entityKeyId to resolve the tcID",
347
+ "After resolving entityKey → tcID, call this tool with the resolved numeric tcID",
348
+ "This tool provides metadata and properties; use FETCH_TEST_CASE_STEPS for step-level details",
349
+ ],
350
+ outputDescription: "JSON object with test case details including ID, key, summary, description, and metadata",
351
+ readOnly: true,
352
+ idempotent: true,
353
+ },
354
+ {
355
+ title: "Fetch Test Case Version Details",
356
+ summary: "Get QMetry test case details for a specific version by numeric ID",
357
+ handler: QMetryToolsHandlers.FETCH_TEST_CASE_VERSION_DETAILS,
358
+ inputSchema: TestCaseVersionDetailsArgsSchema,
359
+ purpose: "Retrieve version-specific information for a test case including history and changes",
360
+ useCases: [
361
+ "Get specific version details of a test case",
362
+ "Compare different versions of a test case",
363
+ "Retrieve version history information",
364
+ "Audit changes made across test case versions",
365
+ ],
366
+ examples: [
367
+ {
368
+ description: "Get version 2 details for test case ID 123",
369
+ parameters: { id: 123, version: 2 },
370
+ expectedOutput: "Version 2 details for test case 123",
371
+ },
372
+ ],
373
+ hints: [
374
+ "Requires numeric ID, not entityKey",
375
+ "If user provides entityKey (e.g., MAC-TC-1684), first resolve it to numeric ID using FETCH_TEST_CASES",
376
+ "Version defaults to 1 if not specified",
377
+ "Provides version-specific metadata and history",
378
+ ],
379
+ outputDescription: "JSON object with version-specific test case details",
380
+ readOnly: true,
381
+ idempotent: true,
382
+ },
383
+ {
384
+ title: "Fetch Test Case Steps",
385
+ summary: "Get detailed test case steps for a specific test case by numeric ID",
386
+ handler: QMetryToolsHandlers.FETCH_TEST_CASE_STEPS,
387
+ inputSchema: TestCaseStepsArgsSchema,
388
+ purpose: "Retrieve step-by-step instructions and expected results for manual execution of a test case",
389
+ useCases: [
390
+ "Get step-by-step instructions with expected results",
391
+ "Retrieve test case execution procedure for manual runs",
392
+ "Export or display detailed test steps for documentation",
393
+ "Fetch steps before automation mapping",
394
+ ],
395
+ examples: [
396
+ {
397
+ description: "Get steps for test case ID 123",
398
+ parameters: { id: 123 },
399
+ expectedOutput: "Detailed steps with actions and expected results for test case 123",
400
+ },
401
+ ],
402
+ hints: [
403
+ "Requires numeric ID, not entityKey",
404
+ "If user provides entityKey (e.g., MAC-TC-1684), resolve it first via FETCH_TEST_CASES to get the numeric ID",
405
+ "Version defaults to 1 if not specified",
406
+ "Use pagination for test cases with many steps",
407
+ ],
408
+ outputDescription: "JSON object with array of test steps including step description, expected result, and order",
409
+ readOnly: true,
410
+ idempotent: true,
411
+ },
412
+ {
413
+ title: "Fetch Test Case Executions",
414
+ summary: "Get execution records for a specific test case by numeric ID",
415
+ handler: QMetryToolsHandlers.FETCH_TEST_CASE_EXECUTIONS,
416
+ inputSchema: TestCaseExecutionsArgsSchema,
417
+ purpose: "Retrieve execution history and results for a specific test case. " +
418
+ "This tool provides detailed execution information including test suite names, platforms, " +
419
+ "execution status, executed by, project, release, cycle, execution date, and test case versions.",
420
+ useCases: [
421
+ "Get execution history for a specific test case",
422
+ "Retrieve test case execution results for reporting",
423
+ "Filter executions by test suite, platform, or execution status",
424
+ "Get execution data for test case analysis",
425
+ "Monitor test case execution trends over time",
426
+ "Filter executions by release, cycle, or execution date",
427
+ "Get execution details for specific test case versions",
428
+ "Audit test execution history for compliance",
429
+ "Analyze test case execution performance across different environments",
430
+ "Track test execution by specific users or teams",
431
+ ],
432
+ examples: [
433
+ {
434
+ description: "Get all executions for test case ID 1223922",
435
+ parameters: { tcid: 1223922 },
436
+ expectedOutput: "List of execution records for test case with execution details, status, and metadata",
437
+ },
438
+ {
439
+ description: "Get executions for specific test case version",
440
+ parameters: { tcid: 1223922, tcversion: 2 },
441
+ expectedOutput: "Execution records for version 2 of the test case",
442
+ },
443
+ {
444
+ description: "Filter executions by test suite and platform",
445
+ parameters: {
446
+ tcid: 1223922,
447
+ filter: '[{"value":"Sample Test Suite","type":"string","field":"testSuiteName"},{"value":[12345],"type":"list","field":"platformID"}]',
448
+ },
449
+ expectedOutput: "Filtered execution records matching test suite and platform criteria",
450
+ },
451
+ {
452
+ description: "Filter executions by execution status",
453
+ parameters: {
454
+ tcid: 1223922,
455
+ filter: '[{"value":["PASS"],"type":"list","field":"executionStatus"}]',
456
+ },
457
+ expectedOutput: "Execution records with PASS status only",
458
+ },
459
+ {
460
+ description: "Filter executions by release and cycle",
461
+ parameters: {
462
+ tcid: 1223922,
463
+ filter: '[{"value":[55178],"type":"list","field":"release"},{"value":[111577],"type":"list","field":"cycle"}]',
464
+ },
465
+ expectedOutput: "Execution records filtered by specific release and cycle",
466
+ },
467
+ {
468
+ description: "Filter executions by date range",
469
+ parameters: {
470
+ tcid: 1223922,
471
+ filter: '[{"value":"2024-01-01","type":"date","field":"executedDate","comparison":"gt"},{"value":"2024-12-31","type":"date","field":"executedDate","comparison":"lt"}]',
472
+ },
473
+ expectedOutput: "Execution records within the specified date range",
474
+ },
475
+ {
476
+ description: "Filter executions by user",
477
+ parameters: {
478
+ tcid: 1223922,
479
+ filter: '[{"value":["john.doe"],"type":"list","field":"executedBy"}]',
480
+ },
481
+ expectedOutput: "Execution records executed by specific user",
482
+ },
483
+ ],
484
+ hints: [
485
+ "This API requires a numeric tcid parameter, not entity key",
486
+ "If user provides entityKey (e.g., MAC-TC-1684), first call FETCH_TEST_CASES with filter on entityKeyId to resolve the tcid",
487
+ "After resolving entityKey → tcid, call this tool with the resolved numeric tcid",
488
+ "tcversion parameter is optional - omit to get executions for all versions",
489
+ "",
490
+ "CRITICAL WORKFLOW FOR LINKED ISSUES: When user asks 'fetch linked issues of test case [ID]' or 'linked issues of execution':",
491
+ "YOU MUST FIRST get the execution data using this tool to extract tcRunID before fetching issues!",
492
+ "",
493
+ "COMPLETE WORKFLOW FOR TEST CASE → LINKED ISSUES:",
494
+ "STEP 1: Resolve Test Case ID (if needed) - Use FETCH_TEST_CASES if user provides entity key",
495
+ "STEP 2: Fetch Test Case Executions (THIS TOOL) - Input: tcid, Extract: data[].tcRunID values",
496
+ "STEP 3: Fetch Linked Issues - Tool: FETCH_LINKED_ISSUES_BY_TESTCASE_RUN, Input: entityId = tcRunID",
497
+ "",
498
+ "ID MAPPING CRITICAL UNDERSTANDING:",
499
+ "- tcid/tcID = Test Case ID (for getting execution data with this tool)",
500
+ "- tcRunID = Test Case Run/Execution ID (THIS is entityId for linked issues API)",
501
+ "- entityId = tcRunID (what the linked issues API actually needs)",
502
+ "",
503
+ "NEVER USE tcid DIRECTLY as entityId for linked issues!",
504
+ "ALWAYS get tcRunID from executions and use THAT as entityId!",
505
+ "",
506
+ "EXAMPLE RESPONSE STRUCTURE FROM THIS TOOL:",
507
+ '{ "data": [{ "tcRunID": 58312120, "testSuiteName": "Suite 1", "executionStatus": "PASS" }] }',
508
+ "→ Use tcRunID (58312120) as entityId for linked issues API",
509
+ "",
510
+ "FILTER CAPABILITIES: Support extensive filtering by test suite, platform, status, user, release, cycle, dates, and archive status",
511
+ "FILTER FIELDS: testSuiteName (string), platformID (list), executionStatus (list), executedBy (list), project (list), release (list), cycle (list), executedDate (date with comparison), isPlatformArchived (list), isTestSuiteArchived (list), executedVersion (numeric)",
512
+ "DATE FILTERING: Use 'gt' (greater than) and 'lt' (less than) comparisons for executedDate field",
513
+ "EXECUTION STATUS: Common values include 'PASS', 'FAIL', 'BLOCKED', 'NOT_EXECUTED', 'WIP' (verify with your QMetry instance)",
514
+ "PLATFORM/SUITE ARCHIVE: Use [1,0] for both archived and non-archived, [1] for archived only, [0] for active only",
515
+ "Multiple filter conditions are combined with AND logic",
516
+ "Use pagination for large execution result sets (start, page, limit parameters)",
517
+ "Get platform IDs from FETCH_PLATFORMS tool and release/cycle IDs from FETCH_RELEASES_AND_CYCLES tool",
518
+ "This tool is essential for test execution reporting, trend analysis, and compliance auditing",
519
+ "Execution data includes timestamps, user information, environment details, and test results",
520
+ "Use scope parameter to define retrieval context (project, folder, release, cycle)",
521
+ ],
522
+ outputDescription: "JSON object with executions array containing execution records, status, timestamps, and metadata",
523
+ readOnly: true,
524
+ idempotent: true,
525
+ },
526
+ ];