Skip to main content
Glama

Find Event Subscriptions

find_by_event_subscription
Read-onlyIdempotent

Find C# types subscribing to an event via '+=' to identify listeners, handler wiring, and unreleased subscriptions for leak detection.

Instructions

Find the TYPES that subscribe to a C# event: a '+=' whose left side resolves to an event, anywhere in the type; external events too ('Button.Click'). find_usages on a solution-declared event lists its (un)subscribing and raising METHODS.

Use it for 'who listens to this event?', where handlers are wired, and as a leak hint. A '+=' on a number, string or delegate field is no subscription and is skipped. XAML-wired handlers (Click="OnClick") are 'markupWires' (handler, viewCount, views), owe no '-=', are never 'unreleased'; no event is recorded with them, so eventName cannot match them.

Returns scope, event, typesScanned, subscriptionSitesChecked, subscriptionSitesUnresolved, matches (at most 200 types: name, namespace, events, unreleased, markupWires; sorted by namespace, name) and when they apply 'note', availableEvents, testMatchesFiltered. A partial type is one row ('files' when spread over several); 'fullName' marks namesakes, 'project' linked-file twins. A hit lists ALL event keys ('DeclaringType.EventName') the type subscribes to.

'unreleased' lists each subscription no '-=' of the type removes ('Event <- Handler'). A '-=' counts for the same event AND the same handler on ANY receiver, so an old/new swap reads released; a lambda never matches, so a lambda subscription is always listed; a subscription to an object the type owns is listed although it cannot outlive it. [] means each has a matching '-='; no list means not measured (see the note). A place to look, not a proven leak.

Reading an empty answer: availableEvents lists the events subscribed in scope; read testMatchesFiltered first if present. An EMPTY availableEvents means none was RECORDED - recognition needs a resolved left side. The site counts settle it: '0 of 0' is nothing to see, '0 of 7, 0 unresolved' a real absence, '0 of 7, 7 unresolved' an unmeasured scope.

Read-only; works on a recalled session. eventName matches exactly, never as a substring; omit it for every subscribing type. Test-project types are excluded unless includeTests=true.

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

Input Schema

NameRequiredDescriptionDefault
scopeNo'solution' (default) or a namespace prefix (e.g. 'MyApp.UI') to narrow scope.solution
eventNameNoFilter to types subscribing to this event - the event name ('Click') or the qualified 'DeclaringType.EventName' key ('Button.Click'), case-insensitive. Omit to list every type with any subscription.
sessionIdYesThe session_id returned by analyze_solution. Also takes an absolute .sln/.slnx/.slnf path, analyzed on first use.
includeTestsNoInclude test-project types (default false - production focus; test setup that wires events would drown the signal).

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 declare readOnly, idempotent and non-destructive, but the description goes well beyond them: it explains skipped '+=' cases, XAML markupWires, 'unreleased' semantics, partial types, name collisions, and how empty results should be interpreted. This is unusually rich behavioral context for a read-only analyzer tool.

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?

The description is long, but it is front-loaded with purpose and use cases and then organized into return-value, edge-case, and empty-result sections. Given the complexity and absence of an output schema, most detail earns its place, though some sentences are dense enough to verge on over-specification.

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 of explaining return fields, match limits, sorting, edge cases like markupWires, and how to interpret empty and unresolved results. It is complete enough for an agent to invoke and interpret the tool correctly.

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 schema carries most parameter documentation. The description still adds meaningful semantics, especially that eventName matches exactly and never as a substring, and reinforces test-project exclusion behavior beyond the schema's default-value explanation.

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 TYPES that subscribe to a C# event. It distinguishes itself explicitly from find_usages on solution-declared events, so an agent can route between them 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 Guidelines5/5

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

Gives concrete when-to-use cases: 'who listens to this event?', where handlers are wired, and as a leak hint. It also names the alternative behavior of find_usages on solution-declared events and explains how to read empty results, leaving little to inference.

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