Skip to main content
Glama

TestChimp

by io.testchimp
OverviewDiscussionsAdmin

List Semantic Similar Tests

list-semantic-similar-tests
Read-onlyIdempotent

List semantically similar SmartTest pairs in scope using TestLocators (no test_id). Pairs are deduped (A→B only when A.testId < B.testId). Distinct-marked pairs are excluded.

Input Schema

NameRequiredDescriptionDefault
botIdNoQA bots: your botId from your stored TestChimp binding.
scopeNo
projectApiKeyNoQA bots: your own project API key from your stored TestChimp binding. Required on every call except get-bot-credentials, get-project-credentials and get-bot-compat. Never print it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / scope / properties / artifactType
      Added value: +{
+  "enum": [
+    "UNKNOWN_ARTIFACT_TYPE",
+    "USER_STORY_ARTIFACT",
+    "SCENARIO_ARTIFACT"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / scope / properties / ids
      Added value: +{
+  "items": {
+    "minLength": 1,
+    "type": "string"
+  },
+  "type": "array"
+}
  2. Changed2 schema fields changed
    • addedInput schema / properties / botId
      Added value: +{
+  "description": "QA bots: your botId from your stored TestChimp binding.",
+  "maxLength": 64,
+  "minLength": 1,
+  "type": "string"
+}
    • addedInput schema / properties / projectApiKey
      Added value: +{
+  "description": "QA bots: your own project API key from your stored TestChimp binding. Required on every call except get-bot-credentials, get-project-credentials and get-bot-compat. Never print it.",
+  "maxLength": 256,
+  "minLength": 8,
+  "type": "string"
+}
  3. First observed

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint/idempotent/non-destructive, and the description adds genuinely useful behavior beyond them: the dedup rule (A→B only when A.testId < B.testId) and the exclusion of distinct-marked pairs. It does not cover auth requirements, though the schema spells out projectApiKey.

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?

Two tightly packed sentences with no filler, and the core action is front-loaded. Minor jargon density ("TestLocator", "distinct-marked") slightly raises the reading cost but nothing is wasted.

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?

With no output schema, the description must carry the return-value burden, and it partially does (pair orientation and dedup). It leaves out what qualifies as "semantically similar" (threshold/source) and any pagination or volume expectations for a nested-scope list tool.

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 67%, so most parameters are documented structurally. The description only clarifies one nuance — scope selection is by TestLocators rather than test_id — and adds nothing about botId, projectApiKey, or how scope fields (ids/filePaths/folderPath/artifactType) interact.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource ("List semantically similar SmartTest pairs") plus the scope mechanism (TestLocators) and the output shape (deduped A→B pairs). It is clear what the tool returns, though it does not name the sibling list-semantic-nearby to distinguish itself from it.

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 parenthetical "(no test_id)" and "in scope" imply when the tool applies, but there is no explicit guidance on when to choose this over list-semantic-nearby or list-related-perf-tests. Usage is inferable rather than stated.

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

All TestChimp toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources