aicb-roslyn-mcp

Overview Schema Source Related Servers Discussions Admin

Refresh a Session

refresh_session

Idempotent

Re-analyzes the session's C# solution after .cs edits so callers, impact, and context queries use the updated Roslyn graph instead of stale pre-edit results.

Instructions

Re-analyze the session's solution after YOUR code edits - call it once you have changed .cs files, otherwise find_usages / impact_of_change / list_insights / get_context may keep answering from the STALE pre-edit graph (a silent source of wrong results). Cheap to call speculatively: a W0 file-set-hash check skips the expensive Roslyn re-run when nothing actually changed, and a C# file whose timestamp moved while its text stayed the snapshot's (a save without an edit) does not count as a change either. That check reads SOURCE files. A restore that rewrote a project's assets file after the load is noticed anyway and reloads through MSBuild; a plain build is not seen - after one, an analysis that reported unresolved references retries once by itself, and 'force' is the deterministic way to demand a reload. Reuses the warm workspace. Returns { changed, reason, session, mode } - 'mode' names the path the re-analysis took ('incremental' = document texts replayed into the warm snapshot without an MSBuild reload, else 'full-reload') and is absent when nothing was re-analyzed. The incremental path can stop engaging without any visible symptom - answers stay correct, calls just get slow again - so 'mode' is how you notice.

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

Input Schema

Name	Required	Description	Default
`force`	No	Re-analyze even when no source file has changed. Use it after a restore/build that was meant to repair unresolved references - those live in build output the file-set hash does not cover, so an ordinary call can legitimately answer 'unchanged'. Costs a full MSBuild reload; leave false for the normal after-an-edit refresh.
`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 only declare readOnly=false/idempotent=true/destructive=false; the description goes far beyond by disclosing the W0 file-set-hash fast path, timestamp-vs-text comparison, assets-file restore detection via MSBuild, the one-shot auto-retry after an unresolved-reference build, warm-workspace reuse, and the observable-side-effect warning that the incremental path can silently stop engaging. Consistent with annotations (a state-mutating but idempotent cache refresh).

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 purpose and the stale-graph warning, and nearly every clause carries operational information. It is dense and long for a single paragraph, with nested parentheticals ('a silent source of wrong results', the timestamp caveat) that take effort to parse but are not padding.

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?

No output schema exists, and the description compensates by naming the return shape { changed, reason, session, mode } and explaining how to interpret 'mode' including its absence and the silent-degradation symptom. For a 2-parameter tool with annotations, nothing an agent needs in order to call or interpret it 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 baseline is 3; the description adds marginal meaning by framing force as the deterministic override and explaining why an ordinary call can legitimately answer 'unchanged' in the restore/build case. Most of this overlaps the schema's own force description, so it does not clear the bar for a 5.

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 ('Re-analyze the session's solution after YOUR code edits') and immediately contrasts its role with named siblings (find_usages / impact_of_change / list_insights / get_context) that go stale without it. An agent can tell exactly what this does and why it exists.

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 an explicit trigger ('once you have changed .cs files'), an explicit consequence of skipping it (stale pre-edit graph), and explicit guidance on the force alternative ('force' is the deterministic way to demand a reload; leave false for the normal after-an-edit refresh). It also pre-empts false positives (save without edit, plain build) so the agent knows when a no-op result is legitimate.

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

Deploy Server