Skip to main content
Glama
Sign In
Swipium

Swipium

by GeroPalombo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Scope testing to a feature

qa_app_map_feature_scope
Read-only

Resolve a feature ID or search query into a test scope: related code, screens, existing tests, coverage gaps, test strategy, and ranked candidates. Works from a code scan when no feature map exists.

Instructions

Resolve a feature (featureId, or a query like "checkout") to a test scope: code, screens, existing tests, coverage gaps, strategy, ranked candidates. Works without a map (code scan). Read-only.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "qa_app_map_feature_scope"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMax items per list (default 8).
queryNoe.g. "checkout flow".
platformNo
featureIdNoExact map feature id (or use query).
sessionIdNoAdds runtime screen-graph evidence.
includeCodeNoquery: scan source code (default true).
projectRootNoProject root when no session exists.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the trailing "Read-only" merely restates them. The one genuine addition is that the tool degrades gracefully to a code scan when no map exists, but there is no disclosure of cost, latency, or behavior when the feature cannot be resolved.

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 short sentences, front-loaded with the verb and feature addressing, followed by the output inventory. The output list is telegraphic ("strategy, ranked candidates") but no sentence is wasted.

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?

With no output schema, the description usefully enumerates what comes back and notes the map-optional fallback, which is the key operational fact for a 7-parameter read tool. Remaining gaps are minor: no failure mode for an unresolvable feature and no guidance on how platform/sessionId change results.

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 description coverage is 86%, so the parameters are already well documented, and the description adds little beyond noting featureId and query are the two ways to specify the feature. It does not explain the interaction between platform, sessionId, and includeCode, or what happens when both featureId and query are supplied.

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 names a concrete verb ("Resolve") and resource (a feature, via featureId or query) and enumerates the returned scope items (code, screens, existing tests, coverage gaps, strategy, ranked candidates). It partially distinguishes itself from map-dependent siblings with "Works without a map (code scan)," but never names a specific alternative such as the map query or feature-test tools.

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?

Usage is only implied: "Works without a map (code scan)" tells an agent it can skip building a map first, and the featureId-vs-query wording hints at two addressing modes. There is no explicit when-to-use/when-not-to-use statement or named alternative for cases where a map already exists or when the agent actually wants to execute tests.

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

Deploy Server

Other Tools