Skip to main content
Glama

conf_search

Read-onlyIdempotent

Search Confluence content with CQL queries and return one paginated result page with pagination metadata for navigating large result sets.

Instructions

Search content using CQL; returns one page with pagination metadata

Input Schema

NameRequiredDescriptionDefault
cqlYes
limitNo
startNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

C2.9/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that — results are a single page with pagination metadata — but says nothing about authorization requirements, result size limits, or whether indexing delays affect freshness.

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?

A single compact sentence with the action front-loaded and no filler. Its brevity is efficient, though the terseness contributes to the documentation gaps noted elsewhere.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a search tool whose required parameter is an entire query language and which has no output schema, the definition is thin: no CQL syntax hint, no description of the returned page or pagination token, and no guidance on paging through results. The annotations cover safety but not the operational detail an agent needs to call this correctly.

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

Parameters2/5

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

Schema description coverage is 0% across three parameters, so the description carries the full burden and largely fails: it never explains CQL syntax or capabilities, and does not connect "one page with pagination metadata" to the limit/start parameters or their defaults and bounds. The only schema-adjacent hint is the word "pagination".

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource ("Search content using CQL") and names the query mechanism, which separates it from the fetch-oriented siblings like conf_get_page and conf_get_children. It does not define what CQL is or what content types are searchable, but the core purpose is unambiguous.

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

Usage Guidelines2/5

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

There is no explicit when-to-use guidance: nothing says when to search versus walking the hierarchy with conf_get_children or fetching a known page with conf_get_page. Usage is only implied by the verb "Search", leaving the agent to infer the alternative-selection logic.

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