Skip to main content

MCP Readiness Audit

A fixed-scope, human-reviewed assessment of one MCP implementation — what will hold in production, what will not, and what to change first.

Suitable for

  • Teams with a working MCP server or integration that has not yet faced production traffic, security review or procurement.
  • Engineering leads who need an independent, vendor-neutral view before committing to a rollout.
  • Teams preparing for a client-directory submission or an internal go/no-go decision and needing evidence, not opinion.

Before we start

What you provide

Fixed-scope work needs defined inputs. This is everything the engagement requires from your side.

  • Read access to the MCP server source repository, or an agreed representative extract.
  • Server configuration and manifest files (secrets redacted — we never need live credentials for an audit).
  • A short written description of intended clients, hosting and transport.
  • One nominated technical contact for a kickoff call and clarification questions.

Scope

What is included — and what is not

Included

  • Protocol-level review: initialization, capability negotiation, tool/resource/prompt declarations and error behaviour against the current MCP specification.
  • Transport and session review: stdio/streamable-HTTP configuration, session handling, timeout and reconnection behaviour.
  • Authorization boundary review: how identity, scopes and tool-level permissions are (or are not) enforced.
  • Tool-surface review: schema quality, input validation, destructive-action safeguards and prompt-injection exposure of tool descriptions.
  • Client compatibility assessment against the named clients agreed at kickoff.
  • Operational readiness: logging, secret handling, deployment and rollback posture.

Excluded

  • No code changes — the audit reports and recommends; implementation is a separate engagement.
  • No penetration testing, load testing or formal security certification.
  • No review of unrelated infrastructure beyond the agreed MCP boundary.
  • One implementation per audit. Additional servers or integrations are separate audits.

What you receive

Deliverables

  • Severity-ranked findings report (critical / high / medium / advisory) with evidence for each finding.
  • Prioritised remediation plan sequenced by risk and effort.
  • Client compatibility matrix for the named clients agreed in scope.
  • Production Evidence Pack (audit edition) — see contents below.
  • A 45-minute findings walkthrough call with your team.

Production Evidence Pack — readiness audit edition

  • Findings report (PDF and Markdown).
  • Remediation plan with priority ordering.
  • Client compatibility matrix with test conditions recorded.
  • Requirements, findings and acceptance traceability matrix.
  • Residual-risk register: what remains open, who owns it and what would close it.
  • Scope statement and exclusions as agreed at kickoff.
  • Methodology note describing what was and was not examined.

Timetable

Expected timetable

  1. Kickoff call scheduled after intake and scope validation.
  2. Audit delivered within 5 working days of kickoff for a typical single-server scope.
  3. Findings walkthrough within 3 working days of delivery, at your convenience.

Acceptance

How success is accepted

  • All agreed scope areas are covered in the findings report, or explicitly marked out of scope with the reason.
  • Every critical and high finding includes evidence and a concrete remediation step.
  • The findings walkthrough has been offered and either held or waived by you.

Microsoft readiness

Microsoft MCP server certification — where we stand

Microsoft operates an MCP server certification process for its own supported discovery and runtime surfaces. It is Microsoft's process, run to Microsoft's standards, and Microsoft decides its outcomes.

  • EcoCitizenz is independent. We are not Microsoft, we do not act for Microsoft, and we are not a Microsoft certification authority.
  • We do not issue Microsoft certification, and we cannot approve, endorse or publish anything on Microsoft's behalf.
  • Microsoft alone controls its certification, review, approval and publication outcomes.
  • What we provide is independent readiness assessment, evidence mapping and remediation guidance — preparation for a process someone else runs.
  • A readiness assessment is not certification, not approval, not a compliance attestation, not a security guarantee, and not proof that certification will be obtained.

Independent Microsoft MCP server certification readiness matrix

Publisher readiness

Whether the verified-publisher position is in place: a Partner Center account with completed business verification, the required programme enrolment, and demonstrable ownership or control of the endpoint being submitted.

Package and metadata readiness

Whether the submission artefacts exist and are coherent: the API definition covering the tools and endpoints, the authentication configuration, the required descriptive metadata, and the public documentation file.

Authentication readiness

Whether at least one approved authentication method is supported and correctly configured, and whether the test credentials and configuration instructions a reviewer needs can actually be supplied.

Functional and documentation consistency

Whether each tool behaves as its documentation says, since a manual reviewer tests exactly that. Divergence between documented and observed behaviour is recorded as a finding.

Security and access posture

Whether endpoints are secured, domain ownership is demonstrable, and access is least-privileged — assessed as readiness observations, not as a security guarantee.

Telemetry and traceability

Whether logging and telemetry are sufficient to support auditing and traceability, and where they are not.

Responsible-AI exposure

Where AI-driven behaviour or actions on user data create safety, permission-handling or content-policy exposure that a reviewer would probe with normal, edge-case and adversarial scenarios.

Ongoing-maintenance exposure

What would fall out of alignment after publication — new tools, significant changes, documentation drift — given that certification is an ongoing commitment, not a one-off event.

This matrix is our independent readiness view, mapped against Microsoft's published requirements. It is not a Microsoft assessment, carries no Microsoft status, and does not guarantee that a submission will be accepted. Microsoft decides that, on its own evidence.

Primary sources, retrieved 2026-07-25: Microsoft Learn — MCP certification (Copilot Studio) (external) · Microsoft Learn — Microsoft MCP server certification (external)

Protocol revision

MCP 2026-07-28 — published stable, adopted at different speeds

  • MCP 2026-07-28 is a published stable specification release. It introduces a stateless protocol core, per-request version and capability metadata, server/discover, subscriptions/listen, Multi Round-Trip Requests, versioned extensions, authorization changes, caching metadata and formal feature deprecation. Ecosystem adoption varies, and clients and servers may continue to support and negotiate earlier protocol versions.
  • Publication does not make it a mandatory certification requirement, does not set a deadline by which anything shuts down, and is not evidence that existing MCP servers stop working. Earlier protocol revisions, including 2025-11-25, remain in real use.
  • We report findings against the protocol revision your implementation actually targets. Where you target an earlier revision, migration exposure to 2026-07-28 is mapped as its own clearly labelled view rather than mixed into the findings for your target revision.

Stateless-core assumptions

Where the implementation depends on server-side session affinity, and what that dependency would cost under the stateless protocol core.

Removed handshake

Where behaviour is tied to the initialize/initialized handshake the 2026-07-28 revision removes, and what carries that information instead.

Removed protocol-level sessions

Where the protocol-level session and its session-id header are relied on, given that the 2026-07-28 revision removes them.

Routing and version metadata

How per-request routing, version and capability metadata would be produced and consumed, and what in the current implementation assumes it does not exist.

Extensions

Exposure to the versioned extensions model, and which current behaviour would need to be expressed as an extension.

Tasks

Where long-running work is handled today, and how it relates to the specification's Tasks model.

MCP Apps

Whether any interactive interface surface is in scope, and the exposure that would come with it.

Authorization hardening

Observations against the 2026-07-28 revision's tightened authorization expectations, reported as readiness observations rather than as a security verdict.

Primary sources, retrieved 2026-07-28: Model Context Protocol — 2026-07-28 release (official repository) (external) · Model Context Protocol — 2026-07-28 specification changelog (external)

Scope and price

How this fits the £395 Readiness Audit

  • This is positioning for the existing MCP Readiness Audit, not a new service. The price remains £395, paid 100% upfront, with no later milestone.
  • The Audit still covers one MCP implementation. A second implementation is a second audit.
  • It remains assessment, report and remediation guidance. It includes no customer-code modification.
  • Coverage depends on your agreed written scope and on the evidence actually available. We include what is relevant to your scope, and we say what we did not examine.
  • Where evidence is unavailable or a fact is only the owner's to confirm, it is recorded as an evidence gap or marked OWNER CONFIRMATION REQUIRED. It is never silently converted into a failure.

Unknown is not the same as failed. Where evidence is unavailable, the finding is recorded as an evidence gap or marked OWNER CONFIRMATION REQUIRED, with what would close it.

This describes what the Audit assesses. It is not a claim that these checks are automated, that the mapping has been rehearsed on a live engagement, or that any result carries Microsoft status.

After payment

What happens after you pay

  1. TrustOps confirms your order and opens the intake form.
  2. You provide repository access, configuration and the intended-client list.
  3. We validate scope; the kickoff call is scheduled. Delivery start is confirmed after intake and scope validation.
  4. If the implementation is out of scope for a fixed-price audit, we say so before starting and refund in full if we decline the engagement.
Start the audit — £395

You'll review your order on TrustOps (trustops.ecocitizenz.com) before any payment step. Purchase starts your engagement and written intake; your delivery schedule is confirmed during intake.