Skip to main content
Glama

Find Tests for a Symbol

find_tests_for
Read-onlyIdempotent

Find C# tests that likely cover a symbol using static call, access, construction, dispatch, or name evidence, so you can assess change impact and choose which tests to run.

Instructions

Find the tests that likely cover a symbol: test methods that call it, read it, build it or are named after it. Static evidence (coverage_gaps asks the reverse).

Use it before a change, to see what pins a symbol, and after, to pick tests. Only a method with a test attribute counts (default: Fact, Theory, Test, TestMethod, TestCase(Source)).

Returns items [{testType, testMethod, project, matchReason}] (+ 'testTypeFullName' where two read alike), count, totalFound, truncated (max 50), invokesTotal, dispatchTotal (omitted at 0) and an optional 'note' after the list. matchReason is one of eleven tiers, sorted: 'invokes' (it calls the target), 'invokes-via' (through one method or constructor), 'command' (it executes the target's command), 'command-via', 'accesses' (it reads or writes the target property or field; for a type, a static one), 'accesses-via', 'constructs' (it builds the target type; type and constructor queries only), 'constructs-via', 'dispatch' (it calls an interface, abstract or virtual member the target implements or overrides; a double may have run), 'dispatch-via' and 'name' (a guess: the test's or its class's name mentions the symbol - for Type.Member, both). The first eight are strong; invokesTotal counts them over the result and dispatchTotal the contract rows, the rest are name guesses.

Evidence reaches one call deep at most (the test's body and one method, constructor or getter it calls). The 'note' says so on an empty answer and on a non-constructor one whose strong rows are all '-via', and names other misleading cases: an undeclared name or type segment (name noise), an event or enum member (name tier only), a nested 'Outer.Inner' type, a constructor query, no strong row, contract rows, construction rows (matched by simple name), overloads unioned, tests left out for only reading a constant. 'namesakes': types sharing the name.

Read-only. symbol is case-sensitive: a type's simple name, a member name bare or as 'Type.Member' (only that type's member), or 'Type.Type' for the constructor.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "sessionId": "<sessionId>",
      "symbol": "<symbol>"
    },
    "name": "find_tests_for"
  }
}

Input Schema

NameRequiredDescriptionDefault
symbolYesThe type name, or the member name - bare or in the qualified Type.Member form - to find covering tests for.
sessionIdYesThe session_id returned by analyze_solution. Also takes an absolute .sln/.slnx/.slnf path, analyzed on first use.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.5.46513
    • changedInput schema / properties / sessionId / description
      Previous value: -"The session_id returned by analyze_solution."New value: +"The session_id returned by analyze_solution. Also takes an absolute .sln/.slnx/.slnf path, analyzed on first use."
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover the safety profile, yet the description adds substantial depth beyond them: evidence depth is capped at one call, results are tiered and sorted by an eleven-value matchReason, truncation at 50, and a 'note' that warns on specific misleading cases (undeclared names, event/enum members, nested types, overload unioning). The 'namesakes' caveat and case-sensitivity rule materially change how an agent should interpret results.

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?

Front-loaded with purpose and usage in the first three sentences, which is appropriate. The matchReason enumeration and the long comma-delimited list of 'note' triggers are dense and somewhat soup-like, and 'Read-only' partly restates the annotations, but the length is largely earned because there is no output schema to carry the return-value documentation.

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 and only two parameters, the description carries the full burden and does so: return fields, sorting, truncation, aggregate counters (invokesTotal, dispatchTotal) and the conditional 'note' are all explained. An agent has enough to call the tool and correctly interpret a weak or empty answer.

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 coverage is 100%, so the baseline would be 3, but the description adds real meaning: symbol is case-sensitive and accepts three distinct forms, including the scoping semantics of 'Type.Member' (only that type's member) and 'Type.Type' for a constructor query. These are interpretation rules the schema text does not spell out.

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?

States a specific verb and resource ("Find the tests that likely cover a symbol") and immediately enumerates the evidence kinds — calls it, reads it, builds it, named after it. It also explicitly contrasts itself with the sibling coverage_gaps ("asks the reverse"), so an agent can distinguish the two without opening either schema.

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?

Gives concrete lifecycle guidance — "before a change, to see what pins a symbol, and after, to pick tests" — and names the complementary tool (coverage_gaps). It stops short of a full when-not-to-use rule (e.g., when to prefer find_usages or impact_of_change instead), so it is clear but not exhaustive.

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