Arclan MCP Registry

Server Details

MCP registry: 138k servers crawled, handshake-validated, reliability-scored. 744 production-safe.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 99.7% over 41 days
Last Tested: 2026-09-27 00:38
Transport: Streamable HTTP · MCP 2024-11-05
URL

TDQS

A4.4/5.0

Scored 2026-07-30 09:00 across 4 tools

Disambiguation5/5

Each tool serves a distinct purpose: retrieving details, searching, recommending, and reporting. There is no overlap or confusion between them.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern (get_server, query_registry, recommend_server, report_server) with no mixing of styles.

Tool Count5/5

Four tools is a well-scoped set for a registry server. Each tool covers a necessary operation without being too few or too many.

Completeness5/5

The tool set covers the core registry operations: retrieving details, searching, getting recommendations, and reporting. No obvious gaps for an agent's interaction with the registry.

Available Tools

4 tools

get_serverAInspect

Get full details for a specific MCP server. Pass the server name (e.g. "GitHub", "Brave Search"), registry ID slug, or endpoint URL. Returns score, state, tools list, latency, and recent test history.

ParametersJSON Schema

Name	Required	Description	Default
`id`	No	Server name, registry ID slug, or any identifier (e.g. "github", "brave-search", "gateway-pipeworx-io-rpc-mcp")
`url`	No	The MCP server endpoint URL (e.g. "https://mcp.example.com/mcp")

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses return values (score, state, tools list, latency, test history), which is adequate for a read operation. Lacks info on authentication or side effects, but not critical for this tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences: first states purpose, second covers inputs and outputs. No unnecessary words. Front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, but description adequately lists return fields (score, state, tools list, latency, test history). Parameters are covered. Error handling not mentioned, but for a simple get tool, this is acceptable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for both parameters. Description adds examples (e.g., 'GitHub', 'Brave Search') and clarifies that id can be a name or slug, but does not significantly extend beyond schema. Baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the verb 'Get' and resource 'full details for a specific MCP server'. It lists the return contents, distinguishing it from siblings like query_registry, recommend_server, and report_server.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage when full details of a specific server are needed, but does not explicitly state when not to use or compare with alternatives. However, the context is clear and no exclusions are needed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

query_registryAInspect

Search the Arclan registry for MCP servers. By default returns only connectable servers (active, mcp_partial, auth_gated). Use status=stdio to browse local-only servers available for installation. Use status=all to query the full index. Use production_safe=true to restrict to servers with uptime > 97% and handshake success > 95%. Use read_only=true to restrict to servers with no write or exec tools. Use this before connecting to an MCP server to check its validation status and score. After using a server, call report_server to contribute reliability data.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max results to return 1–20 (default 10)
`status`	No	Filter by state. Default (omit): connectable states only (active + mcp_partial + auth_gated). Use "stdio" for local-install catalog. Use "all" for the full index.
`min_score`	No	Minimum validation score 0–100 (default 0)
`read_only`	No	Only return servers with no write or exec tools — safe for read-only agent workflows.
`transport`	No	Filter by transport type
`capability`	No	Filter by tool name or keyword (searches name, description, tools)
`production_safe`	No	Only return servers with uptime_7d > 97% and handshake_success_rate > 95%. Use when reliability matters.

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of disclosure. It explains default behavior (returns only connectable servers) and filter effects. However, it does not disclose potential error conditions, rate limits, or details about the return structure beyond the limit parameter.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured, starting with the main action and default behavior, then listing specific filter uses, and ending with a related action. It is front-loaded and each sentence contributes useful information, though it could be slightly more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of 7 parameters and no output schema, the description covers the tool's purpose, default behavior, filter options, and even suggests a follow-up action. It lacks detail on return format but is otherwise complete for a search tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage with descriptions for all 7 parameters. The description adds value beyond the schema by explaining specific use cases for parameters (e.g., 'Use production_safe=true to restrict to servers with uptime > 97% and handshake success > 95%') and clarifying defaults for the status parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Search the Arclan registry for MCP servers.' It specifies the resource (Arclan registry) and the action (search), and distinguishes itself from sibling tools like get_server, recommend_server, and report_server by focusing on querying the registry with various filters.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use the tool: 'Use this before connecting to an MCP server to check its validation status and score.' It also gives specific filter suggestions (production_safe, read_only, status=stdio) and mentions a related action after use (report_server). However, it does not explicitly state when not to use this tool compared to alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

recommend_serverAInspect

Get ranked MCP server recommendations for a task. Returns servers scored by production safety, keyword relevance, registry score, latency, and freshness. Each result includes a reason code array explaining why it was ranked. Use this instead of query_registry when you want an opinionated ranked list rather than a filtered search.

ParametersJSON Schema

Name	Required	Description
`q`	No	Task or capability query — e.g. "search the web" or "read files"
`auth`	No	Include servers that require authentication (default: true)
`limit`	No	Max results 1–20 (default: 5)
`read_only`	No	Only return servers with no write-classified tools
`production_safe`	No	Only return production-safe servers (uptime > 97%, handshake > 95%)

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It describes the output (scored servers with reason codes) and implies it is a read-only operation (recommendations). While it does not explicitly state side effects or authentication needs, the behavioral transparency is high for a recommendation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences: the first defines the tool's purpose and output, the second provides explicit usage guidance. It is front-loaded, efficient, and contains no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given there is no output schema and no annotations, the description covers the main purpose, output structure (ranking with reason codes), and usage context. It lacks details on default parameter behavior but the schema covers defaults. Overall fairly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description mentions the 'task or capability query' but does not add additional meaning beyond the schema. No further parameter semantics are provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with a specific verb-resource pair ('Get ranked MCP server recommendations') and explicitly distinguishes itself from the sibling `query_registry` by contrasting 'opinionated ranked list' with 'filtered search'. This makes the tool's purpose very clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly states when to use this tool ('when you want an opinionated ranked list') and explicitly names the alternative (`query_registry`). However, it does not mention the other siblings (`get_server`, `report_server`), so it is not exhaustive but still clear for the most similar tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

report_serverAInspect

Submit an agent usage report for an MCP server. Reports are aggregated and influence registry trust scores. Call this after using an MCP server so the registry can track real-world reliability. Supports both a simple outcome report and a structured scoring report (criterion + component_score).

ParametersJSON Schema

Name	Required	Description
`errors`	No	Array of error strings encountered during tool use
`agentId`	No	Identifier for the reporting agent (optional)
`outcome`	Yes	Result of using the server
`severity`	No	Severity of the worst issue encountered
`criterion`	No	Specific reliability criterion being scored (enables structured component scoring)
`latencyMs`	No	Total wall-clock latency in milliseconds
`serverUrl`	Yes	The MCP server endpoint URL that was used
`toolsUsed`	No	List of tool names that were called
`environment`	No	Environment the server was used in
`evidenceRef`	No	Trace ID, log URL, or other reference supporting this report
`taskCategory`	No	Category of task attempted (e.g. "search", "write", "read")
`turnsRequired`	No	Number of turns to complete the task
`componentScore`	No	Score 0–100 for the specified criterion
`taskDescription`	No	Brief description of what the task was

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so description must disclose behavior. It mentions aggregation and influence on trust scores, but lacks details on idempotency, authentication, rate limits, or response behavior. Some transparency is present but incomplete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two focused sentences with no wasted words. First sentence states action, second gives usage context, third lists supported modes. Well-structured and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 14-parameter tool with no output schema, the description is minimal. It covers basic purpose and modes but lacks details on usage frequency, error handling, duplication semantics, and integration into workflow. Adequate but could be more complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% (baseline 3). The description adds value by explaining two modes of reporting: simple outcome and structured scoring (criterion + component_score), clarifying parameter relationships beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Submit an agent usage report for an MCP server' with specific verb and resource. It explains the purpose (influence registry trust scores) and distinguishes from sibling tools (get_server, query_registry, recommend_server) which are query-oriented.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Call this after using an MCP server' providing clear context. However, it does not explicitly contrast with siblings or state when not to use it, limiting full guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateMay 27, 2026

Changedget_server2 fields changed

changedInput schema / properties / id / description

Previous value: -"The registry ID (slug) for the server"New value: +"Server name, registry ID slug, or any identifier (e.g. \"github\", \"brave-search\", \"gateway-pipeworx-io-rpc-mcp\")"

changedInput schema / properties / url / description

Previous value: -"The MCP server endpoint URL"New value: +"The MCP server endpoint URL (e.g. \"https://mcp.example.com/mcp\")"

1 tool updateMay 26, 2026

Changedreport_server6 fields changed

addedInput schema / properties / componentScore

Added value: +{
+  "description": "Score 0–100 for the specified criterion",
+  "type": "number"
+}

addedInput schema / properties / criterion

Added value: +{
+  "description": "Specific reliability criterion being scored (enables structured component scoring)",
+  "enum": [
+    "output_reliability",
+    "side_effect_transparency",
+    "failure_handling",
+    "rate_limits",
+    "agent_feedback"
+  ],
+  "type": "string"
+}

addedInput schema / properties / environment

Added value: +{
+  "description": "Environment the server was used in",
+  "enum": [
+    "prod",
+    "staging",
+    "dev",
+    "unknown"
+  ],
+  "type": "string"
+}

addedInput schema / properties / errors

Added value: +{
+  "description": "Array of error strings encountered during tool use",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / evidenceRef

Added value: +{
+  "description": "Trace ID, log URL, or other reference supporting this report",
+  "type": "string"
+}

addedInput schema / properties / severity

Added value: +{
+  "description": "Severity of the worst issue encountered",
+  "enum": [
+    "info",
+    "warning",
+    "error",
+    "critical"
+  ],
+  "type": "string"
+}

1 tool updateMay 22, 2026

Changedquery_registry3 fields changed

changedInput schema / properties / limit / description

Previous value: -"Max results to return 1–200 (default 50)"New value: +"Max results to return 1–20 (default 10)"

addedInput schema / properties / production_safe

Added value: +{
+  "description": "Only return servers with uptime_7d > 97% and handshake_success_rate > 95%. Use when reliability matters.",
+  "type": "boolean"
+}

addedInput schema / properties / read_only

Added value: +{
+  "description": "Only return servers with no write or exec tools — safe for read-only agent workflows.",
+  "type": "boolean"
+}

1 tool updateMay 21, 2026
- Addedrecommend_server
3 tool updatesMay 19, 2026
- First observedget_server
- First observedquery_registry
- First observedreport_server

Related MCP Connectors

MCP Verify B
io.sentinelsignal
Trust, freshness, policy, and discovery layer for public MCP servers.
Agent Orchestration Developer Tools Testing & QA Tools
222
MCP Trust Index
fund.staas
Curated, trust-first index of vetted MCP servers — scored tiers, monthly re-verified. Read-only.
Developer Tools
1
AgenticSearch B
uk.co.cybersecai.agentsearch
Trust-scored search engine for MCP servers. 1,900+ sources indexed. IETF draft published. Referenced by OWASP MCP Security Cheat Sheet. L0-L4 trust levels based on cryptographic verification.
Legal & Compliance Security
2
Find MCP - Agentage MCP Directory A
io.agentage
Search the official MCP registry: 17,000+ servers with trust grades, stars, tools, install config.
Search Developer Tools Documentation Access
32

Related MCP Servers

dominion-observatory
Monitoring Observability
vdineshk
A
license
Not graded
quality
A
maintenance
Behavioral trust scoring for MCP servers and AI agents. Live registry tracking 4,500+ servers with trust scores (0-100) based on interaction history, success rates, and latency
Updated 4 months ago (2026-06-08 06:10 UTC)
2
MIT
MCP Queen Registryofficial
Developer Tools Testing & QA Tools
mcpqueen
A
license
A
quality
B
maintenance
Crawls and grades MCP servers deterministically, providing a registry, leaderboard, and API to query server grades and submit feedback.
Updated 13 days ago (2026-09-13 15:28 UTC)
7
MIT
vaglio-mcp
Research & Data Search Knowledge & Memory
Alemusica
A
license
A
quality
B
maintenance
MCP server for academic research with shared token bucket governance, evidence-based read depth, and archival inscription. Uses multiple sources with failover to avoid rate limits.
Updated 2 months ago (2026-07-28 11:06 UTC)
6
MIT
mcp-registry-server
Search RAG Systems
KBB99
A
license
C
quality
D
maintenance
Easily find MCP servers using our MCP registry. Search with natural language.
Updated 2 years ago (2025-02-05 23:18 UTC)
1
6
MIT