Skip to main content
Glama

Find Implementations

find_implementations
Read-onlyIdempotent

Lists all types implementing a C# interface, including external matches and optional test-project implementers, so you can identify every type affected before changing an interface member.

Instructions

List the types that implement an interface, in the solution or external (IDisposable). The interface counterpart to get_type_hierarchy (classes) and find_overrides.

Use it before changing an interface member, to find every type that must follow.

Returns items [{name, isAbstract (absent on interfaces and unknown kinds), kind, isTestProject, namespace, declaration, via, closes, through}], count, totalFound, truncated - at most 100, items without via first, then by name. 'declaration' is a generic implementer's arity form ('PolicyWrap'); via:'back-edge' = known only from the interface's implementer list, 'inherited' = through a solution base class or interface, 'derived-interface' = an interface extending it (implements nothing). 'closes' = the type arguments closing a generic interface, through bases too ('ContentSavedNotification'; an open generic names its own type parameter); 'through' = the base or interface it comes through. Absent when empty or unreadable.

A closed query ('IHandler') keeps the types closing it with those arguments; typeArgumentFilter counts the others closing it otherwise (otherClosings) or only over their own type parameters (openClosings). typeArgumentBase keeps the types closing it with an argument that is, derives from or implements that type ('DeletedNotification'); typeArgumentBaseFilter gives familyTypes and leftOut. An unreadable closing stays, marked closing:'unresolved'.

Test-project implementers are excluded by default; testImplementationsFiltered counts them (absent = none).

An empty answer carries a 'hint' when the name is not an interface or no indexed type carries it (a did-you-mean if one is close), and a 'generatedCodeNote' when a generator that did not run may have added it. A leading 'note' marks the inventory partial when a project's core references did not resolve (restore or build, then refresh_session).

Read-only. interfaceName is the simple name, case-sensitive. Two interfaces sharing a simple name answer as one list.

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>",
      "interfaceName": "<interfaceName>"
    },
    "name": "find_implementations"
  }
}

Input Schema

NameRequiredDescriptionDefault
sessionIdYesThe session_id returned by analyze_solution. Also takes an absolute .sln/.slnx/.slnf path, analyzed on first use.
includeTestsNoInclude test-project implementers (default false - production focus).
interfaceNameYesThe interface's simple name, e.g. 'ICodeAnalyzer'. An arity suffix ('IConsumer`1' / 'IConsumer<T>', or 'IConsumer`0' for the non-generic namesake) filters to that arity; a bare name keeps the merged view of every arity. A concrete type argument ('IConsumer<OrderPlaced>') keeps only the types that close it with that argument.
typeArgumentBaseNoOptional: keep only the types that close the generic interface with a type argument that is this type or derives from or implements it - a simple name, case-sensitive, with an arity suffix for a generic ('DeletedNotification<T>', 'ICancelableNotification'). Only solution types form the family; when none matches, typeArgumentBaseFilter carries a note.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.5.46516
    • addedInput schema / properties / typeArgumentBase
      Added value: +{
      +  "default": null,
      +  "description": "Optional: keep only the types that close the generic interface with a type argument that is this type or derives from or implements it - a simple name, case-sensitive, with an arity suffix for a generic ('DeletedNotification<T>', 'ICancelableNotification'). Only solution types form the family; when none matches, typeArgumentBaseFilter carries a note.",
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
  2. Changed1 schema field changedv0.5.46514
    • changedInput schema / properties / interfaceName / description
      Previous value: -"The interface's simple name, e.g. 'ICodeAnalyzer'. An arity suffix ('IConsumer`1' / 'IConsumer<T>', or 'IConsumer`0' for the non-generic namesake) filters to that arity; a bare name keeps the merged view of every arity."New value: +"The interface's simple name, e.g. 'ICodeAnalyzer'. An arity suffix ('IConsumer`1' / 'IConsumer<T>', or 'IConsumer`0' for the non-generic namesake) filters to that arity; a bare name keeps the merged view of every arity. A concrete type argument ('IConsumer<OrderPlaced>') keeps only the types that close it with that argument."
  3. 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."
  4. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already cover read-only/idempotent/closed-world, and the description adds substantial behavior beyond them: a hard cap of 100 items with a 'truncated' flag, deterministic ordering ('items without via first, then by name'), test implementers excluded by default with a counter, partial-inventory 'note' when core references fail to resolve, and generator hints on empty results. These are exactly the traits an agent needs to interpret results correctly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and the 'use before changing an interface member' line are properly front-loaded, but the middle is a very dense wall of quoted field names and run-on clauses ('via', 'closes', 'through', 'closing') that is hard to parse in one pass. Most content earns its place because there is no output schema, but the packaging could be far tighter.

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 return-shape burden and does so thoroughly — item fields, ordering, truncation, filter result fields, empty-result hints, and partial-inventory caveats are all covered. Nothing an agent needs to call this correctly or interpret its output 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 baseline is 3; the description still adds meaning on top: interfaceName is case-sensitive, an unreadable closing returns as closing:'unresolved', and the filter outputs (typeArgumentFilter/typeArgumentBaseFilter producing otherClosings, openClosings, familyTypes, leftOut) are explained with examples. The value is real but overlaps the already-detailed schema in places.

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 ('List the types that implement an interface') plus scope (solution or external, e.g. IDisposable), and explicitly positions itself against named siblings: the interface counterpart to get_type_hierarchy and find_overrides. An agent can pick the right one without opening schemas.

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 a concrete trigger — 'Use it before changing an interface member, to find every type that must follow' — and names the sibling alternatives for class hierarchies and overrides. It does not state when *not* to use it (e.g. for finding call sites, use find_usages), so it stops short of full routing guidance.

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