Skip to main content
Glama
gregordadera

aicb-roslyn-mcp

by gregordadera
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

Get Review Context

review_context
Read-onlyIdempotent

Assembles per-symbol fan-in, transitive impact risk, implementations, and covering tests in one call to gauge blast radius and test coverage before reviewing or refactoring.

Instructions

Assemble review context for a set of changed symbols in ONE call: per symbol its fan-in, the transitive change impact with a risk level, the types that implement it (if an interface) and the test methods that likely cover it. It bundles what find_usages, impact_of_change, find_implementations and find_tests_for answer one symbol at a time.

Use this before reviewing or refactoring to see blast radius + test coverage at a glance. It does not name the callers (use find_usages or impact_of_change for that list) and returns no code (use explain_symbol).

Returns a JSON array ordered by symbol NAME - index it by 'symbol', never by request position. Per entry: symbol, resolvedKind, directUsages, transitiveImpact, risk (none/low/medium/high), implementations (names; test doubles are listed too, find_implementations filters them by default), coveringTests (testType, testMethod, project, matchReason), coveringTestsTotal, coveringTestsTruncated. An unresolved name reads resolvedKind 'not_found' with a 'note' and no risk; a 'note' also flags a risk graded on the direct fan-in or on implementers alone. For a bare name several types share, the counts are their union and no note says so - find_usages names the namesakes.

'coveringTests' is find_tests_for's list: strongest evidence first, capped at 50 per symbol. The cap keeps the 50 strongest rows: name guesses go first, strong rows too once there are more than 50. find_tests_for stops at the same 50, so narrow the symbol rather than re-query. 'invokesTotal' (strong rows) and 'dispatchTotal' (rows reaching the symbol through an interface or abstract member) count the WHOLE list and can exceed the rows shown; coveringTestsTotal minus both is the name guesses. For a qualified method, directUsages and transitiveImpact include callers credited through such a member - see 'viaContract' / 'viaContractNote'.

Read-only. Parameters: symbols must not be empty and takes the strings find_usages resolves - a type's simple name, or a member bare or as Type.Member.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
symbolsYesThe changed type/method names to assemble review context 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.8/5.0
Behavior5/5

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

Annotations already cover the safety profile (read-only, idempotent, non-destructive), yet the description adds substantial behavioral detail: results are ordered by symbol NAME and indexed by 'symbol' rather than request position, the 50-row cap and its retention policy, invokesTotal/dispatchTotal semantics, 'not_found' handling with notes, union counting for shared bare names, and test doubles included. Very little about runtime behavior is left implicit.

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?

Purpose is front-loaded and nearly every sentence carries unique semantics (ordering key, cap policy, count attribution, namesake caveat). It is, however, a dense unformatted block without headers or bullets, which makes the return-shape details harder to scan than they need to be given the volume.

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 carries the full burden and does so: every returned field (symbol, resolvedKind, directUsages, transitiveImpact, risk, implementations, coveringTests and its subfields, coveringTestsTotal/Truncated) is documented along with edge cases like not_found and unioned counts. Nothing an agent needs to interpret the response is missing.

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 is 3, and the description goes beyond it by stating that symbols must not be empty and that it accepts the exact strings find_usages resolves (a type's simple name, or a member bare or as Type.Member). It does not elaborate on sessionId beyond what the schema already documents.

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?

Opens with a specific verb+resource+scope ('Assemble review context for a set of changed symbols in ONE call') and enumerates exactly what is bundled: fan-in, transitive impact with risk level, implementers, covering tests. It explicitly names the four siblings it consolidates (find_usages, impact_of_change, find_implementations, find_tests_for), so an agent can place it precisely in the toolset.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

States the triggering situation ('Use this before reviewing or refactoring to see blast radius + test coverage at a glance') and gives explicit exclusions with routing alternatives: it does not name callers (use find_usages or impact_of_change) and returns no code (use explain_symbol). When-to-use, when-not-to-use, and alternatives are all present.

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