Connect WordPress directly to Amazon Bedrock using your own AWS account. Add a chat powered by
Claude, Amazon Nova or Titan, Meta Llama, Mistral or DeepSeek, let authenticated conversations use
governed tools through the Model Context Protocol, and check that the answers are still right after
you change something.
Model requests go from your WordPress server to the Amazon Bedrock endpoint you configure. The
plugin author does not operate an AI relay service, and no request passes through anyone else. It is
built for site owners, developers and teams already on AWS who want predictable requests and
security-focused defaults.
What you can build
- An internal assistant, or a public chatbot with explicit guest access
- An agent that answers from your own content and from approved MCP tools
- A WordPress MCP endpoint that clients such as Claude Code, Cursor or VS Code can read
Add the chat with the [ai_chat_bedrock] shortcode or the chat block, or let it float on every page
from a single setting.
Three things this does differently
It runs without storing AWS keys. An instance role, a task role or environment variables are
enough. Where keys are stored, they are encrypted, and Diagnostics generates the least-privilege
IAM policy this site actually needs rather than asking you to attach a broad managed policy.
It assumes a public chat will be abused. Every default below is the safe one, and each is a
setting you can change rather than a promise you have to trust:
- Guest access is off until you enable it, and the chat is hidden from visitors until it can
actually answer, so a half-finished setup is never public - Requests are rate limited per visitor and per profile, with optional per-role limits and an
optional daily site cap - Tools run on the server, so a browser cannot forge a tool result, and a tool that changes data
needs an explicit capability - External MCP tools are off for visitors, and the built-in MCP routes require authentication unless
you deliberately open read-only access - Input, history, token and tool-call limits are enforced on the server
- A visitor can stop a long answer, and the server stops the Bedrock request with it rather than
paying for text nobody will read
It can tell you whether an answer was good. Write questions whose right answer you already know
and run them: each goes through the pipeline the chat uses, and the result is reported by category,
so you can see which part of an answer changed after a prompt edit or a model swap. Every check is a
program, so nothing scores style or tone and no model is asked to judge another model. It runs from
the command line too and exits nonzero, which is what lets it gate a deployment.
Grounded in your own content
Point the chat at your published pages and it answers from them, citing what it used. Choose an
embedding model and it matches by meaning rather than by shared words, so “when will my parcel
arrive” can find a page titled “Getting parcels to you”. Questions the site does not cover return no
context, and the Conversations screen lists them as content gaps with a shortcut to draft the page
that is missing.
An MCP server, and an MCP client
The site can expose its own read-only tools to AI clients over JSON-RPC on protocol revision
2026-07-28, with anonymous access and OAuth both off by default. It can also call external MCP
servers and an Amazon Bedrock AgentCore Gateway, with no authentication, a bearer token stored
encrypted, or SigV4. Endpoints must be public HTTPS URLs.
Stored data and privacy
No custom table is created. The conversation log is optional and off by default; when enabled it
holds the 200 most recent exchanges in a WordPress option, with a retention window you set, and it
supports the WordPress personal-data export and erase tools. Debug mode records redacted metadata,
not prompts, responses or credentials. The Privacy Policy section
sets out what is sent, to whom, and what is kept.
What it costs, and how to watch it
The dashboard shows requests and tokens for the last seven days, broken down by the model that
actually answered, so a fallback or a profile on a different model is visible. Those counters are
kept for 30 days and contain no prompts, responses or identities.
Token counts are what Bedrock reported and are not a price estimate. Rate limiting reduces
accidental usage but guarantees nothing about your bill, so review Amazon Bedrock pricing and set
AWS Budgets before opening a chat to public traffic.
The rest
Streaming, managed prompts from Bedrock Prompt Management, a fallback model, multiple chats with
profiles, a floating launcher, the content tools, the WordPress abilities integration, WP-CLI, moving
a configuration between sites and the full MCP setup are covered in the FAQ tab, with their limits
stated.
Privacy Policy
Chat messages and the configured system prompt are sent to Amazon Bedrock. When MCP tools are enabled for authenticated users, relevant tool parameters are sent to the selected external MCP server and tool output is sent to Amazon Bedrock to complete the answer. Review AWS and each MCP provider’s privacy terms before use.
Conversation logging is disabled by default, and with it off no chat content is written to the database. When an administrator enables it, questions and answers are stored for the configured retention window, capped at the 200 most recent exchanges, and can be deleted per user or in full from the Conversations screen. Administrators are responsible for disclosing this recording to visitors.
The plugin creates no custom database tables; the optional log is kept in a WordPress option and is reachable through Tools > Export Personal Data and Erase Personal Data. Request limiting stores a salted hash-derived transient counter for each visitor for up to one minute. Debug logging is optional and records only redacted operational metadata. Administrators are responsible for disclosing these data flows and obtaining any consent required in their jurisdiction.
Screenshots
A grounded answer on the front end, citing the pages it used, with a timestamp, a copy action and a helpfulness control.
Dashboard with today's usage, a seven-day trend, a per-model breakdown of requests and tokens, and the setup checklist.
Grounding settings: site content search, semantic search with an embedding model, batch indexing progress, knowledge base and controlled abilities.
Diagnostics running a live Amazon Bedrock connectivity test, with round-trip time and tokens used.
Answer checks: run a set of questions whose right answer you know, and read the result by category. Every check is a program; no model judges another model.
The golden set itself: what each question expects, the text it must or must not contain, the page it should credit, and the match it must clear.
MCP screen split into Servers, AI clients, Tool policy and Activity, here showing the tool policy and audit log switch.
Content generator streaming a draft as it is written, before the post is created.
Conversations: the content gaps this site has, each with a shortcut to draft the missing page, above the log with its filters, CSV export and per-answer token counts.
Chat settings with the system prompt, an optional Amazon Bedrock managed prompt, suggested questions and streaming.
Per-role request limits, so editors and administrators can be given more requests per minute than anonymous visitors.
The least-privilege IAM policy generated for this site's own configuration, ready to paste into AWS.
Drafting a first set of pages from a description of the business. Every page is a draft, and nothing existing is touched.