Skip to main content
Glama
gregordadera

aicb-roslyn-mcp

by gregordadera
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

List Tools and Facets

list_skills
Read-onlyIdempotent

Discover all tools this server exposes, grouped by pool state, facets, and skill bundles, to find specialized options or check if a tool is outOfPool.

Instructions

The server's capability map: a tools INDEX naming EVERY tool this server has - each exactly once, grouped into three lists by pool state (inPool.core = the tools every profile exposes, in reach-for-them order; inPool.extras = the rest of the active pool, alphabetical; outOfPool = exists but the active tool set does not expose it) - plus the sections that group them by name: the always-on navigation CORE (listed in no menu because it needs none), the task FACETS (id + guidance + template slot + the facet's tool menu), the cross-cutting guidance styles, and the legacy functional skill bundles. Use it to discover specialized long-tail tools (e.g. get_insight, find_by_concurrency_risk, coverage_gaps, find_unresolved_bindings) beyond that core - and to check whether ANY tool you want is merely in outOfPool rather than nonexistent. Tools outside the active pool become reachable via an MCP profile whose facet menu or bundle names them (see list_mcp_profiles / 'aicb mcp --mcp-profile '), or via the AICB_MCP_TOOLS override. By default the answer omits the per-tool descriptions, which is what makes it cheap; pass detail="full" when you need them. No session needed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
detailNoHow much per-tool text to include: "lean" (default) - bare names in their pool groups; "full" - additionally each tool's one-line description. Case-insensitive.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, closed-world, non-destructive), so the bar is lower. The description adds genuinely useful behavior: by default per-tool descriptions are omitted for cheapness, detail="full" includes them, and no session is needed.

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 intent is front-loaded ('capability map'), but the body is one very long sentence with deeply nested parentheses enumerating pool states and sections, which hurts scannability. It is information-dense but not efficiently structured.

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 describing the return shape, and it does: three pool-state lists, the navigation CORE, task FACETS, guidance styles, and legacy bundles. Nothing needed to call or interpret the result is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single `detail` parameter is fully documented in the schema, so baseline is 3. The description reinforces the lean-vs-full tradeoff and its cost rationale, but adds little format or syntax detail 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?

States a specific verb and resource - an index naming every tool the server has - and even enumerates the three pool groupings it returns. It distinguishes itself from the similar-sounding list_mcp_profiles and list_insights by describing a capability map rather than profiles or insights.

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 explicit when-to-use cases: discovering specialized long-tail tools (name examples) and checking whether a wanted tool is merely in outOfPool rather than nonexistent. It also explains the alternative paths (an MCP profile that names the tool, or the AICB_MCP_TOOLS override).

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