Skip to main content
Glama
Sign In
aicb-roslyn-mcp

aicb-roslyn-mcp

by gregordadera
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

Check Solution Configuration Drift

check_solution_config_drift
Read-onlyIdempotent

Detects stale Layer Profile, Exclude-Namespaces and Test Profile settings that no longer match a solution's code, so you know when to rebuild them.

Instructions

Check whether a solution's active Layer Profile, Exclude-Namespaces and Test Profile still FIT the code. solution_config_status tells you WHICH configuration is active and where it comes from.

Use it on a solution configured a while ago, or when layer or exclusion results look off; a stale axis is rebuilt with init_solution_config and apply_solution_config. On a never-configured solution only exclusion.excludedApiAreas is evaluated.

Three conservative signals: layer - declared (own) namespaces that no rule of the active layer profile maps; exclusion - EXTERNAL referenced namespaces that the active exclusion list does not cover; test - projects the default heuristic classifies as test projects that the active custom test profile's rules do not match.

Returns JSON with layer, exclusion and test, each carrying source (db / sidecar / built-in / none), name, status, stale, considered (the denominator), sample (drifted names, items/count/totalFound/truncated, max 50) and reason (the drifted count against considered). status is 'stale' from 3 drifted names on for layer and exclusion, for test above a quarter of considered projects; else 'ok' (an 'ok' with a sample is still worth reading). 'built-in-preset' and 'not-configured': the axis was NOT judged, only a custom config is (a generic preset is a choice, not drift). exclusion.excludedApiAreas, on any status: excluded areas carrying the public API, each with the keepRule to add. sidecarProblem: the .aicb.json could not be read.

It changes no configuration and creates no solution row; a missing dbPath is refused, an empty one is not opened, an older one is upgraded on open (schema, built-in rows). It judges the configuration a plain analyze_solution resolves NOW, not a layerProfile the session was analyzed with. It needs a live session, not a recalled one.

Parameters: normally pass only sessionId (an absolute .sln/.slnx/.slnf path works too). Pass dbPath only if the session was analyzed with it; otherwise this judges a configuration the analysis did not use.

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": "check_solution_config_drift"
  }
}

Input Schema

NameRequiredDescriptionDefault
dbPathNoOptional absolute path to the aicb config/master DB. If given, the config the DB holds for the solution (per-solution row, then app-global default) takes precedence over the .aicb.json sidecar; a built-in default in the DB does not. Omit to fall back to the server's default config DB (the GUI's, if resolved), else only the .aicb.json sidecar next to the .sln.
sessionIdYesThe session_id returned by analyze_solution. Also takes an absolute .sln/.slnx/.slnf path, analyzed on first use.

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.6/5.0
Behavior4/5

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

Annotations already declare readOnly/non-destructive/idempotent, but the description adds real context: it changes no configuration and creates no solution row, a missing dbPath is refused, an empty one is not opened, an older one is upgraded on open, and it needs a live session rather than a recalled one. It also explains which statuses mean 'not judged' (built-in-preset, not-configured) and what sidecarProblem means. The gap: the 'upgraded on open (schema, built-in rows)' detail is a write side effect that sits awkwardly next to a pure read-only framing, and the description never reconciles that tension.

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 with the core verdict question before any of the return-shape detail, and the positioning against solution_config_status comes early where it matters. It is dense and long, with several back-to-back clauses (status thresholds, sample caps, sidecarProblem, dbPath caveats) that could be split for scanability, but almost every sentence carries operational content.

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?

There is no output schema, and the description compensates thoroughly: it enumerates the returned keys (layer, exclusion, test, source, name, status, stale, considered, sample, reason, sidecarProblem), defines the staleness thresholds, and explains that an 'ok' with a sample is still worth reading. For a multi-axis diagnostic tool this is complete enough to call and interpret correctly.

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 genuine selection guidance: normally pass only sessionId, an absolute .sln/.slnx/.slnf path also works, and dbPath only if the session was analyzed with it — otherwise the result judges a configuration the analysis did not use. That conditional is not in the schema and prevents a real misuse.

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 object: check whether a solution's active Layer Profile, Exclude-Namespaces and Test Profile still fit the code. It also explicitly distinguishes itself from the nearest sibling, solution_config_status, which reports WHICH configuration is active rather than whether it still fits.

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 concrete trigger conditions ("on a solution configured a while ago, or when layer or exclusion results look off") and names the relevant alternatives and remedies: init_solution_config and apply_solution_config for a stale axis, solution_config_status for the 'which/where-from' question. It also states a scoping exclusion: on a never-configured solution only exclusion.excludedApiAreas is evaluated.

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

Deploy Server

Other Tools