Skip to main content
Glama

Measure Method Complexity

symbol_metrics
Read-onlyIdempotent

Measure cyclomatic and cognitive complexity plus parameter count for a named C# method, or rank solution hotspots to locate hard-to-follow code before editing.

Instructions

Report method complexity: McCabe CYCLOMATIC complexity (independent paths) and COGNITIVE complexity (how hard the method is to follow: nesting is penalised, boolean-operator runs collapse), plus the parameter count - for one method by name, or as a ranking of the hotspots. solution_metrics gives the solution-wide rollup.

Use it before touching an unfamiliar method, and to find where the complexity sits. Both metrics measure CODE SHAPE, not runtime cost; for a hot path use a profiler.

With symbol (mode 'symbol'): every method unit of that exact, case-sensitive name - bare for all same-named ones, 'Type.Member' for one type's. scope, includeTests, minComplexity and rankByCognitive are ignored. Accessors, constructors and operators answer by metadata name ('get_Items', '.ctor', 'op_Equality'); '.ctor' is every constructor unit of the solution, 'Type..ctor' one type's. Without symbol (mode 'ranked'): methods only, sorted by cyclomatic complexity descending - by cognitive with rankByCognitive=true - and filtered to complexity >= minComplexity (inclusive; 0 = no floor).

Returns scope, mode, metricMeaning, minComplexity, methodsScanned, methods - at most 200 items (name, declaringType, namespace, cyclomaticComplexity, cognitiveComplexity, parameterCount; project when two projects compile one type) - and when they apply 'note', minComplexityBoundary, 'nearest' (a close declared name when a lookup matched no method) and testMethodsFiltered. In a ranking, test-project methods are excluded by default (includeTests=true includes them); testMethodsFiltered counts those that cleared the floor, and the note names the strongest one when it would have ranked inside the shown list. The note also says when the two axes would have listed different methods.

An empty ranking means nothing cleared the floor - or the scope matched nothing: methodsScanned 0, plus a note. An empty lookup means no METHOD of that name; a bare property or type name gets a note saying so.

Read-only; works on a recalled session.

Input Schema

NameRequiredDescriptionDefault
scopeNoWhen ranking: 'solution' (default) or a namespace prefix to narrow scope. Ignored when symbol is given.solution
symbolNoExact (case-sensitive) method name to report - bare (every same-named method) or in the qualified Type.Member form (that type's member only). Omit to rank all methods by complexity.
sessionIdYesThe session_id returned by analyze_solution. Also takes an absolute .sln/.slnx/.slnf path, analyzed on first use.
includeTestsNoWhen ranking: include test-project methods (default false - production hotspots; CC-heavy test harnesses would otherwise skew the top-N). Ignored in the by-name symbol lookup (which always returns the named method).
minComplexityNoWhen ranking (no symbol): only include methods whose ranking complexity (cyclomatic, or cognitive when rankByCognitive=true) >= this. 0 (default) = no filter.
rankByCognitiveNoWhen ranking: rank + filter by COGNITIVE complexity instead of cyclomatic (default false). Both numbers are always present per method; this only changes the sort + minComplexity axis. Ignored in the by-name symbol lookup.

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 readOnly/idempotent/non-destructive/non-open-world, yet the description adds substantial behavior: a 200-item cap, default exclusion of test-project methods with a rationale, empty-ranking vs empty-lookup semantics, nearest-name notes, and testMethodsFiltered accounting. This is rich context beyond what structured fields provide.

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?

Front-loaded: the first sentence delivers the core purpose and metrics, then modes and return shape follow. It is dense and long with some redundancy against the schema (mode-ignore rules restated), but nearly every sentence carries distinct information for a genuinely complex tool.

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?

No output schema exists, so the description carries the return-shape burden and does so fully: it enumerates every returned field (scope, mode, metricMeaning, methodsScanned, methods, note, minComplexityBoundary, nearest, testMethodsFiltered) and explains edge-case returns for empty rankings and lookups.

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 mode-interaction semantics (scope/includeTests/minComplexity/rankByCognitive are ignored in symbol mode) and the metadata-name convention for accessors/constructors/operators ('get_Items', '.ctor', 'op_Equality') that the schema does not explain. Some of the ignore-when text overlaps the schema's own 'Ignored when symbol is given' notes, capping it below 5.

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: reports McCabe cyclomatic and cognitive complexity plus parameter count for a method or as a ranking. It explicitly distinguishes itself from the sibling solution_metrics (solution-wide rollup) and from profilers (runtime cost).

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 explicit when-to-use ('before touching an unfamiliar method, and to find where the complexity sits') and when-not (for runtime cost use a profiler). Mode selection is spelled out with the exact triggering parameter (symbol present vs absent), so the agent knows which sibling and which mode to pick.

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