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

aicb-roslyn-mcp

by gregordadera
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

Read the Operating Manual

docs
Read-onlyIdempotent

Read the aicb operating manual: setup, first-context steps, tool navigation, and config pages, with token estimates for budgeting. Start here before using aicb.

Instructions

The aicb operating manual - how to USE this server, as opposed to what it can tell you about your code. Call it with no arguments for the directory (each page with a one-line summary and a token estimate, so you can budget); pass one or more page ids to read them, or the route id 'init' for the whole first run in order. Pages: 'overview' (what aicb is and is not, the three ways to run it), 'install' (getting the dotnet tool, aicb init, and what it writes - the client's .mcp.json entry and the agent skill a tool install cannot deliver; for setting aicb up somewhere else, or finishing a half-done setup), 'first-context' (from a .sln to your first context - and why the full export is rarely the right call), 'navigation' (which tool answers which question about the code, the blast-radius call before editing shared code, and where plain text search is still right), 'solution-config' (layers / exclusions / test detection and the .aicb.json sidecar), 'glossary' (session, facet, MCP profile, snapshot, insight, AI-Builder MD). Start here if you have not used aicb before. No session and no solution needed.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "docs"
  }
}

Input Schema

NameRequiredDescriptionDefault
topicsNoOptional page or route ids. Omit for the directory. A route id ('init') expands to its pages in reading order; repeats collapse, so asking for a route and one of its pages yields one copy. Unknown ids are named back to you rather than silently dropped.

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds real behavioral detail beyond them: token estimates per page for budgeting, route expansion into reading order, deduplication of repeats, and unknown ids being named back rather than dropped.

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-loads what it is, then how to call it, then the page catalog. The page enumeration is long but each entry earns its place as a routing aid; only minor tightening is possible.

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 single optional-array parameter tool with rich annotations and no output schema, the description covers invocation modes, valid values, edge behavior, and prerequisites. Nothing an agent needs to call it correctly 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, but the description goes further by enumerating every valid page id with its content summary ('overview', 'install', 'first-context', 'navigation', 'solution-config', 'glossary') plus the 'init' route — effectively documenting the valid value domain beyond 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?

The first sentence names the specific resource (the aicb operating manual) and explicitly demarcates its scope: 'how to USE this server, as opposed to what it can tell you about your code.' That contrast cleanly separates it from the ~50 sibling code-analysis tools.

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 explicit routing conditions: 'Start here if you have not used aicb before', explains that a bare call returns the directory, and gives per-page when-to-use cues (e.g. 'for setting aicb up somewhere else, or finishing a half-done setup'). It also notes 'No session and no solution needed', removing a common prerequisite question.

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