aicb-roslyn-mcp

Overview Schema Source Related Servers Discussions Admin

Propose a Solution Configuration

init_solution_config

Read-onlyIdempotent

Collects the raw configuration material needed to propose Layer Profile, Exclude-Namespaces, and Test Profile mappings before writing them via the apply step.

Instructions

Collect the raw material for the guided setup of a solution's Layer Profile, Exclude-Namespaces and Test Profile - step 1 of 2; apply_solution_config is the step that writes.

Use it when solution_config_status or the configInit hint of analyze_solution reports an axis as not initialized, or when check_solution_config_drift reports one as stale. Propose a mapping from the returned material, then call apply_solution_config with it. To only see what is configured, use solution_config_status.

Returns JSON: solutionPath; declaredNamespaces - the solution's own namespaces, the source for layer-mapping rules (test-project and framework namespaces are left out); referencedNamespaces - every namespace a using directive names, the solution's OWN included, heaviest first (a hand-written global using ahead of any file count), each {namespace, documents} (hand-written files whose own using names it), plus generatedDocuments (build-written files, obj/) and globalUsingProjects / implicitGlobalUsing (an SDK implicit using) where they apply - neither says what the code leans on: only the external/framework ones are exclusion material, never exclude your own; testProjects - what the default heuristic classifies as test projects; detectedTestAttributes - the test attributes present in the code; frameworkApiAreas - areas the built-in exclusion list removes although at least 15% of the public method signatures name them (Dapper: System.Data), each with the keepRule to put into exclusions so the rest of the list still applies; proposalFormat - the JSON shape apply_solution_config expects. The first three lists are capped envelopes (items/count/totalFound/truncated, max 300); the other two are plain arrays.

Read-only: it writes no configuration and no DB row and marks nothing as initialized. It walks the warm session workspace (no re-analysis), so it needs a live session; a recalled one is rejected with an error.

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

Input Schema

Name	Required	Description	Default
`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.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 declare readOnly/idempotent/non-destructive, and the description goes well beyond them: it writes no configuration, no DB row, marks nothing initialized, walks the warm session workspace without re-analysis, and requires a live session because a recalled one is rejected with an error. That is exactly the operational context annotations cannot express.

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 step 1 of 2 and the when-to-use conditions, and the return-value detail is necessary because no output schema exists. It is dense and the return paragraph runs long with semicolon-chained clauses, but no sentence is filler.

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?

With no output schema, the description fully specifies the return shape: solutionPath, declaredNamespaces vs referencedNamespaces, capped envelope semantics with max 300, generatedDocuments/globalUsing caveats, frameworkApiAreas with keepRule guidance, and proposalFormat. It also tells the agent how to consume the result ('Propose a mapping from the returned material'), including the critical rule never to exclude the solution's own namespaces.

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% and the sessionId description already covers the .sln/.slnx/.slnf path fallback, so the schema carries most of the load. The description still adds a constraint the schema lacks: the session must be live, and a recalled session errors out, which materially narrows acceptable sessionId values.

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 ('Collect the raw material for the guided setup of a solution's Layer Profile, Exclude-Namespaces and Test Profile') and explicitly frames itself as step 1 of 2 with apply_solution_config as the writer. That makes it unmistakable against its closest siblings, apply_solution_config and solution_config_status, without opening any schema.

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?

Names the exact triggering conditions (solution_config_status or the configInit hint of analyze_solution reporting an axis as not initialized, or check_solution_config_drift reporting one as stale) and the follow-on call ('then call apply_solution_config with it'). It also gives an explicit not-for-this alternative: 'To only see what is configured, use solution_config_status.'

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

Deploy Server