Skip to main content
Glama

Find Symbols by Layer, Role or Domain

find_by_semantics
Read-onlyIdempotent

Find C# types and methods by resolved semantics: layer, role, domain, responsibility. Use filters to answer questions like 'list services in Infrastructure layer' or 'types with role X'.

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 'list the services of the Infrastructure layer' or 'which types carry role X?'. 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 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; the key is absent when there are none). A queried value missing from it is unknown at that confidence; if it is listed, the AND of your filters was empty.

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

Input Schema

TableJSON 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 already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is low, and the description far exceeds it: it discloses max 200 items and types-first ordering, whole-value vs substring match modes, near-miss behavior, zero-match behavior of availableAxisValues, the fact that domain/responsibility are never inferred, that there is no 'Repository' role, and that test-project symbols are matched like production ones.

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?

It is long, but front-loaded with purpose and usage before the matching mechanics, return shape and edge cases, and nearly every sentence adds operational information an agent needs. Slightly dense across eight paragraphs rather than ruthlessly trimmed, which keeps it from a 5.

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 present, the description carries the return-value burden and does so fully – criteria, note, minConfidence, matches (kind, name, declaringType, namespace, matched), matched source provenance, plus availableAxisValues and nearMisses when applicable. Nothing an agent needs to call and interpret it 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, but the description adds real meaning: filters combine with AND, layer/role match the whole value case-insensitively while domain/responsibility match as substrings, responsibility applies to types only, minConfidence rejects unknown values, and the echoed criteria encode the mode ('role=View' vs 'domain~order').

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?

States a specific verb and resource – find types and methods by their resolved semantics (layer, role, domain, responsibility) – which is a clear, distinctive capability. Concrete usage examples ('list the services of the Infrastructure layer', 'which types carry role X?') sharpen the intent. It does not name a sibling such as find_by_attribute or find_symbol to draw the boundary explicitly, so it stops short of a 5.

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 explicit when-to-use examples and a hard precondition ('At least one filter is required'). It does not, however, state when to prefer an alternative tool or when this is the wrong choice, so the routing guidance to siblings is incomplete.

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