aicb-roslyn-mcp

Overview Schema Source Related Servers Discussions Admin

Run Several Queries at Once

batch

Read-onlyIdempotent

Execute multiple independent read-only C# code queries in one round-trip against a shared session, returning per-query results or errors.

Instructions

Run several read-only query tools in ONE round-trip against one shared session. measure is the sibling that sizes each answer instead of returning it.

Use it when the questions do not depend on each other's answers; a solution path as sessionId is analyzed once.

queries is an array of {tool, args}: args is that tool's own arguments as a JSON object WITHOUT sessionId (omit it for a tool that takes none). Example: queries=[{"tool":"find_usages","args":{"symbol":"Foo"}},{"tool":"find_tests_for","args":{"symbol":"Foo"}}]. At most 16 per call: more fails the whole call, as does a sessionId that does not resolve.

Returns { results: [{tool, ok, result | error | omitted}], count, okCount, omittedCount (when any) }, in query order. A failing sub-query answers ok:false + error; the rest still return. A JSON tool's result is nested as an object, a Markdown tool's is the string. The answers share about 9000 tokens, small ones whole first. A large answer is never cut: a 'budget' tool's may be rendered smaller if its share reaches that tool's floor (see 'note'), else it carries 'omitted' (it ran; call it directly). Unknown arguments are ignored, named in 'note'.

Dispatchable is a fixed registry of read-only queries about the analyzed code, among them find_*/get_*/impact_of_change/symbol_signature/explain_symbol/calls_external/resolve_injection/symbol_metrics/list_insights. Refused per item, with the registry's names listed - call these directly where the profile exposes them: tools that mutate session state or write (such as analyze_solution/refresh_session/apply_solution_config/save_session/remember_codebase/export_markdown/install_agent_hooks), poor batch members (evaluate_change_set/init_solution_config/prepare_task/review_context), tools needing a second session or snapshot (semantic_diff/diff_review/verify_claim/compare_with_previous) and the session, configuration and server tools. A tool the active MCP profile does not expose is refused per item too, as a direct call would be - also when a refusal's list names it.

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>",
      "queries": "<queries>"
    },
    "name": "batch"
  }
}

Input Schema

Name	Required	Description	Default
`queries`	Yes	The read-only sub-queries: an array of { tool, args } objects. 'tool' is a read-only tool name; 'args' is that tool's argument object (without sessionId), omittable when the tool needs no arguments. Max 16.
`sessionId`	Yes	The session_id returned by analyze_solution. Also takes an absolute .sln/.slnx/.slnf path, analyzed on first use. Shared by ALL sub-queries - do NOT repeat it inside each query's args.

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 (or an absolute .sln path to self-init once). Shared by ALL sub-queries - do NOT repeat it inside each query's args."New value: +"The session_id returned by analyze_solution. Also takes an absolute .sln/.slnx/.slnf path, analyzed on first use. Shared by ALL sub-queries - do NOT repeat it inside each query's args."

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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description adds substantial behavior beyond them: partial-failure semantics (a failing sub-query returns ok:false while the rest still return), the shared ~9000 token budget with small answers served whole first, and the guarantee that a large answer is never truncated - it is either rendered smaller against that tool's floor or returned as 'omitted'. Unknown arguments being silently ignored is also disclosed.

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?

Purpose, when-to-use, and the worked example are front-loaded before the return shape and the long dispatchable/refusal registry. The prose is dense and telegraphic rather than padded, but the final registry paragraph is a long run-on that could be split for scanability.

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 fully by spelling out the returned shape ({results:[{tool, ok, result|error|omitted}], count, okCount, omittedCount}), the ordering guarantee, and the distinction between JSON-tool results (nested objects) and Markdown-tool results (strings). Failure modes and the 16-item ceiling are all covered, so an agent has everything needed to invoke it 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 baseline is 3, but the description adds real meaning: args is the sub-tool's own arguments as a JSON object WITHOUT sessionId, args is omittable when the tool takes none, unknown argument keys are ignored and named in 'note', and a concrete two-entry example is given. The sessionId note that it is shared across all sub-queries and must not be repeated is echoed from the schema but reinforced usefully.

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?

The first sentence gives a specific verb and resource: run several read-only query tools in one round-trip against a shared session. It also explicitly distinguishes itself from the sibling 'measure', which sizes answers instead of returning them, so an agent can choose between the two without inspecting 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?

It states the selection condition plainly: use it when the questions do not depend on each other's answers. It also names alternatives and exclusions - 'measure' for sizing, and the refused categories (mutating session tools, second-session tools) that should be called directly instead. The 16-query cap and sessionId resolution failure are stated as hard limits.

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

Deploy Server