Skip to main content

Use Cases

The eight tools in the Tools Reference are deliberately small building blocks. This page shows what people actually do with them - the workflows that repay the setup effort, with a prompt you can paste to try each one.

Everything here runs entirely inside Confluence, as you, under your own permissions. Nothing leaves your Atlassian site.

Two rules apply throughout:

  • Read is free, write deserves review. Reading costs you nothing but a tool call. Before any prompt that creates or updates a page, ask the AI to show you what it plans to write first.
  • Name the destination. Space key, and a parent page ID if you have one. Page titles repeat across spaces, and "put it in the docs space" is how the wrong page gets edited.

For teams working in a chat client​

These work in Claude Desktop or any chat-based MCP client. No IDE, no repository, no code.

Answer questions from your own documentation​

The most common thing people use this for, and the least glamorous: finding the one paragraph you need without opening six tabs. The AI searches Confluence, reads the pages worth reading, and answers with the content in front of it rather than from memory.

"Search Confluence for our data retention policy, read the most recent page you find, and tell me how long we keep customer support transcripts"

This works best when you point at something specific. If a search comes back empty, the content is usually there and your keywords missed - rephrase with the words the author would have used. See Your prompt does the heavy lifting.

Recover a decision from the comment thread​

Decisions frequently do not live in the page body. They live in the comments underneath it, three replies down, six months ago. The page still describes the original plan; the comment explains why the team went the other way.

Because the AI can read a page and its comments together, it can reconstruct what was actually settled rather than what was originally proposed.

"Open the 'Auth Service Rollout' page, read its comments as well as the body, and tell me what we actually decided about the migration cutover date - flag anywhere the comments contradict the page"

Worth knowing: comment bodies come back in full, never truncated, but only the top-level comments are returned at first. Each one is labelled with how many replies it has, and the AI has to make a second call per thread to read them. On a heavily discussed page, say which threads you care about - "open the ones with the most replies" - rather than expecting the whole discussion in one pass.

Inline comments (the ones anchored to highlighted text) are a separate list, and can be filtered to the unresolved ones, which is often the faster route to what is still being argued about:

"Show me the unresolved inline comments on the 'Auth Service Rollout' page and what text each one is attached to"

Turn a conversation into a properly formatted page​

You have just worked something out in chat - a plan, a set of notes, a comparison. Rather than copy-pasting into the editor and reformatting, have it written straight into Confluence.

The page body is Confluence Storage Format, which means you can ask for real Confluence structure and get it: headings, tables, info and warning panels, expandable sections, a table of contents. You are not limited to what plain text can express.

"Create a page called 'Q3 Vendor Comparison' in the OPS space under page 445123. Use a table of contents at the top, a section per vendor with the pricing table we just built, and put the two open risks in a warning panel at the end."

Ask to see the outline before it writes if the page matters.

Find documentation that has gone stale​

Search takes CQL, not just keywords, which turns it into a reporting tool. Date fields accept relative forms like now("-180d"), so you can ask questions about the state of a space rather than its contents.

"Search the ENG space for pages that haven't been modified in over a year, sorted oldest first. Give me the top 20 as a list with title, space and last modified date, and tell me which ones look like they describe systems we may no longer run."

Two other CQL patterns that are useful here: creator = currentUser() to find your own pages, and ancestor = <pageId> to scope a search to everything beneath a particular page - handy when you want to audit one section of a space rather than all of it.

The AI's judgement about which pages are obsolete is a starting point for a human review, not a verdict.

Review a page without changing it​

There is a safer alternative to letting an AI edit your documentation: have it read the page and leave a comment instead. Nothing is overwritten, the author stays in control, and the feedback lands where the discussion already happens.

"Read the 'New Starter Setup' page. Check it against the 'IT Access Request' page and tell me where the two disagree. If you find real contradictions, add a comment on the New Starter page listing them - phrased as questions, not corrections."

This is a good first write to try if you are nervous about giving an AI write access at all. Comments are additive and easy to delete.

Orient someone new to a space​

New joiners do not know what exists, which is exactly what the AI can find out for them by listing spaces and searching across them.

"List the spaces I can see. Then in the PLATFORM space, find the pages that explain the overall architecture and how the deployment process works, and give me a reading order with a one-line summary of each."

For developers working in an IDE​

These assume an MCP-capable coding agent with your repository open alongside Confluence.

Use your documentation as a constraint on generated code​

This is the highest-value pattern here, and the one most people miss. Instead of writing code and checking it against the standards afterwards, load the standards first and generate against them.

The trick is to verify the AI actually absorbed the document before you let it write anything:

"Find our Backend Guidelines page in the ENG space and read it. Before writing any code, summarise the rules it sets for error handling and logging, so I can confirm you've read it correctly."

Then, once you are satisfied:

"Now implement the new endpoint in src/orders/ following those rules. Afterwards, explain which specific guideline drove each decision."

That closing instruction matters. It surfaces the cases where the AI cited a rule that is not in the document.

The same pattern applies to business logic. When the rules for something live in Confluence and not in the code, pointing the agent at the page beats explaining it in the prompt, and it stays correct when the page changes.

Publish a spec, plan, or runbook from the repository​

The agent has your codebase. Confluence is where the rest of the team reads things. Documents that are derived from code - migration plans, endpoint inventories, architecture decision records, runbooks - can be generated from the source and written directly to a page.

"Analyse the handlers in src/api/ and create a page called 'Payments API Endpoint Inventory' in the ENG space under page 778901. One section per endpoint with route, method, parameters and a response example, then a summary table of all endpoints at the end."

Landing it in Confluence rather than a chat window is the point: it becomes something the team can review, comment on and correct.

Be precise about space_key and parent_page_id. Identically titled pages in different parts of a space are the usual cause of an update going to the wrong place.

Draft release notes from what actually changed​

Release notes get written from memory, late, by whoever is left. The agent can read the diff, the commit range or the changelog in your working tree and produce the page from what genuinely shipped.

"Look at the commits since the v4.2 tag. Create a page called 'Release 4.3' in the PRODUCT space under page 112233, grouped into New, Changed and Fixed, written for customers rather than engineers. Show me the draft before you create it."

Update a page when the code moves under it​

Documentation drifts because updating it is a separate chore. When the agent is already in the file that changed, amending the page is one more instruction.

Updating requires the page's current version number, which means the agent has to read the page before it can write to it. That is a useful safety property - it cannot blindly overwrite something it has not seen.

"The retry logic in src/queue/worker.ts changed - it's now exponential backoff with a 5-attempt cap. Read the 'Queue Processing' page in the ENG space, show me a diff of the change you'd make to the 'Failure Handling' section, and only update it once I approve."

Ask for the diff, not the result. On a page with a lot of Confluence structure - macros, panels, layouts, embedded content - a full-body rewrite risks losing formatting the AI did not realise was there. Reviewing the change before it lands is cheap. If a page is dense with macros and you only want to add something, adding a comment or a new child page is the lower-risk move.

Patterns that make these work​

Drawn from what people report after a few weeks of use.

PatternWhy
Start read-only for the first weekBuild trust in what the search finds before you let it write anything
Ask for a dry run before any write"Show me what you'd create, don't create it yet" catches misread instructions for free
Search before creating"Check whether a page about this already exists; if it does, suggest updating it instead" prevents duplicate pages
Put your defaults in the client's rules fileSpace keys and frequent parent page IDs, so you stop restating them every prompt
Be specific about scope"Bugs in the ENG space from the last 14 days" works; "tell me about our docs" does not
Prefer comments over edits when unsureAdditive, reversible, and it puts a human in the loop by design

What this is not for​

Being straight about the edges, so you do not spend an afternoon finding them yourself:

  • Attachments, images, and labels. There are no tools for these. The AI can read a page's labels as metadata but cannot add them, and cannot upload or retrieve files.
  • Deleting anything. There are no delete tools, by design. Cleanup stays manual.
  • Moving or restructuring pages. No move or reparent tool. New pages can be nested under a parent at creation; existing pages cannot be relocated.
  • Writing inline comments. Inline comments can be read, including the page text they are anchored to and their resolution status. Posting one is not supported: confluence_add_comment only posts a top-level footer comment, and cannot anchor it to a specific phrase or reply within a thread.
  • Bulk generation. Creating pages in large batches will run into Confluence's own API rate limits, and every page still needs a human to check it. Small batches, reviewed, work better than a hundred pages nobody trusts.
  • Anything outside Confluence. This app covers Confluence only. It does not reach Jira, Bitbucket, or other Atlassian products.