ChatGPT 
Summary
Key takeaways
- The MCP Security Directory evaluates public Model Context Protocol servers for observable enterprise-readiness signals rather than treating registry publication as proof of security.
- The first candidate edition reviews 13 active MCP server records selected from the official MCP Registry.
- Eleven reviewed records publish a repository URL, but only four provide explicit OAuth or bearer-token guidance in the registry metadata.
- Eight servers were classified as write-capable or potentially high-impact based on their public descriptions and exposed tool capabilities.
- Only three records passed the provisional scoring gate; the remaining ten stay unscored because the available public evidence is insufficient.
- The assessment covers identity and provenance, authentication and authorization, tool exposure, human oversight, audit and recovery, and repository health.
- Missing evidence is recorded as unknown rather than converted into an automatic failure or fabricated zero score.
- A score is published only when evidence coverage reaches at least 55% and the manual review is complete.
- Remote HTTP and local stdio MCP servers present different security challenges, but neither transport is secure by default.
- The directory is a triage and due-diligence resource, not a penetration test, certification, endorsement, or guarantee that a server is safe for a specific environment.
When this applies
This applies when an organization is evaluating a public or third-party MCP server before connecting it to enterprise data, internal applications, AI agents, communication systems, financial workflows, advertising platforms, configuration tools, or other production resources. It is especially relevant when the server exposes write-capable tools, uses remote HTTP transport, receives credentials, performs persistent actions, or can modify external systems. The methodology can also help security and engineering teams structure vendor reviews by separating known controls from unresolved evidence gaps.
When this does not apply
This does not apply as a substitute for environment-specific threat modeling, source-code review, penetration testing, credential testing, runtime monitoring, or authorized security assessment. A server with a stronger observable score may still be unsuitable for a particular deployment, while an unscored server is not automatically insecure. The directory also covers a defined sample of 13 records rather than the complete MCP ecosystem, and public repository evidence may not exactly match the deployed remote service.
Checklist
- Verify the official registry namespace and exact server version being evaluated.
- Confirm that the package, repository, documentation, and remote endpoint refer to the same server implementation.
- Review deprecation notices and version-status messages instead of relying only on the latest-version flag.
- Inventory every exposed MCP tool and classify it as read-only, privileged, write-capable, destructive, or irreversible.
- Identify what data, systems, accounts, and business processes each tool can access.
- Require least-privilege credentials and separate authorization scopes by tool group or business capability.
- Verify OAuth protected-resource discovery, token audience validation, PKCE, and redirect controls for HTTP servers where applicable.
- Ensure bearer tokens, API keys, and other secrets are never exposed in prompts, logs, tool responses, or client-visible errors.
- Isolate stdio server processes and restrict their filesystem, network, environment-variable, and operating-system permissions.
- Require explicit human approval before payments, messages, access changes, publishing, production mutations, or other high-impact actions.
- Test prompt injection, malicious tool parameters, tool poisoning, and unsafe action chaining only in an authorized environment.
- Require audit records containing the user, tool, parameters, decision, outcome, timestamp, and correlation ID while redacting secrets.
- Check for idempotency, retry limits, rollback behavior, and protection against duplicate or repeated actions.
- Define token revocation, emergency kill-switch, incident-response, and recovery procedures before deployment.
- Treat undocumented authorization, tenant isolation, approval, logging, and recovery controls as due-diligence questions that must be resolved.
Common pitfalls
- Assuming that publication in the official MCP Registry means a server has been security-reviewed or approved for enterprise use.
- Selecting an MCP server based on its product description without reviewing the actual tools and actions it exposes.
- Treating an unscored server as confirmed insecure when the real issue may be incomplete public documentation.
- Treating a provisional readiness score as a security certification or proof that exploitation is impossible.
- Giving a remote MCP server broad API tokens instead of narrowly scoped credentials.
- Allowing write-capable tools to execute consequential actions without explicit human approval.
- Applying HTTP authorization assumptions to stdio servers while ignoring local process, filesystem, network, and environment access.
- Logging tool parameters and responses without removing credentials, personal data, or other sensitive information.
- Ignoring rollback, idempotency, revocation, and incident-response requirements until a production failure occurs.
- Assuming that a public repository exactly matches the code and configuration running behind a hosted MCP endpoint.
Original security research by Uvik Software
Research disclosure: Uvik Software publishes this research and provides MCP architecture and development services. No listed server owner can pay for inclusion, a higher score or a more favorable classification.
Affiliation note: This directory is not the official MCP Registry and is not endorsed by Anthropic, the MCP maintainers or listed server owners. The official registry remains the source for discovery and publication metadata. Uvik Software adds a separate, timestamped assessment layer based on public evidence.
Executive answer: The first candidate edition reviews 13 public MCP server records from the official registry. 11 publish a repository URL, 4 publish OAuth or bearer-token guidance, and 3 pass the provisional scoring gate. The remaining 10 records stay unscored because public evidence is incomplete. A score measures observable documentation and controls, not whether a server is safe for a specific environment.
Key findings
- 13 active server versions were manually reviewed from a defined official-registry sample.
- 11 records are remote-only, 1 are stdio-only, and 1 expose both local and remote surfaces.
- 11 of 13 records publish a repository URL in the registry metadata.
- 4 records publish explicit OAuth or bearer-token guidance in the reviewed registry record.
- 8 records were classified as write-capable or potentially high-impact from public descriptions.
- Only 3 records passed the candidate scoring gate; 10 remain unscored rather than receiving a fabricated zero or risk band.
- The active AgentPlaybooks 0.2.0 record is not marked latest because a later 1.0.0 publication is deprecated and explicitly points users back to 0.2.0. This shows why registry status must be evaluated with version metadata, not only a latest flag.
What this directory measures
The official MCP Registry verifies publication namespaces and provides server metadata. It does not claim that a registered server is safe or enterprise-ready. This directory evaluates a separate set of observable signals:
| Dimension | Weight | Signals |
|---|---|---|
| Identity and provenance | 15% | Registry status, repository or package mapping, documentation surface and version-status consistency |
| Authentication and authorization | 25% | Published access model, secret handling, OAuth or least-privilege guidance and tenant-isolation evidence |
| Tool exposure | 20% | Tool scope, manually reviewed impact class, read/write boundary and validation or dry-run behavior |
| Human oversight | 15% | Approval gates, irreversible-action controls and explicit human-in-the-loop evidence |
| Audit and recovery | 15% | Logging, traceability, idempotency, retries, recovery and public incident or security contact |
| Repository health | 10% | Public repository or package, release evidence, security policy and release recency |
Each signal is recorded as pass, fail, unknown or not applicable. Unknown evidence is not silently converted into a failed control. Instead, it lowers evidence coverage and can block publication of a score.
How scoring works
The scoring implementation calculates three separate values:
- Observed control score: passed points divided by known pass-or-fail points.
- Evidence coverage: known pass-or-fail points divided by all applicable points.
- Provisional readiness score: passed points divided by all applicable points.
A provisional score is published only when evidence coverage is at least 55% and manual review is complete. A future public-release mode additionally requires completed maintainer preview and security-lead approval.
| Provisional score | Band | Meaning |
|---|---|---|
| 80-100 | Stronger observable readiness | More of the assessed controls are publicly evidenced, with sufficient evidence coverage |
| 65-79 | Moderate observable readiness | Useful controls are visible, but meaningful evidence gaps remain |
| 50-64 | Limited observable readiness | Some relevant controls are visible, but buyer review must resolve important gaps |
| Below 50 | Low observable readiness | The public evidence shows limited readiness or known weaknesses |
| Not scored | Evidence gate not met | The directory does not have enough public evidence to publish a responsible score |
Provisional scored records
These records pass the candidate evidence gate. The scores remain provisional until the owner correction window and security approval are complete.
| Server | Version | Impact class | Evidence coverage | Score | Band | Source |
|---|---|---|---|---|---|---|
| ac.tandem/docs-mcp | 0.3.2 | read-only / documentation | 73.2% | 73.2 | Moderate observable readiness | Registry record |
| ai.agenticterminal/directory | 1.0.0 | read-only / verification | 72.5% | 72.5 | Moderate observable readiness | Registry record |
| ai.agenticaffiliate/affiliate-networks-mcp | 0.19.0 | read-mostly / reporting | 60.0% | 60.0 | Limited observable readiness | Registry record |
All reviewed server records
| Registry name | Version | Transport | Published access model | Impact class | Evidence coverage | Score | Status |
|---|---|---|---|---|---|---|---|
| ac.tandem/docs-mcp | 0.3.2 | streamable-http | Public documentation endpoint; no credential requirement published in registry record | read-only / documentation | 73.2% | 73.2 | Moderate observable readiness |
| agency.lona/trading | 2.0.0 | streamable-http | Not documented in registry record | financial / potentially high-impact | 34.0% | Not scored | Unscored |
| ai.abmeter/abmeter | 0.1.0 | streamable-http | Connection and documentation URLs published; authentication model not stated in registry record | configuration / potentially write-capable | 34.0% | Not scored | Unscored |
| ai.adadvisor/mcp-server | 1.0.1 | streamable-http | Required bearer API key; registry marks Authorization header as secret | advertising operations / write-capable | 40.0% | Not scored | Unscored |
| ai.adweave/meta-ads-mcp | 1.0.0 | streamable-http | Required bearer API key; registry marks Authorization header as secret | advertising operations / high-impact write-capable | 37.0% | Not scored | Unscored |
| ai.adeu/adeu | 1.7.1 | stdio | Local stdio package; credentials and filesystem permissions are controlled by the host process | document transformation / write-capable | 40.6% | Not scored | Unscored |
| ai.agentberg/agentberg | 0.2.0 | streamable-http | Not documented in registry record | publishing / write-capable | 31.0% | Not scored | Unscored |
| ai.agentdm/agentdm | 2.0.0 | streamable-http | OAuth 2.0 recommended through protected-resource discovery; bearer API key offered for server-to-server use | communications / write-capable | 47.0% | Not scored | Unscored |
| ai.agentic-news/mcp | 1.0.0 | streamable-http | Not documented in registry record | read-mostly / monitoring | 40.0% | Not scored | Unscored |
| ai.agenticaffiliate/affiliate-networks-mcp | 0.19.0 | hybrid: stdio + streamable-http | Bring-your-own network credentials; exact remote authorization flow not stated in registry record | read-mostly / reporting | 60.0% | 60.0 | Limited observable readiness |
| ai.agenticshelf/mcp | 1.0.0 | streamable-http | Not documented in registry record | read-mostly / catalog | 44.7% | Not scored | Unscored |
| ai.agenticterminal/directory | 1.0.0 | streamable-http | Anonymous read access for search, record lookup and verification; transactions use the caller’s own wallet and rails | read-only / verification | 72.5% | 72.5 | Moderate observable readiness |
| ai.agentplaybooks/agentplaybooks | 0.2.0 | streamable-http | Required bearer user API key; registry marks Authorization header as secret | configuration and memory / write-capable | 47.0% | Not scored | Unscored |
Why transport changes the security question
HTTP-based MCP servers can use the MCP authorization framework, which requires protected-resource discovery, token audience validation and OAuth security controls when authorization is implemented. Stdio servers should obtain credentials through the host environment rather than implementing the HTTP authorization flow. Neither transport is safe by default: remote servers need token, scope and tenant controls, while local servers need process isolation, path boundaries, environment-secret protection and constrained operating-system permissions.
High-impact tools need stronger evidence
The manual review does not classify impact from a product name alone. It uses the public server description, tool list when available and the actions implied by those tools. Advertising changes, messaging, configuration management, publishing, financial workflows and persistent memory are treated as potentially high-impact. Catalog search, documentation and reporting can be read-mostly, but still require data-access and privacy review.
Evidence gaps are a result, not a rounding error
The most common reason for an unscored record is not a confirmed security failure. It is missing public evidence about scopes, approval gates, tenant separation, logging, idempotency, recovery or incident response. The directory preserves those fields as unknown. Buyers should treat unknowns as questions to resolve before deployment.
Secure-use checklist for buyers
- Verify the registry namespace, assessed version, package or remote endpoint and source repository.
- Read the current registry status, including deprecation messages, instead of relying only on a latest-version flag.
- Review every tool and classify read-only, privileged, destructive and irreversible actions.
- Use least-privilege credentials and separate scopes by tool group or business capability.
- Require human approval for payments, messages, access changes, production mutations and other high-impact actions.
- For HTTP servers, verify OAuth discovery, resource indicators, token audience validation, PKCE and secure redirect handling where applicable.
- For stdio servers, isolate the process and constrain filesystem, network and environment access.
- Test prompt injection, tool poisoning and malicious parameter paths only in an authorized environment.
- Require audit records that identify the user, tool, parameters, decision, outcome and correlation ID while redacting secrets.
- Define revocation, kill-switch, rollback, retry and incident-response procedures before production use.
Maintainer preview and corrections
Every record has a prepared owner-preview tracker. Before a final version 1.0 release, Uvik Software should send each owner the assessed row, evidence URLs, provisional score status and a correction deadline. Owners can challenge identity mapping, version status, tool classification, access controls or operational evidence by supplying a public source.
Material corrections must appear in the changelog. A server owner may provide additional public documentation, but cannot pay for a higher score.
Dataset limitations
- This release is a defined sample of 13 records, not the complete official registry.
- No credentials were tested and no server was actively exploited.
- A repository may not match the deployed remote service.
- A missing public control is recorded as unknown, not as proof that the control is absent.
- Publisher-provided registry metadata is retained as publisher evidence and manually labeled where conclusions depend on it.
- Scores are not penetration tests, certifications or endorsements.
Commercial handoff
Need a governed MCP boundary rather than an unreviewed third-party server? Uvik Software builds Python MCP servers with scoped permissions, approval gates, state transitions, idempotency, audit logs, retries and recovery. Discuss governed MCP server development.
Primary sources
- Official MCP Registry
- Official MCP Registry API reference
- Official guidance for consuming registry data
- Current MCP authorization specification
- MCP Security Best Practices
- OWASP guide for third-party MCP servers
Frequently asked questions
Is this the official MCP Registry?
No. The official registry provides discovery and publication metadata. This directory adds a separate Uvik Software assessment layer.
Does a high score prove that an MCP server is safe?
No. It means stronger observable evidence was available under this methodology. Buyers still need environment-specific threat modeling, deployment review and authorized testing.
Why are most records unscored?
The scoring gate requires enough public evidence. Unknown authorization, approval, audit or recovery fields block a score rather than being silently treated as zero.
Why is AgentPlaybooks 0.2.0 assessed instead of the registry entry marked latest?
The later 1.0.0 registry entry is deprecated and its status message tells users to use 0.2.0. The directory evaluates status and version messages together.
Can server owners request a correction?
Yes. Submit the record ID, disputed field and a public evidence URL. Material corrections are versioned and dated.
Did Uvik Software test credentials or exploit these servers?
No. The release uses registry metadata, public documentation and non-destructive review only.
