aicb-roslyn-mcp

Overview Schema Source Related Servers Discussions Admin

List MCP Profiles

list_mcp_profiles

Read-onlyIdempotent

Lists MCP profiles from the server's config database, including id, name, active status, and render settings. Use the profile id with 'aicb mcp --mcp-profile ' to pin it at server start.

Instructions

List the MCP profiles in the server's config DB - each with its id, name, the slots that have a template assigned (General appears exactly when a profile-wide template is set), the profile-wide templateId (null = none), whether it carries a skill, its effective tool-set (toolSelection: the class-level CSV, or a 'methods:'-prefixed function-name list when the profile curates individual tool functions; null = lean core), whether it is the active one, AND the render config it applies (tokenBudget / outputFormat / overflowPolicy - a null tokenBudget/overflowPolicy means inherit: the template then the active PipelineProfile decides). Requires the server to be started with --db-path. Use the ids with 'aicb mcp --mcp-profile ' to pin the profile at server start - that is the only way to change it; there is no runtime switch tool.

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

Input Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 2, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety bar is low; the description instead adds real behavioral context — the --db-path prerequisite and the fact that profile selection is immutable at runtime. Null-handling rules (null templateId, null tokenBudget means inherit through template then active PipelineProfile) are disclosed, though some of this drifts into return-shape territory rather than behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, but the body is a single sprawling sentence with stacked parentheticals and an ALL-CAPS 'AND' joining two unrelated payload descriptions (identity fields vs. render config). Splitting the return-field inventory from the usage note would make it far more scannable.

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, so the description carries the burden of explaining the return shape — and it does, field by field, including null semantics and the two toolSelection encodings. Combined with the stated prerequisite and the 'no runtime switch' constraint, an agent has everything needed to call and interpret this tool.

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?

The tool takes zero parameters, so per the rubric the baseline is 4. The description correctly adds no parameter guidance because none is needed.

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?

Opens with a specific verb+resource ('List the MCP profiles in the server's config DB') and enumerates the exact fields returned. No sibling tool in the list covers MCP profile configuration, so it is unambiguously distinguishable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

States the prerequisite ('Requires the server to be started with --db-path') and explains what to do with the results ('Use the ids with aicb mcp --mcp-profile <id> to pin the profile at server start'). It also pre-empts a fruitless search by stating there is no runtime switch tool. It never frames when to call this versus another tool, but no viable alternative exists.

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

Deploy Server