Auditra

FAQ

Which clients and what does the transport look like?

Any MCP client supporting remote servers over HTTP. Transport is Streamable HTTP with a single application/json response (no SSE), JSON-RPC 2.0, stateless — no session ID is issued and none ever was.

Both MCP protocol generations are supported, decided per request with no server-side state. Clients speaking revision 2026-07-28 send per-request metadata and may call server/discover; the server validates the MCP-Protocol-Version, Mcp-Method, and Mcp-Name headers against the request body and rejects disagreement outright. Clients speaking 2025-11-25, 2025-06-18, or 2025-03-26 use the initialize handshake exactly as before, including notifications/initialized (202, empty body) and ping. Nothing was dropped; the server was stateless from the first release, so the new revision’s model is the one this plugin always had.

Clients on 2026-07-28 receive a 24-hour freshness hint on the tool list, so a tool added by a plugin update appears within a day without reconnecting. Older clients cache the tool list with no expiry signal, so on those, reconnect after upgrading the plugin.

How does authentication work?

A bearer token in the URL path: POST /wp-json/auditra/v1/mcp/{token}. Generated from random_bytes(32), hex encoded, compared with hash_equals, stored in a non-autoloaded option. permission_callback returns true and authentication happens inside the handler so error shapes stay under the plugin’s control: 404 when the endpoint is disabled, 401 on a bad token, 429 past the rate limit (60/min per IP, filterable via auditra_rate_limit). No OAuth — token-in-path is the permanent design.

Can I extend or tune it?

Tools are auto-discovered from includes/mcp/tools/: one file per tool, each declaring its own name, description, and JSON Schema. Filters: auditra_rate_limit, auditra_http_timeout, and auditra_vulnerability_provider — the last swaps the vulnerability data source for any class implementing the provider interface, which is one file (see CONTRIBUTING.md). Attribution accuracy comes from includes/data/prefix-overrides.json, a curated slug-to-prefix map that takes pull requests — the easiest useful contribution.

Is this safe to run on a production site?

The endpoint is disabled by default, token-authenticated, rate-limited, and structurally incapable of writing to your site. What it exposes when enabled is described honestly in the section above — read it and decide. Failed authentication attempts are logged on the settings page.

Does it slow my site down?

No. It does nothing on normal page loads. Work happens only when your AI client asks a question, and expensive lookups are cached (external data for 12–24 hours, disk scans for a day).

Why is the first question slow?

Because the cache is empty and the first call fills it. On a 45-plugin site the first list_plugins takes around 8 seconds and about 20 MB, because it looks every plugin up against wordpress.org and the vulnerability database and fetches release-cycle data, all in one request. Every call after that answers from cache in about 0.2 seconds until the data expires.

This is expected behaviour rather than a fault, and it costs your visitors nothing: the work happens inside your client’s request, not on a page load. If your MCP client gives up on the first call, ask again — the second one is fast.

What is the supply_chain section, and how is it different from a vulnerability?

A vulnerability is a bug in a release. A supply-chain audit is the other kind of problem: someone with publishing rights on the plugin shipped a version the original author did not write, usually after buying or hijacking the plugin.

These are reported separately and never mixed into the CVE list, because they mean different things and carry no CVE or severity score. Verdicts are malicious (attacker-supplied code confirmed in the affected versions), suspicious (changes consistent with a compromise, unconfirmed), and cleaned (compromised, later fixed in a clean release — which says nothing about a site still running an affected version). Where an audit publishes its range as a repository revision rather than a version number, the entry is still reported, marked as undetermined rather than quietly dropped.

These verdicts are WPVulnerability’s, not Auditra’s. They are reproduced exactly as published, identified by audit ID and publication date. Auditra does not analyse plugin code, reaches no independent conclusion about any plugin or its authors, and neither endorses nor disputes a verdict. It reports that an audit exists, what it says, and whether your installed version falls inside the range it names.

A supply-chain verdict is a serious accusation by a third party about someone else’s software. Attribute it to its source, and take any question about a specific verdict — its evidence, its accuracy, or its removal — to WPVulnerability at https://www.wpvulnerability.net/ rather than to us or to the plugin’s author.

Why doesn’t it give my site a score?

Because scores would be invented. Auditra reports measurable facts — versions, dates, sizes, counts, published CVEs — and leaves judgment to the model reading them, which can weigh actual context instead of applying a formula.

Does a zero usage count mean a plugin is safe to delete?

No, and the tool is deliberately narrow about this. zero_content_usage means exactly one thing: the plugin registers shortcodes, blocks, or post types and none appear in post content. A plugin registering no content features at all is reported as not measurable, never as unused — hooks, filters, admin screens, REST endpoints, and template code are all invisible to content scanning. Counts also scan post_content only, so a shortcode living in a widget, an option, or a theme template counts zero while appearing on every page.

Does it work on multisite?

Not properly in v1. It operates on the individual site it runs on; managing it on a network requires a network administrator. Full network support may come later.

What happens if one of the external services is down?

The affected answers degrade explicitly rather than quietly.

Every response carries a status object per source: whether it answered, why it did not, when it last answered successfully, and when the next retry is due. Failing services are retried with increasing backoff (up to 24 hours) to avoid hammering free community APIs.

If a source is unreachable but cached data survives, that data is served and labeled with its exact age — six-day-old wordpress.org data is far more useful than none. Vulnerability data is the exception: it is discarded after 72 hours, because a CVE published yesterday does not appear in a three-day-old cache.

check_vulnerabilities states which of four situations produced its answer: everything checked, everything checked from cached data past its expiry, some plugins checked and the rest named, or nothing checked at all. In the last case it returns **no findings list whatsoever** — an empty list is shaped like an answer, and "I looked and found nothing" is not the same statement as "I could not look".