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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Add a comment to a Confluence page,' with no mention of side effects, required permissions, error handling, or whether the comment is appended or replaces existing comments. As a mutation tool, this lack of detail is a significant gap.

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?

The description is a single sentence with no unnecessary words. It is perfectly concise and front-loaded, stating the core action immediately. Every word earns its place.

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?

For a mutation tool with no annotations, no output schema, and zero parameter descriptions, the description is too minimal. It lacks information about return values, error conditions, authentication requirements, and how this action fits with sibling tools. The tool is likely simple, but the description does not provide enough context for reliable invocation.

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 input schema has 0% description coverage, and the description does not mention either parameter (pageId or comment). It adds no meaning beyond the parameter names, which are already self-explanatory. The description does not compensate for the schema's lack of semantic detail.

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 clearly states the action: add a comment to a Confluence page. It names the specific verb and resource, making the purpose obvious. However, it does not explicitly distinguish from sibling tools like create_page or update_page, although the verb 'add' and object 'comment' are specific enough for basic selection.

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 offers no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions. The tool's purpose is implied by its name, but explicit usage instructions are absent.

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

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

With no annotations, the description carries the full burden, but it only restates the basic create action. It does not disclose behavioral traits such as space/parent requirements, validation rules, side effects, or return behavior, which is insufficient for a mutation tool.

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?

The description is a single short sentence, which is concise, but it essentially restates the tool name. It is under-specified rather than usefully concise, providing minimal value beyond the name itself.

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?

The description is far too sparse for a tool with 4 parameters, no annotations, and no output schema. It doesn't explain required fields, how pages are nested, what spaceKey and parentId mean, or what happens on success/failure, making it incomplete for correct invocation.

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 input schema contains four properties with no descriptions, and the tool description does not mention any of them. With 0% schema description coverage, the description fails to compensate, leaving the agent to guess what body, title, parentId, and spaceKey mean.

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 uses the specific verb 'Create' and the resource 'a Confluence page,' clearly distinguishing it from siblings like get, search, update, add_comment, and list_spaces. It directly states the action, so purpose is clear.

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?

No guidance is provided on when to use this tool versus alternatives. There is no mention of context, prerequisites, exclusions, or situations where a different tool would be more appropriate.

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

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

With no annotations, the description carries the full burden. 'Get' implies a read-only operation, which is transparent. However, it does not disclose error behavior, return format, or precedence rules when multiple parameters are provided. This is minimal but adequate for a simple read tool.

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?

The entire description is one concise sentence that states the purpose and the two modes of lookup without any filler. Every word earns its place.

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?

For a get-by-identifier tool, the description is reasonably complete, but the combination of three optional parameters with no required fields and no output schema creates ambiguity about precedence and combined usage. The description does not address these edge cases, leaving minor but important gaps.

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 coverage is 0%, so the description must compensate. It adds meaning by indicating that 'spaceKey + title' are paired together as an alternative to 'pageId'. However, it fails to clarify whether parameters are mutually exclusive, what happens if both are given, or whether spaceKey alone is valid. Some semantics added, but incomplete.

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 clearly states the verb 'Get' and the resource 'Confluence page', and specifies two lookup methods: by ID or by spaceKey + title. This distinguishes it sharply from siblings like search, create, update, and comment, which have different actions.

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 provides clear context: use this tool when you have a page ID or a spaceKey/title pair. It does not explicitly mention alternatives or when not to use it (e.g., use search when you lack identifiers), but the context is sufficiently clear. Missing explicit exclusions prevents a 5.

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

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

With no annotations, the description carries the full burden of disclosing behavior. It explicitly indicates a read operation ('List') and suggests a practical use case, but it fails to mention pagination behavior, return format, or whether results are limited to keys only. This is moderate transparency, lacking depth.

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?

The description is a single, compact sentence that front-loads the core action ('List Confluence spaces') and adds a useful parenthetical note. Every word earns its place; there is no filler or redundancy.

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?

For a simple list tool, the description is adequate but sparse. It doesn't describe the output schema or pagination details, which are not covered elsewhere. However, given the simplicity of the tool and the presence of limit/start parameters in the schema, a 3 is fair—it meets the minimum but leaves gaps.

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 schema provides no descriptions for the parameters, and the description does not mention 'limit' or 'start' at all. While the names are somewhat self-explanatory, the description adds zero semantic value beyond the schema, which is a significant gap given the 0% schema description coverage.

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 clearly states a specific action ('List') and resource ('Confluence spaces'), making the tool's purpose immediately obvious. The parenthetical 'useful to discover valid space keys' adds practical context and distinguishes this from sibling tools like page retrieval or search.

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 phrase 'useful to discover valid space keys' provides clear context for when to use this tool (e.g., before other operations requiring space keys). However, it does not explicitly contrast with alternatives or state exclusions, so it falls short of a 5.

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

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

No annotations are present, so the description carries the full burden of behavioral disclosure. It only states the basic search action and mentions CQL, but does not disclose what the response looks like, how pagination works, or any required permissions. The description adds no meaningful behavioral context beyond the function itself.

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?

The description is a single short sentence, but this brevity results from under-specification rather than effective conciseness. It omits crucial details that would require additional sentences to explain. The structure does not front-load information beyond the bare minimum.

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?

Given the lack of annotations and output schema, the description is profoundly incomplete. It does not explain how to compose CQL, what the returned data structure is, or how limit and start affect results. An agent would be unable to use this tool reliably without guessing or seeking external documentation.

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%, and the description does not explain any parameters. It refers to CQL but fails to clarify the roles of cql, limit, and start. The agent is left with only schema type constraints, which are insufficient for understanding how to build queries or interpret pagination parameters.

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 clearly states the tool's function: 'Search Confluence content with CQL.' This identifies the verb ('search'), the resource ('Confluence content'), and the method ('CQL'), effectively distinguishing it from sibling tools like confluence_get_page and confluence_create_page.

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 provides no guidance on when to use this tool versus alternatives. It does not mention that this should be used for general search queries instead of specific page retrieval, nor does it reference any sibling tools or conditions. Usage context is only implied by the tool's name.

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

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

The description discloses an important side-effect: automatic version increment. However, with no annotations, it does not mention required permissions, behavior if the page does not exist, or whether the body is fully replaced. This leaves several behavioral aspects unexplained.

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?

The description is two concise sentences, front-loaded with the action, and includes the useful versioning side-effect without any waste. Every word contributes to understanding.

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?

For a simple update tool, the description covers the core purpose and a key side-effect, but lacks details about permissions, error handling, and return value. With no output schema or annotations, these omissions mean the description is adequate but not fully complete.

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 description adds meaning to the title and body parameters by saying 'title and/or body', indicating they are the updatable fields. However, it does not explain the pageId parameter or provide format constraints (e.g., body markup), and with 0% schema coverage, the description only partially compensates for the lack of parameter documentation.

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 clearly states the action (update), the resource (Confluence page), and the specific fields affected (title and/or body). This distinguishes it from sibling tools like create_page, get_page, and search by specifying the exact mutation scope.

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 verb 'update' implies this tool is for modifying existing pages, which differentiates it from create_page, but the description does not explicitly state when to use it versus alternatives or provide exclusions. There is no guidance about prerequisites like the page needing to exist.

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