The New -
WebCenter Content MCP Server 2.0!
WebCenter Content holds a lot — documents, metadata, folders, workflows, taxonomies — and historically you accessed it through a browser. It's had a number of names over the years but at it's core it has managed to retain its original admin user UI from the 90's & I should know I was there using it..
AND.. With AI you now have the ability to more easily interact with data through chat & The WebCenter Content MCP Server 2.0.
It puts WebCenter Content behind the Model Context Protocol, so an AI agent ie Claude Desktop, or anything that can use MCP can search, retrieve, classify, and run workflows against your repository directly, in plain language.
If you are interested in MCP what it can do with WebCenter & have been waiting for a reason to point an agent at your content, this is it.
MCP Architected Tools
The thing that makes V2.0 so reliable in front of an agent is the shape of its tool surface. This MCP Server has 17 tools, each built around a task rather than pointed at a raw REST endpoint.
That matters alot more than it sounds.
It's easy to mechanically expose WebCenter Content's REST API as one tool per endpoint - dozens of them, one for every shape of every call.
(I did this for Oracle Integration Cloud because that made sense: https://bitmapbytes.com/oracle-integration-cloud-webcenter-content-adapter/)
But.. an agent handed that list has to know that fetching a document by its name and fetching it by revision ID are different tools, and pick correctly every single time it has been prompted by users who ask/prompt in different ways.
MCP V2.0 doesn't have an API Map
There is one tool where you tell it which document with a reference `{dDocName}` or `{dID}`.. and it sorts out the rest. Lifecycle operations ie delete, check-out, expire etc all sit behind another tool with an action.
An agent choosing between the well-named, well-described tools is dramatically more reliable than one choosing between dozens of near-duplicates. Which inturn means fewer wrong turns, fewer "I'll just try this one" moments, and tool descriptions short enough to actually fit in the model's context.
Don't mirror the endpoint list. Group by the job the caller is trying to do, and let a discriminated argument carry the variation.
What can an agent can actually do
Rather than walking you through all the tools, here's a summary of what your agent could do when hooked up via the MCP to your WebCenter instance once it's been pointed at your repository.
Here are some example prompts:
- "Find every contract signed last quarter that hasn't been reviewed by legal, and download the three oldest to my Desktop."
- "Take the PDFs in this folder, file them under Marketing > Q3, set the security group to Public, and check them in."
- "Approve the three documents waiting on me, and reject the one from outside our organization with a short note explaining why."
Now none of those are a single tool call.. Each one is the agent searching, filtering, fetching, updating, or approving - behind the scenes the agent is picking the right tools and stitching them together!
Today the agent doesn't start from scratch!
V2.0 ships three preset modes you can switch it into:
- Curator for organizing content.
- Auditor for finding problems
- Migrator for moving things between places.
Flip it into auditor mode and the agent already knows what an auditor would look for — inconsistent security groups, orphaned metadata, mis-classified documents — without you having to spell any of it out.
Auth that matches how WCC is deployed
V2.0 has three authentication modes, so it fits whatever your WebCenter Content sits behind:
Basic auth
Username and password, for on-prem WCC.
Simple, and the right call for plenty of installs.
OAuth 2.1, inbound
The server can act as an OAuth Resource Server (RFC 9728), validating bearer tokens from MCP clients with proper audience binding (RFC 8707).
OAuth 2.1, outbound
The server can be an OAuth client to your authorization server ie Oracle IDCS with PKCE and rotated refresh tokens.
The part I care about most and believe is the most powerful when it comes to chat is identity per-user. With OAuth wired, the agent acts as the actual signed-in user, so that WebCenter Content's own security model and audit trail behave exactly the way they were designed to; there is no shared service account flattening every action into one identity. And the tokens stay where they belong. An inbound MCP token is never forwarded to WCC; an outbound WCC token is never handed back to an MCP client.
In the repo I've added an operator runbook for exactly how to set it up: `docs/operators/oauth-setup.md` - there is also an old generic post also covering how to set this up.
The guardrails — because an agent is driving
When a person uses an API, they are a sanity check on every call. But.. when an agent uses it, those checks are gone. There are a few options you have but for now this is what I've implemented to help steer the calls:
Path policy...
Every filesystem touch ie a download target, an upload source - runs through a policy. In stdio mode it is confined to the directories your MCP client actually advertised; in hosted mode filesystem access is denied.
An agent cannot talk the server into writing somewhere it shouldn't.
Outbound URLs - OAuth discovery, for example are refused if they resolve to a private, loopback, link-local, or cloud-metadata addresses, with double-resolve detection for DNS rebinding.
Rate limiting - Token-bucket middleware on the HTTP transport, with a proper 429 and Retry-After.
Audit log - Every tool call, token validation, consent decision, transport rejection, and path-policy refusal emits a structured JSON line on stderr. When something strange happens, there is a record of it.
Workflow tools & bulk operations
I've also introduced a new class of tool: it applies a metadata patch across many documents in one call... But! What happens when it is halfway through and something fails? It doesn't stop dead and lose its place. It returns a partial-failure result and also what succeeded, alongside a signed resume token.
When you hand that token back it carries on from where it stopped. It emits progress notifications as it runs, and can be cancelled end-to-end.
The engine underneath is reusable..
which is the whole point.
Two ways in, one path through
V2.0 speaks two transports:
- stdio
Designed for desktop clients like Claude Desktop — the server runs as a local process. - Streamable HTTP
Designed for teams and hosted deployments — built to the current MCP spec, with an Origin allowlist, anti-DNS-rebinding host checks, and protocol-version negotiation.
both transports route through one dispatch path. There is a single `dispatchToolCall`, and an architecture test fails the build the moment anyone adds a second one. So this means that stdio and the Streamable HTTP behaviour cannot drift apart.
Whatever you test on one, you get on the other.
Trying it today
You can find the full walkthrough — including the exact config blocks here:
Where this goes next?
If you take 2.0 for a spin, I would genuinely like to hear how it goes and especially how it breaks!
So: clone it, point an agent at your WebCenter Content instance, and file an issue when something is wrong. - Also if you liked this post and are using this repo a star on it helps to validate that there are people trying it out or it's in use today! :)..