aicb-roslyn-mcp

Overview Schema Source Related Servers Discussions Admin

Get Solution Configuration Status

solution_config_status

Read-onlyIdempotent

Checks whether a solution's Layer Profile, Exclude-Namespaces and Test Profile are initialized and reports the active configuration, so you can offer guided setup when a slot is missing.

Instructions

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. With no DB (or an empty file) the answer comes from the sidecar and the built-in defaults, and no database is opened or created; a dbPath that does not exist is refused. Each slot names the config IN FORCE for the analysis - resolved exactly as analyze_solution resolves it - and its source: 'db' (the per-solution row or the app-global default), 'sidecar' (the committed .aicb.json applies, which it does whenever the DB configured nothing for the axis - a built-in default is not configuration), 'built-in' (the built-in exclusion list, applied when nothing configured one and no sidecar names one) or 'none' (the heuristic). A repo with a valid .aicb.json sidecar but no DB row reads initialized=true, source:sidecar, not a misleading uninitialized. Use this on solution start: if a slot is not initialized, offer to run init_solution_config + apply_solution_config.

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

Input Schema

Name	Required	Description	Default
`dbPath`	No	Absolute path to the aicb config/master SQLite DB that holds the per-solution configuration. Omit to use the server's default config DB (the same one the GUI uses), if the server resolved one; with none, or an empty file, the sidecar answers alone.
`sessionId`	Yes	The 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.

Changed1 schema field changedv0.5.46517Oct 30, 2026

changedInput schema / properties / dbPath / description

Previous value: -"Absolute path to the aicb config/master SQLite DB that holds the per-solution configuration. Omit to use the server's default config DB (the same one the GUI uses), if the server resolved one."New value: +"Absolute path to the aicb config/master SQLite DB that holds the per-solution configuration. Omit to use the server's default config DB (the same one the GUI uses), if the server resolved one; with none, or an empty file, the sidecar answers alone."

Changed1 schema field changedv0.5.46513Oct 4, 2026

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."

First observedOct 2, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already mark it read-only, idempotent, non-destructive, and closed-world. The description adds substantial context beyond annotations: initialized is an explicit marker, not inferred from an active id; source values db, sidecar, built-in, none are explained; no DB is opened or created when absent; nonexistent dbPath is refused; and sidecar-only repos are correctly reported as initialized.

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?

The purpose is front-loaded, then behavior and parameter notes follow in a logical order. It is dense and somewhat long for a status tool, with some overlap between description and schema, but most sentences carry useful configuration-resolution detail.

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?

For a status tool with no output schema, the description is complete enough: it explains initialization markers, active-profile resolution, source labels, sidecar fallback, DB behavior, and the recommended follow-up when configuration 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 schema already documents both parameters. The description still adds useful semantics: sessionId should be passed from analyze_solution, dbPath is optional and defaults to the server's config DB, and a nonexistent dbPath is refused — details not fully captured by the schema.

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: check whether a solution's Layer Profile, Exclude-Namespaces, and Test Profile are initialized and which profiles are active. It names related tools like apply_solution_config and analyze_solution, making the status-checking role clear without opening schemas.

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?

Explicitly says to use it on solution start and what to do if a slot is not initialized: offer init_solution_config and apply_solution_config. It also explains when dbPath can be omitted and what happens with no DB or empty file.

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

Deploy Server