AIContextBuilder

Check whether a solution's Layer Profile, Exclude-Namespaces and Test Profile have been initialized via the guided setup, and which Layer Profile / Exclusion List / Test Profile is currently active. 'initialized' is an explicit marker for all three slots (stamped by apply_solution_config - it is NOT inferred from having an active id, which a user can also set manually via the Settings panel); the testProfile slot additionally reports the effective per-solution active test-detection profile. Pass the session_id; dbPath is optional - omit it to use the server's default config DB (the same one the GUI uses), if the server resolved one. Each slot reports its source (db/sidecar/none): a repo with a valid .aicb.json sidecar but no DB row reads initialized=true, source:sidecar (the sidecar IS consumed at analyze time), not a misleading uninitialized. Use this on solution start: if a slot is not initialized, offer to run init_solution_config + apply_solution_config.

The solution-wide quality rollup in ONE call - the same numbers the CLI '--fail-on' quality gate evaluates and the QP7 snapshot stamp persists: typeCount/methodCount (logical types - partial fragments merged, multi-TFM deduplicated), complexityMax/complexityAvg, methodsOverComplexityThreshold (STRICTLY greater than complexityThreshold - the response's complexityThresholdBoundary field states it; symbol_metrics' minComplexity and the complex-untested insight floor INCLUSIVELY at >=, so their lists at the same number are larger by exactly the boundary methods; the long-methods insight's complexity arm shares the strict boundary), ceMax/caMax (coupling maxima; Ca = reverse fan-in from the persisted dependencies), plus the quality-insight severity counts (critical/warning/info/ok) and the technical-debt estimate. Pass failOn to evaluate a gate expression (same syntax as 'aicb analyze --fail-on', e.g. 'critical>0 OR ce-max>50') against these numbers - the response then carries gate.passed/violatedClauses (advisory; the blocking gate stays the CLI). knownGateMetrics lists the valid metric tokens. Scope matches the CLI gate: PRODUCTION code only - test projects (per the active test profile) are excluded from every number, exactly as the severity/debt inputs beside them are (one population per gate object). The response says so itself: scope:'production' plus testMethodCount/testTypeCount, the EXCLUDED test-side tallies in the same units - methodCount+testMethodCount is the full solution's method-unit count, so cross-tool comparisons have their denominator. Pass dbPath to use that DB's active QualityProfile for the thresholds AND its configured default layer profile (per-solution > app-global) for the layer-violation severity - the same resolution the CLI gate and list_insights use; an explicit analyze_solution(layerProfile) still wins. The response discloses the effective layerProfile. Omit dbPath for the default profile. Works on recalled sessions - the LOC-based debt/lo…

Query per-method complexity directly, or rank the complexity hotspots. Returns BOTH McCabe CYCLOMATIC complexity (independent-path count) and SonarSource-style COGNITIVE complexity (how hard the method is to UNDERSTAND: a nesting penalty, else/catch counted, boolean-operator runs collapsed) for every method. Pass symbol=<exact method name> to get both numbers + the parameter count of that method (and any overloads/same-name methods), or the qualified Type.Member form to report that member on that type only - the same string find_usages / find_tests_for / explain_symbol resolve; omit symbol to RANK all methods by complexity descending, optionally filtered to complexity >= minComplexity (0 = no filter). The floor is INCLUSIVE - a method exactly AT minComplexity is listed, and a filtered answer states that as minComplexityBoundary; solution_metrics' methodsOverComplexityThreshold counts STRICTLY greater, so at the same number that count is smaller by exactly the boundary methods. By default ranking + the floor use cyclomatic complexity; set rankByCognitive=true to rank + filter by cognitive complexity instead (surfaces deeply-nested methods a low path-count would otherwise hide). get_context only surfaces complexity as an opt-in tag attribute - this gives a direct queryable/rankable view. Both metrics come from the persisted Roslyn fact (NOT line-count metrics, which are live-only) so it works on recalled sessions (a snapshot taken before cognitive complexity existed reports 0 for it). When ranking, test-project methods are EXCLUDED by default (production hotspots) - set includeTests=true to include them. How many of them cleared the floor is reported as 'testMethodsFiltered: N' - counted over the methods the filter REMOVED, which methodsScanned does not include, so it can exceed that number. When the strongest would have landed INSIDE the shown ranks a note names it and the rank it would hold: in a ranking, a count alone cannot say whether the missing methods sat at…

Return a symbol's signature(s) WITHOUT the body: the type declaration, the method/operator signature or a member's declaration (property, field, event, enum member - the last as its qualified Enum.Member form), plus its XML <summary> doc and its declaring file + start line - for understanding an API without reading the whole file/body, and for navigating straight to it. 'file' is the fragment's OWN file (for a partial type a method points at the file the METHOD lives in, not at the first type fragment); it is omitted only when the snapshot carries no path, and a member's 'line' is null (no line fact is modeled for members). Exact (case-sensitive) name match; multiple results for overloads or name collisions. A user-defined operator matches by its METADATA name ('op_Equality' / 'op_Implicit' / …). Leaner than get_context (which returns the full source). Returns a capped envelope (items/count/totalFound/truncated), max 50. Matching is EXACT, so a typo or case-mismatch returns an empty list rather than an error - when nothing matched, the response therefore carries a 'nearest' suggestion (the closest declared name), which distinguishes 'you spelled it differently' from 'this symbol genuinely has no signature'.

Report the SERVER-side tool-call telemetry: every tools/call invocation the CallTool filter has recorded into the config DB's tool_calls table - cross-client (corpus runs, foreign adopters), not this client's transcript. READ THE SCOPE FIRST - it is narrower than the numbers look, and the response repeats it in recordedVia because a client caches this description until it reconnects: the filter sits on the tools/call pipeline ONLY. A sub-query inside batch or measure records the PARENT call and no child row, and a one-shot `aicb call` invocation records nothing at all - both measured with planted probes. So every count here is a LOWER BOUND, and a tool at 0 was not called THROUGH THIS DOOR rather than not called. What the correction leaves untouched is the cross-client property: no transcript-based view can see a foreign harness at all. Returns overall totals (total calls, error count + rate, distinct tools + sessions, first/last timestamp, the clients + server versions seen) and a per-tool breakdown ranked by call count: calls, errors + rate, and latency (ms) + result size (chars) each as average / nearest-rank p50 + p90 / max - the percentiles are the honest read for the right-skewed latency distribution (one warmup call drags the average). Each tool with errors also carries errorClasses, the exception-TYPE histogram behind its error count (e.g. {"McpException": 3, "ArgumentException": 1}) - read the rate through it: McpException is a GUIDED failure the tool raised on purpose (expired session, unknown policy token), any other type is a defect suspicion worth chasing - with ONE exception the histogram cannot express, which is why argumentBindingErrors exists next to it: that count is the subset where the CALLER named an argument this tool does not have, so the call never reached the tool (neither a defect nor a refusal). It is not derivable from errorClasses, because the same ArgumentException is also what a guard INSIDE a tool raises; a value here means the tool'…

Verify a structured claim about a change by diffing two analyzed sessions (baseline → changed). Supported claim types (MVP): 'no_new_api' (no types/methods were ADDED AND no method signatures changed) and 'symbol_removed_unused' (the named symbol was removed AND had no usages in the baseline's static fan-in graph). Returns a verdict of confirmed / refuted / indeterminate with a reason + evidence. NOTE THE SCOPE OF 'no_new_api': it is about ADDITIONS and SIGNATURE CHANGES, so a REMOVAL does not refute it - a change set that only deletes public API is legitimately 'confirmed'. Removals are therefore never silent: the reason states the boundary and every removal the same diff records is listed as evidence, prefixed '-'. For the removal question ask verify_claim(symbol_removed_unused), or diff_public_contract (outside the default profile's pool). Conservative in BOTH directions: what the diff cannot prove is never falsely confirmed - and never falsely refuted either, because 'was not removed' is a claim about the change that is only made once the string resolves to something this diff could report on. A name that resolves to nothing, a property/field/event/enum member (the diff models types and methods only), and the simple name of a removed type the diff had to render by its FULL name because it is ambiguous, each return 'indeterminate' naming that cause - not a confident 'was not removed'. Unsupported claim types return indeterminate.