Skip to main content
Glama

Find Symbols by Layer, Role or Domain

find_by_semantics
Read-onlyIdempotent

Find C# types and methods by resolved layer, role, domain, or responsibility; combine filters to answer which symbols match semantic criteria.

Instructions

Find types and methods by their resolved semantics: layer, role, domain, responsibility. Filters combine with AND, and each hit names where a matched value came from.

Use it for 'which types of layer X carry role Y?'. At least one filter is required.

layer and role match the WHOLE value, case-insensitively: role='View' is one view, not every ViewModel. Values that merely contain the query are counted in nearMisses (axis, value, symbols) and named in a leading 'note', never listed as matches. domain and responsibility are free text and match as a case-insensitive substring; responsibility exists on types only, so setting it matches no method. The echoed criteria show the mode ('role=View' vs 'domain~order').

Returns criteria, a 'note' when there are near misses, minConfidence, matches - at most 200 items (kind, name, declaringType, namespace, matched), types first - and when they apply availableAxisValues, unclassifiedAxes, verifiedAbsentAxes and nearMisses. matched lists per filtered axis the field, the value and its source: 'fact', 'ai', 'inferred' or 'none'.

The layer and role values the built-in inference assigns are listed on those parameters; there is no 'Repository' role and an enum gets none. A layer profile or an annotation adds values in its own spelling ('viewmodel-item' beside 'ViewModel'). Nothing infers a domain: that axis matches only where an annotation set one.

On zero matches availableAxisValues lists, for the queried axes, the values present under the same minConfidence (up to 50 per axis). A queried axis no symbol carries a value on at that confidence (so nothing can match it here) is in verifiedAbsentAxes when every symbol declares it 'none' via , otherwise (only some declare it, or no symbol does) in unclassifiedAxes. A queried value missing from availableAxisValues is unknown at that confidence; if it is listed there, the AND of your filters was empty. An axis you did not query is in no list.

Read-only; test-project symbols are matched like production ones.

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_semantics"
  }
}

Input Schema

NameRequiredDescriptionDefault
roleNoMatch symbols whose resolved Role EQUALS this (whole value, case-insensitive). Inferred TYPE roles: Service, Helper, Model, Record, Interface, Builder, ViewModel, Converter, Controller, Middleware, Attribute, Exception, EntryPoint, ContractModel, Type - there is NO 'Repository' (a repository class is mostly 'Service'), and an enum gets no role. Methods use a category role (e.g. Query, Command, Mapping, Validation, Orchestration). <ai>-asserted roles add values of their own. Omit to not filter on role.
layerNoMatch symbols whose resolved Layer EQUALS this (whole value, case-insensitive). The built-in inference assigns Domain / Application / Infrastructure / Presentation / Contracts; a layer profile adds its own names. Omit to not filter on layer.
domainNoMatch symbols whose resolved Domain contains this (free text, set by an <ai> annotation - nothing infers it). Omit to not filter on domain.
sessionIdYesThe session_id returned by analyze_solution. Also takes an absolute .sln/.slnx/.slnf path, analyzed on first use.
minConfidenceNoConfidence floor: 'any' (default - include inferred guesses) or 'asserted' (only fact/ai). Any other value is rejected (not silently treated as 'any').any
responsibilityNoMatch TYPES whose resolved Responsibility contains this (types only; free text). Omit to not filter.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.5.46513
    • changedInput schema / properties / domain / description
      Previous value: -"Match symbols whose resolved Domain contains this (free text - derived from naming/namespace). Omit to not filter on domain."New value: +"Match symbols whose resolved Domain contains this (free text, set by an <ai> annotation - nothing infers it). Omit to not filter on domain."
    • changedInput schema / properties / layer / description
      Previous value: -"Match symbols whose resolved Layer EQUALS this (whole value, case-insensitive). Clean-Architecture layers: Domain / Application / Infrastructure / Presentation / Contracts. Omit to not filter on layer."New value: +"Match symbols whose resolved Layer EQUALS this (whole value, case-insensitive). The built-in inference assigns Domain / Application / Infrastructure / Presentation / Contracts; a layer profile adds its own names. Omit to not filter on layer."
    • changedInput schema / properties / role / description
      Previous value: -"Match symbols whose resolved Role EQUALS this (whole value, case-insensitive). Inferred TYPE roles (closed set): Service, Helper, Model, Record, Interface, Enum, Builder, ViewModel, Converter, Controller, Middleware, Attribute, Exception, EntryPoint, ContractModel, Type - there is NO 'Repository' (repositories are 'Service'). Methods use a category role (e.g. Query, Command, Mapping, Validation). <ai>-asserted roles may differ. Omit to not filter on role."New value: +"Match symbols whose resolved Role EQUALS this (whole value, case-insensitive). Inferred TYPE roles: Service, Helper, Model, Record, Interface, Builder, ViewModel, Converter, Controller, Middleware, Attribute, Exception, EntryPoint, ContractModel, Type - there is NO 'Repository' (a repository class is mostly 'Service'), and an enum gets no role. Methods use a category role (e.g. Query, Command, Mapping, Validation, Orchestration). <ai>-asserted roles add values of their own. Omit to not filter on role."
    • 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.3/5.0
Behavior5/5

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

Annotations only cover the safety profile (read-only, idempotent, closed-world), and the description adds substantial behavior beyond that: AND combination of filters, whole-value vs substring matching per axis, a 200-item cap with types ordered first, nearMisses surfacing instead of matches, and the zero-match diagnostic logic distinguishing verifiedAbsentAxes from unclassifiedAxes by minConfidence. It also discloses that test-project symbols are matched like production ones, which annotations do not cover.

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 purpose and the one-filter requirement are front-loaded, and the dense diagnostic paragraphs are justified by the tool's complexity and the absence of an output schema. There is some redundancy, such as restating that domain and responsibility are case-insensitive substrings (already in the schema) and a meta-sentence pointing the reader at the parameter lists rather than stating the values.

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 describing the return payload (criteria, note, minConfidence, matches with kind/name/declaringType/namespace/matched, plus the conditional diagnostic lists), and it does so completely. It also covers the failure-mode semantics an agent needs to interpret an empty result, which is the main risk for a filter tool of this kind.

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; the description goes beyond it by explaining how filters compose (AND), how matched values are attributed per axis with a source ('fact', 'ai', 'inferred', 'none'), and how the echoed criteria encode the match mode ('role=View' vs 'domain~order'). It also clarifies that the enumerated layer/role values live on the parameters themselves and that <ai>-asserted values add their own spellings, which resolves ambiguity the schema alone leaves open.

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 opens with a specific verb and resource ('Find types and methods by their resolved semantics') and enumerates the four axes (layer, role, domain, responsibility), which clearly separates it from attribute- or side-effect-based siblings. It stops short of naming an alternative tool such as find_by_attribute or find_symbol, so an agent must infer the routing from the axis names alone.

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?

It gives a concrete use case ('which types of layer X carry role Y?') and a hard precondition ('At least one filter is required'), plus per-axis guidance on when an axis can never match (responsibility on methods, domain without an <ai> annotation). It does not say when to prefer a sibling tool or what to do if the result is empty beyond interpreting the diagnostic lists.

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