confluence_list_spacesRetrieve Confluence spaces visible to the authenticated user for browsing or selection. Supports pagination with start and limit to page through large space lists.
List spaces visible to the authenticated user. Use start and limit for pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | ||
| limit | No | ||
| start | No | ||
| expand | No | ||
| status | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description's only added behavioral fact is the visibility/authorization scoping, which is useful but thin; nothing is said about ordering, default result volume, or how pagination terminates.
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 tight sentences with no filler, and the scoping constraint is front-loaded before the pagination note. Sizing is right for the complexity, though the space could have been spent on the undocumented parameters.
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?
Five parameters at 0% schema coverage, no output schema, and no annotations explaining the data model — the description covers only two of five inputs. For a list tool whose filtering options (type, status, expand) materially change results, that is a substantial omission.
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?
Schema description coverage is 0% across 5 parameters, so the description must compensate and it largely does not. It explains only start and limit; type, expand and status remain completely undocumented anywhere, leaving an agent to guess at their accepted values.
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?
States a specific verb and resource ("List spaces") plus a scope qualifier ("visible to the authenticated user") that tells the agent results are permission-filtered. Siblings like confluence_search and confluence_get_page are obviously different operations, so no explicit differentiation is needed.
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 second sentence gives concrete pagination guidance (start and limit), which is genuinely actionable. However, it never says when to reach for this tool versus confluence_search or confluence_rest for space discovery, and there are no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.