Skip to main content
Glama

IA-QA — 152 QA & Dev Tools for AI Agents

fetch_confluence_page

Read-only

Fetch a Confluence page and return its content as clean Markdown. Accepts a numeric page_id or a full page URL. Optionally lists direct child pages. BYOK — credentials transit in-memory only, never stored.

Input Schema

NameRequiredDescriptionDefault
page_idNoConfluence page ID (numeric string), e.g. "123456789"
page_urlNoFull Confluence page URL (alternative to page_id), e.g. "https://mycompany.atlassian.net/wiki/spaces/ENG/pages/123456789"
confluence_emailYesAtlassian account email (same credentials as Jira)
confluence_tokenYesAtlassian API token
include_childrenNoList direct child pages (id + title) (default: false)
confluence_base_urlYesAtlassian base URL, e.g. "https://mycompany.atlassian.net"

Output Schema

NameRequiredDescriptionDefault
urlNo
titleNo
page_idNo
childrenNo
markdownNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / examples
      Added value: +[
      +  {
      +    "confluence_base_url": "https://yourcompany.atlassian.net",
      +    "confluence_email": "you@example.com",
      +    "confluence_token": "<your-atlassian-token>",
      +    "page_id": "123456"
      +  }
      +]
  2. Changed1 schema field changed
    • addedOutput schema / properties
      Added value: +{
      +  "children": {
      +    "items": {
      +      "type": "object"
      +    },
      +    "type": "array"
      +  },
      +  "markdown": {
      +    "type": "string"
      +  },
      +  "page_id": {
      +    "type": "string"
      +  },
      +  "title": {
      +    "type": "string"
      +  },
      +  "url": {
      +    "type": "string"
      +  }
      +}
  3. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": true,
      +  "type": "object"
      +}
  4. Added

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavioral context beyond the annotations: credentials transit in-memory only and are never stored (BYOK), which matters for an agent handling secrets. It still omits failure behavior (auth errors, rate limits, missing page).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences with zero waste: purpose and output format first, then input modes, then the optional flag, then the credential-handling caveat. Every sentence adds information and nothing is buried.

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

Completeness4/5

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

With an output schema present, the description needn't explain return structure, and it still notes the Markdown format for the page body. All required auth parameters are accounted for by the schema and reinforced by the BYOK sentence. The only gap is handling of the optional child listing's output shape and error paths.

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 description coverage is 100%, so the schema already documents all six parameters including the page_id/page_url alternatives and include_children default. The description restates the page_id-or-URL choice and the optional child listing without adding format details (e.g. that page_id must be numeric, or how to extract the ID from a URL). Baseline 3 applies when the schema carries the load.

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 names a specific verb+resource ("Fetch a Confluence page") and adds the return format ("clean Markdown"), plus the two input modes (page_id or URL). It is unambiguous about what the call does, but never differentiates itself from the sibling create_confluence_page or fetch_jira_issue, so an agent must infer the fetch-vs-create split.

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

Usage Guidelines3/5

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

"Accepts a numeric page_id or a full page URL" and "Optionally lists direct child pages" imply when the flags apply, but there is no explicit when-to-use statement, no prerequisite guidance (credentials are required, not optional), and no mention of alternatives such as using a different tool to create or search pages.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.