List Code Insights
list_insightsLists code-quality, async, and design-smell insights for an analyzed C# solution session, with per-producer counts, optional file scoping, and counts of suppressed findings.
Instructions
List code-quality / async / design-smell insights for a session (long methods, fat interfaces, unused types, missing async suffixes, many-parameter methods, ...). Runs against the live analyzed solution; each insight is aggregated per producer, with the count of its detail lines ('detailsCount'; get_insight lists them). Pass dbPath to use the active QualityProfile (producer thresholds + toggles) from that DB; omit it for the default profile (DB-free). Honors the session's active test-detection profile (resolved by analyze_solution(dbPath)) for the production-focused producers. An explicit analyze_solution(layerProfile) drives the layer-violation insight and wins over the DB-configured profile (same precedence as solution_metrics and the CLI gate). THIS ANSWER IS TRIAGE-FILTERED, on BOTH triage axes: findings the solution marked intentional (a suppression - in the DB or in the git-tracked .aicb.json sidecar) AND findings a user dismissed as seen (in the solution record, NOT in the sidecar) are removed, and an insight whose findings are all gone does not appear at all. Every insight that lost lines carries 'suppressed' with the count of what BOTH axes removed together (absent = nothing filtered), so a shrinking number is never mistaken for a codebase that improved - but do not read that count as a sidecar entry count, because some of it is dismissal. Note 'title' is producer text computed BEFORE filtering, so on a partially filtered insight it still names the pre-filter total - 'detailsCount' + 'suppressed' are the real split. 'remediationCostMinutes' is a coarse order-of-magnitude estimate from fixed per-finding rules, not measured effort. Pass files - say the files a change touches - for the findings about the types they declare, with their detail lines.
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": "list_insights"
}
}Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| files | No | Optional C# files, each absolute or relative to the solution folder: the answer keeps the findings about the types these files declare and becomes an object {files, notInSolution, insights}. 'files' are the ones the solution holds, solution-relative; 'notInSolution' the ones it does not (a deleted or non-C# file, a typo), as given. Each insight carries its in-scope 'details' with 'detailLocators' (up to 20, then a '(... and N more)' line), and 'detailsCount' counts the in-scope lines; 'title', 'remediationCostMinutes' and 'suppressed' stay the whole-solution numbers. A line matches by its locator's simple type name, so a same-named type elsewhere matches too, except on a member line whose member only that other type declares; a line about a file of top-level statements matches by that file; any other line with no type locator is left out, while an insight about the solution as a whole (no lines, no type locator) stays, with detailsCount 0. Omitted or empty: the solution-wide array above. | |
| dbPath | No | Optional path to an AIContextBuilder SQLite DB. When set, producer thresholds + toggles come from that DB's active QualityProfile AND the configured default layer profile (DefaultLayerProfileName / per-solution) drives the layer-violation analysis (an explicit analyze_solution(layerProfile) wins). Omitted, the QualityProfile falls back to the server's default config DB (the GUI's, if resolved), else the default profile, and the layer profile to the config DB the session was analysed against - the one its renders read. | |
| sessionId | Yes | The session_id returned by analyze_solution. Also takes an absolute .sln/.slnx/.slnf path, analyzed on first use. |