Flat index of every Admin API module: operation count, the area it belongs to, what it owns and its known trap. This is a drill-down, NOT the entry point — call capability_map first to route a request to an area, then use this to see every module or list_operations(module) for one module's operations.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds meaningful behavioral context beyond that: the tool returns a flat index, includes metadata like area and ownership, and surfaces a 'known trap' per module. It also clarifies its role in the navigation flow. Slight deduction for not describing the exact response shape, since there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences carry substantial information: what the tool returns, its role, and the routing rule. The core purpose is front-loaded, and every clause earns its place. No filler or repetition of the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters and a readOnly annotation, the only open question is what results look like; the description answers that by listing the elements of the index and by linking the tool into the larger workflow (capability_map first, list_operations for a single module). An agent can invoke and interpret this correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema-only semantics are irrelevant. The description correctly focuses on what the tool returns rather than inputs, which is the right burden given the empty schema. A 4 matches the baseline for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Flat index of every Admin API module,' and enumerates exactly what it provides (operation count, area, ownership, known trap). It also explicitly contrasts itself with sibling tools (capability_map, list_operations), making it unmistakable what this tool is for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives direct routing guidance: it is a drill-down, NOT the entry point, and tells the agent to call capability_map first. It also names the alternative for per-module operation listing (list_operations(module)), so when-to-use vs. when-not-to-use is fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Every tool has a clearly scoped target: discovery, schema introspection, validation, execution, docs, and image services are all distinct. Closely related tools like list_modules/list_operations/search_operations and get_scenario_node_schema/check_scenario_node_payload are explicitly differentiated by their descriptions.
Almost all tools follow a predictable verb_noun snake_case pattern such as get_*, list_*, search_*, generate_*, and import_*. The lone noun-style capability_map and the unique check_ verb are minor deviations rather than a broken convention.
16 tools is slightly above the ideal 3–15 range, but the count is justified by the broad Admin API surface covering discovery, schemas, validation, execution, recipes, docs, and images. It is dense but not bloated.
The set covers the full discovery–schema–recipe–execute lifecycle, plus validation for opaque polymorphic types and product documentation lookup. invoke_operation delegates to the entire Admin API, so there are no dead ends; any arguable gaps are reachable through that operation.
