Let Cursor, Codex, or Claude Code review plugin updates, investigate errors, check backups, understand traffic, and carry out supported hosting tasks from the AI tools you already use.
We're inviting existing Pressidium customers to try the Pressidium MCP beta and help shape what comes next. Start with one website and a task you already perform in the Dashboard. Then tell us what worked, what was confusing, and what you wish your assistant could do.
What is the Pressidium MCP?
Model Context Protocol (MCP) lets an AI application connect to external tools and data.
Pressidium MCP is an MCP server that gives a compatible assistant access to supported Pressidium Dashboard operations through your Dashboard account.
For example, you can ask:
Which plugins on my website have available updates or reported vulnerabilities? Show me the findings without changing anything. |
Your assistant can retrieve the available information and explain it in the conversation. You can then ask follow-up questions or request a specific action.
Pressidium hosts the MCP server. You configure the connection in your AI application; you do not deploy a server or install a WordPress plugin for this connection.
Your existing Pressidium Dashboard remains available alongside it.
The optional Pressidium Agent Skills package adds reusable workflows such as Site Guardian and Performance Review. MCP provides the tools; skills give your assistant instructions for combining them into a useful review.
What can you do with it?
Task | Examples |
Review your websites | List sites, inspect environments, and check WordPress and PHP versions. |
Plan maintenance | Review plugin updates and reported vulnerabilities, inspect available WordPress updates, and prepare a maintenance plan. |
Work with backups | List and create backups, request downloads, and restore a selected backup. |
Investigate issues | Read available access and error logs, review analytics, and inspect recent account activity where your role permits it. |
Review performance and growth | Examine traffic, caching metrics, monthly usage, and existing performance test results; request a new performance test. |
Manage hosting | Work with staging, caching, domains, certificates, and supported site settings. |
Work with standalone EDGE sites | Inspect EDGE sites and origins, review traffic and security analytics, and use supported EDGE operations. |
Availability depends on the product, account permissions, environment, and data exposed by the Dashboard. Managed Hosting and standalone EDGE sites support different operations.
Before you connect
You need:
A Pressidium Dashboard account with access to the team and websites you want to use.
A compatible AI application (The setup options below cover Cursor, Claude Code, and Codex CLI or its IDE extension).
Dashboard email and password authentication. The beta does not currently support MFA login, API token authentication, or MCP OAuth.
The Pressidium Agent Skills package, if you want the named workflows. You can test the MCP connection before installing skills.
Important security considerations
Use a dedicated Dashboard account for the beta, with only the access it needs. Keep MFA enabled on your regular account. If your organization requires MFA for every account, contact Pressidium Support before proceeding; the current authentication method may not fit your policy.
The connection can expose website information and logs to your chosen AI application for processing. Use an application and account appropriate for your organization's data requirements.
Keep passwords in local configuration or credential storage. Never enter your Dashboard password into an AI conversation, screenshot, or Git repository.
The beta includes tools that can modify live sites. Keep tool approval enabled in your AI application and review the target website, environment, and requested action before allowing changes.
Asking for a read-only review is useful guidance, but it does not turn the connection into a technically enforced read-only account.
Choose your application
The Pressidium MCP beta can currently be configured with the applications below.
Application | Setup guide | Beta guidance |
Cursor | Supports remote HTTP MCP with the custom authentication headers required by the beta. | |
Claude Code | Supports HTTP MCP and environment variables in request headers. | |
Codex CLI and IDE extension | Supports HTTP headers sourced from environment variables. |
Choose your favorite application and follow its dedicated setup guide. After connecting, return to this guide to try workflows and understand operation results.
What about Claude web and Claude custom connectors?
The Pressidium Dashboard MCP beta cannot currently be connected directly through Claude's remote Custom Connector interface.
The beta authenticates using custom X-Pressidium-Email and X-Pressidium-Password HTTP headers. The current Claude remote connector setup does not provide a way to configure these headers, and the Pressidium MCP server does not currently support MCP OAuth.
Attempting to add the Pressidium MCP URL directly may therefore return an authentication error such as 403 Forbidden.
For Claude, use Claude Code and follow the dedicated setup guide above.
Connection details
All supported applications connect to the same Pressidium MCP server.
Use this exact URL, including /dashboard:
https://mcp-dashboard.pressidium.com/dashboard
Setting | Value |
Transport | Streamable HTTP over HTTPS |
Email header |
|
Password header |
|
The individual setup guides explain how to provide these authentication headers securely in each application.
This URL connects to your real Pressidium account. To work on a website's staging environment, specify staging in your request. You do not need a different MCP server URL.
Verify your connection
Start with this prompt:
Use pressidium_whoami to verify my connection and show the selected team if available. Then use pressidium_list_sites to list the websites I can access. Include website names and whether each is Managed Hosting or standalone EDGE. Do not change any website settings.
Check that the account, team, and websites match what you expect in the Dashboard. Inspect the actual tool results as well as the assistant's summary.
If you belong to multiple teams, ask:
List my Pressidium teams. Show me their names and ask which team to select before continuing.
After choosing a team, ask the assistant to select it and list its sites again. For larger accounts, ask it to continue through all available pages and state whether the list is complete.
Inspect one website
Next, choose one website:
Inspect the production environment of the Pressidium website my-site. Show its mapped domains, WordPress version, PHP version, and whether staging exists. Report missing information as unavailable. Do not make changes.
Replace my-site with the website name returned by Pressidium.
If you provide a domain instead, ask the assistant to resolve it to the correct website first.
For a standalone EDGE site, use the returned site ID.
Install Pressidium Agent Skills
Skills are optional for individual MCP requests and recommended for the named workflows below. The beta package contains 38 skills: 29 building blocks and 9 combined workflows.
Request skills-pressidium-mcp-dashboard.zip from Pressidium Support through your usual support channel.
Extract it and locate the pressidium folder containing blocks and composites. Keep the complete package together so referenced files remain available.
Keep the complete package together so referenced files remain available.
Skill installation differs between applications. Follow the Agent Skills instructions in the setup guide for your chosen application.
Try a named workflow
Use the installed Pressidium Site Guardian skill to review my-site in production. Start with inspection only. Summarize the findings and proposed next steps, and ask before taking any action that changes the site.
If the assistant cannot find the skill, check its discovery list and installation path. A working MCP connection and a successful skill installation are separate checks.
Available workflows
The package includes these nine combined workflows.
The prompts below are suggested ways to use them. The installed skill instructions define their exact scope.
Workflow | Suggested request |
Site Guardian | “Review this website and prioritize what needs attention.” |
Backup Guardian | “Review the available backups before I begin maintenance.” |
Plugin Auditor | “Review available plugin updates and reported vulnerabilities.” |
Maintenance Advisor | “Help me prepare a maintenance plan for this website.” |
Performance Review | “Review the available performance evidence and explain the findings.” |
Reliability Engineer | “Investigate recent errors using the available logs and activity.” |
Growth Monitor | “Explain recent traffic and usage trends.” |
Staging Validator | “Review the available staging evidence before a deployment decision.” |
Capacity Advisor | “Review current usage against the available plan limits.” |
Practical examples to try
These are example requests, not recorded results.
Replace website names, domains, dates, and IDs with your own. Ask the assistant to state its evidence and any missing data.
1. Review plugins across your websites
Review plugin information across my accessible Managed Hosting websites. Identify sites with reported vulnerable plugins or available updates. Group the findings by website, explain which items deserve attention first, and state any coverage limits. Do not update, activate, or deactivate plugins.
Use this to build a maintenance queue. Reported vulnerability data is not a complete security audit or proof that an unflagged site is secure.
2. Check backups before maintenance
List the available backups for my-site, production, with their IDs and creation times. Tell me how old the most recent backup is. Do not create or restore anything yet.
When ready, request a specific action:
Create a new backup of my-site, production, with the comment “Before planned maintenance”. Track the operation and report whether it completed. If completion cannot be verified, report the job ID and current status instead of submitting another backup.
A backup listing confirms available backup records; it does not verify recoverability through a restore test.
3. Investigate recent errors
Investigate recent 5xx responses for my-site, production. Inspect available access logs and relevant error logs, and compare with recent analytics. Identify affected paths and recurring messages. Distinguish observations from possible causes, state the time range and sample limits, and recommend next checks. Do not make changes.
For logs, the assistant can request inline output so the returned lines are available in the conversation. Inline results are capped at 200 lines and may be a filtered sample, not a complete incident timeline.
4. Understand performance before changing settings
Review performance and cache analytics for my-site, production, over the last day. Also inspect the most recent available mobile PerfAudit results. Explain any concerns supported by the data, separate test results from traffic analytics, and suggest the next investigation step. Do not start a new test or change settings.
To collect a fresh measurement:
Start a mobile PerfAudit test for my-site. Track its status, and retrieve the summary when available. Tell me if results are still pending.
An empty test history means no results were returned. It does not mean the site passed a performance test. The Pressidium Performance Audit Service is website-scoped; do not assume a request for staging changes the tested environment. Check the test URL.
5. Review growth and capacity
Review my current team usage against its plan limits. For my-site, production, summarize the available monthly visits, bandwidth, and disk usage for the last three months. Identify increases worth investigating, show the units, and state any missing months or limits.
Replace my-site with the name of the site you want to review.
Monthly Managed Hosting reports are production-only. Standalone EDGE has its own request and data-transfer reports. Avoid treating unavailable staging reports as zero usage.
6. Inspect staging before a release
Compare the available WordPress version, PHP version, plugin information, and mapped domains for my-site in production and staging. Identify differences relevant to my planned release. Do not create, delete, refresh, or deploy staging. List any functional tests I still need to perform.
This supports a release review; it does not test checkout, forms, visual layout, or every application behavior. A later deployment request should explicitly identify the destination and whether files, the database, or both are involved.
7. Purge a specific page after publishing
Purge the cached URL https://www.example.com/updated-page/ for the production website my-site. Verify the site and URL match before proceeding. Track the operation and report its final status. Do not change cache settings or exclusions.
Replace my-site with the name of the site you want to review.
This requests a real change. Review the tool's target and cache scope before approving it.
8. Investigate standalone EDGE traffic
For standalone EDGE site ID 12345, review traffic, performance, and security analytics for the last day. Inspect firewall activity for platform and custom rules. Summarize notable patterns and distinguish blocked traffic from application errors. Do not change origins, firewall settings, or Under Attack Mode.
EDGE supports access logs; hosting error logs and hosting-only operations are not available for a standalone EDGE target.
Understand operation results
Backups, cache purges, updates, and other changes may run as background jobs.
“Submitted” means accepted, not completed.
Ask your assistant to track the returned job ID and distinguish these outcomes:
Status | Meaning and next step |
| Completion was reported. Review the result and verify the expected website state where appropriate. |
| The operation reported an error. Inspect the details before retrying. |
| The wait period ended without confirmed completion; the job may still be running. Check the existing job. |
| A terminal outcome could not be established. Inspect the job or Dashboard before repeating the action. |
Destructive operations require a confirmation argument at the tool level. That argument is supplied by the assistant; it is not a guarantee of a separate human confirmation dialog.
Your client's tool approvals and your review remain important.
Troubleshooting
Application-specific connection problems are covered in each application's setup guide.
The checks below apply regardless of which supported application you use.
Problem | What to check |
Authentication fails | Verify the Dashboard email and password, account access, and that the dedicated beta account does not use MFA. Confirm the authentication values are available to the AI application. Do not print credential values while troubleshooting. |
| The beta does not currently support MCP OAuth. Verify the exact MCP URL and follow the authentication instructions in your application's setup guide. |
No Pressidium tools appear | Confirm the MCP server is configured and enabled, check the application's MCP connection status, verify the configuration syntax, and check whether organizational policy permits custom MCP servers. Restart the application after configuration changes. |
Wrong sites or no sites appear | Verify the connected account and selected team. List your Pressidium teams, select the intended team, then list its sites again. For larger accounts, check that all available pages were retrieved. |
MCP works but Agent Skills are missing | Confirm the skills package is installed and that the individual skills are discoverable. Restart the application if required. |
Audit logs are denied | Audit-log access requires a team owner or administrator. Other reviews can continue using data available to your current role. |
A tool reports an unsupported environment or product | Confirm whether the target is Managed Hosting or standalone EDGE and whether you requested production or staging. Some operations are available only for particular products or environments. |
Analytics are empty | Check the requested time range and selected domains. Staging analytics may use the platform hostname. Empty results do not necessarily mean there was no traffic. |
A write operation times out | Check the returned job ID or the Pressidium Dashboard before retrying. A timeout does not necessarily mean the underlying operation stopped. |
For application-specific connection problems, see the setup and troubleshooting section in your application's guide.
Disconnect or remove the integration
Follow the removal instructions in your application's setup guide to disable or remove the pressidium MCP server.
Remove any locally stored credentials or session variables.
Removing Pressidium Agent Skills is optional and does not itself disconnect MCP.
If you are retiring the dedicated beta account, remove its access through the Pressidium Dashboard.
If a credential was exposed, change it. Removing a local configuration file does not revoke a Dashboard password.
Disconnecting the AI application does not cancel an operation that has already been submitted to Pressidium.
Where to go next
Choose your AI application and complete its setup:
After connecting, return to this guide and start with the connection verification prompt.