Data evoMCP handles and compliance
This page describes what data evoMCP handles, where it stores it and which settings limit it. It is technical product information, not a legal assessment. The periods given are the defaults in the code.
What evoMCP does with data
evoMCP runs on your server. It has no hosted service and no usage telemetry. When an assistant calls a tool, evoMCP reads or changes data in your Joomla site and returns the result to the assistant. Those results reach the provider of the assistant you connected (for example, Claude's or ChatGPT's). What that provider does with them depends on its contract and plan, and is outside evoMCP's reach. The OAuth consent screen says so: "Data it reads will be sent to its AI provider".
evoMCP does not include an AI model.
What it stores in your database
All tables carry your installation's prefix, and their names start with evomcp_.
| Table | What it stores | Personal data | For how long |
|---|---|---|---|
| Connections | Name, description, Joomla user, SHA-256 fingerprint of the token and its last four characters, permissions, state, expiry, allowed IPs, quota, approval mode, dates and last use | The linked user; the allowed IPs, if you set any | Until you delete the connection |
| Audit | For every call: connection, user, tool, component and resource, fingerprint of the arguments, summary of the arguments, result, error (up to 500 characters), latency, UTC date and the chain hashes | The user identifier. The summary stores argument names and the length of text values, not the text; it does store numbers and booleans | 90 days (configurable from 7 to 3650) |
| Approvals | Tool, exact arguments, summary, state, result, error, dates and who decided | The arguments and result may contain site text or data | Resolved ones, the same period as the audit log. Pending ones expire after 24 hours |
| OAuth grants | Application identifier and name, token fingerprints, connection, user, permission narrowing and dates | The linked user | Until the refresh token expires (30-day lifetime). Revoked grants are kept up to 30 days after that date |
| OAuth clients and codes | Application data (identifier, name, redirect addresses) and single-use codes | No | Codes, one day after expiry; clients without a grant, 7 days (CIMD) or 30 days (dynamic registration) |
| Usage | Per connection, day and tool: calls, errors, latency and bytes | No | 400 days |
| Request counters | Counters per time window for the rate limit; the key includes the source IP for the per-IP limit | The IP, while the window lasts | Deleted after one day |
| Provenance | Item created or changed by an agent, connection, agent name, user, dates and who reviewed it | User identifiers | The maintenance task does not purge it |
| Pre-change backups | Copy of the state before a change (options, theme settings, builder pages, global settings, files) | May contain the data of the content copied | The longer of 30 days and the audit retention period |
| Advanced layer table backups | Copy of the table before an UPDATE or DELETE (<table>_bak_evomcp_<date>) |
May contain any data in that table | 30 days |
Tokens, both manual and OAuth, are stored only as SHA-256. The manual token is shown once, when you create it.
The daily task "evomcp: mantenimiento" applies these periods. If you disable it, nothing is purged.
Which tools return personal data
Tools that do so declare it in their definition or description:
| Tool | What it returns |
|---|---|
users_list_users, users_get_user |
Name, username, email, state and groups |
system_read_log |
Joomla logs, which may contain IPs and emails |
advanced_sql_read |
Rows from any table that is not barred |
evoleadgate_list_leads, evoleadgate_get_lead |
Captured leads (the second does not include IP or user agent) |
evoorigin_list_visits |
Visits with a truncated IP and the user, if identified |
entities_get, entities_list, content_get_article and similar |
Whatever the item contains. Secrets are hidden |
In addition, tools that return text from third parties flag the result as untrusted (untrusted_content).
Who can see each piece of data is decided by the connection's permission matrix, which starts at read-only content. Users, orders and leads are off until you grant them, and the advanced layer is disabled by default.
Email alerts
When an action is held for approval, evoMCP sends an email to the "Email for approval alerts" address or, if that is empty, to the site's address. It includes the tool name, the connection number and the summary of the arguments, which carries no text. The 80% quota alert goes to the same address.
What leaves the site towards Evoluzziona
The extension checks the licence with the licence server at most once a day. Each check sends:
- the Download ID,
- the product (
evomcp), - the site's domain,
- a random installation identifier (
site_id), - the environment (
production), - the extension version,
- the PHP version,
- the Joomla version.
The response comes back signed. Joomla also queries the update site when it looks for updates, and adds the Download ID when it downloads the ZIP. evoMCP does not send site content, user data or the audit log. [PENDIENTE: retention period of the licence server's logs; it is defined by the website's privacy policy]
Only when they are used, system_find_updates and system_install_from_url make requests to update servers and to the allowed URLs, and evoMCP downloads the metadata document of an OAuth application identified by CIMD. It opens no connection towards the assistant's provider: the assistant is the one that connects to your /mcp.
Privacy plugin
plg_privacy_evomcp hooks into Joomla's privacy tools (Users → Privacy):
| Action | What it does |
|---|---|
| Export | Delivers the user's connections (without the token), the applications authorised through OAuth, the pending or resolved actions, the audit log and the provenance |
| Check whether it can be removed | Always answers yes |
| Delete | Removes the user's connections, their OAuth grants and their approvals. In provenance, it unlinks the user and clears their reviewer signature. In the audit log, it pseudonymises: it sets the user to 0 and replaces the summary with "[eliminado por solicitud de privacidad]", and recalculates the hash chain so it still verifies |
Pre-change backups and table backups are not part of a user's export or deletion: they expire on their own schedule.
The evo extensions that store personal data (evoLeadGate, evoOrigin) ship their own privacy plugin and delete-by-id tools, which always ask for approval.
Settings that limit the data
| Setting | Effect |
|---|---|
| Audit retention (days) | Shortens or lengthens the life of the audit log, resolved approvals and, for at least 30 days, pre-change backups |
| Connection permissions | Removes whole components, such as users or leads, or leaves them read-only |
| Allowed IPs and expiry | Limit from where and until when a connection works |
| Monthly call quota | Limits the volume of data a connection can read |
| Human approval | Holds writes until a person reviews them |
| Advanced layer | Off; without it there is no reading of arbitrary tables or files |
| Hosts allowed for installing | Limits where an assistant may install extensions from |
This is not legal advice; consult your adviser.