mcp-registry/io.github.ajc3xc/meridian · v0.2.6
As of 2026-10-19 12:09 UTC, the Ajc3xc Meridian MCP server is up (it requires sign-in) with a Glimind reliability score of 90/100 (grade A). Over the last 30 days it answered 100% of Glimind's liveness checks. It had 15 outages in 90 days, with a median recovery of 3 minutes.
Persistent memory, task coordination, and HITL queue for AI coding sessions.
Claude Code
claude mcp add --transport http ajc3xc-meridian-mcp-server https://usemeridian.us/mcp/sse
Claude Desktop · Windsurf · Cline (mcpServers JSON)
{
"mcpServers": {
"ajc3xc-meridian-mcp-server": {
"type": "http",
"url": "https://usemeridian.us/mcp/sse"
}
}
}
Third-party server, listed as discovered. Review its source before installing.
Loading this server's tool list costs an agent ~81,277 tokens before any work — more than 99% of MCP servers.
Split rarely-used tools into a separate server or a toolset the client can enable, or expose one "search tools" entry point. Many agents load every connected server's tools into every request. How to fix →
3 tool definition(s) exceed ~1,200 tokens each (largest: update_sprint_item, ~3,044).
Move long reference material out of descriptions (link a doc or expose a resource), drop repeated examples, and collapse large enums. Trimming these to ~600 tokens saves ~6,316 tokens every session. How to fix →
235 tools on one server. Tool-selection accuracy drops as the menu grows, and some clients (e.g. Cursor) cap the number of active tools.
Group tools by task into smaller servers or toolsets, and merge near-duplicates behind one tool with a mode parameter. How to fix →
373 parameter(s) across 187 tool(s) have no description.
Add a "description" to each parameter with its format and an example ("ISO 8601 date, e.g. 2026-10-17"). This is the commonest cause of wrong arguments on the first call. How to fix →
3 tool(s) have parameters with no type (no type/enum/anyOf/$ref).
Give every parameter a "type" (or "enum"/"anyOf"). Untyped parameters make models guess — strings for numbers, objects for arrays. How to fix →
Handshake + tools/list takes ~2,101 ms.
Serve tools/list from memory, keep the process warm, and host close to your users. Every new agent session pays this before its first call.
No tool declares an outputSchema.
Declare outputSchema and return structuredContent (MCP 2025-06-18+). Agents can then parse results without guessing, and chain tools reliably. How to fix →
Requires authentication (Bearer); tool definitions could not be read anonymously.
If discovery should be public, allow initialize + tools/list without credentials and gate only tools/call. Directories and routers can then list your tools.
In the last 30 days: 0 tool(s) removed and 6 schema change(s).
Add new tools or optional parameters instead of renaming or removing; deprecate first (say so in the description) and remove later. Agents cache tool contracts. How to fix →
Paste-ready definitions with the problems above fixed. Changes marked verify need a human look. 187 tool(s) still need parameter descriptions written by someone who knows the API. All of them as JSON: /v1/readiness/mcp-registry%2Fio.github.ajc3xc%2Fmeridian/fixes
{
"name": "link_flag_to_section",
"description": "[MAINTENANCE] 8ca89e8f — DURABLY link a docx section/paragraph/figure/table (any doc_elements id — the same id space index_figure/index_table/link_figure_caption already anchor to) to the config-flag state that produced its underlying numbers. This is the check that catches 'results computed with the wrong flag state, then cited as current' — e.g. a flag that silently skipped a whole code path regardless of another flag, or a stale count cited after a fix superseded it. Typical flow: call get_fl",
"inputSchema": {
"type": "object",
"required": [
"doc",
"element_id",
"flag_name",
"value"
],
"properties": {
"doc": {
"type": "string",
"description": "The stored document's source (the path/URL you ingested it under via ingest_document)."
},
"value": {
"description": "The value the flag actually had when this section's numbers were produced (any JSON scalar — string/number/boolean/null).",
"type": "string"
},
"default": {
"description": "The flag's default AS RECORDED by get_flag_registry at link time — what a later get_flag_drift compares the current codebase default against. Optional but recommended.",
"type": "string"
},
"flag_name": {
"type": "string",
"description": "The config flag's name (as scanned by get_flag_registry, e.g. 'DT_ONLY_WIDTH')."
},
"element_id": {
"type": "string",
"description": "The doc_elements.id of the section/paragraph/figure/table this flag state applies to."
},
"project_id": {
"type": "string"
},
"source_file": {
"type": "string",
"description": "Optional: the file the flag was read from (from get_flag_registry's 'file'), pinning drift detection to this exact call site."
},
"source_line": {
"type": "integer",
"description": "Optional: the line the flag was read at (from get_flag_registry's 'line'), paired with source_file."
},
"project_name": {
"type": "string",
"description": "Project name — an alternative to project_id; resolved to the id internally. project_id wins if both are given."
}
}
},
"annotations": {
"title": "Link Flag to Section",
"readOnlyHint": false,
"openWorldHint": false,
"idempotentHint": false,
"destructiveHint": false
},
"title": "Link Flag to Section"
}{
"name": "record_handoff_correction",
"description": "[MAINTENANCE] 3af86d28 — record a corrective handoff when a blocked executor session reaches a wall after receiving a handoff (its evidence/scope no longer holds, a pointer stopped resolving, a required capability went away, etc.). Links to the immutable source_handoff_id (never mutated), classifies the blocker, and carries structured investigation evidence, added/removed/superseded pointers, and changed resources. Records status='draft' by default (or pass status explicitly). Pass idempotency_k",
"inputSchema": {
"type": "object",
"required": [
"source_handoff_id",
"blocker_classification"
],
"properties": {
"mode": {
"enum": [
"full",
"delta",
"planner",
"starter",
"goal"
],
"type": "string",
"description": "Only used when regenerate=true — forwarded to generate_handoff."
},
"status": {
"enum": [
"draft",
"verified",
"superseded",
"blocked"
],
"type": "string",
"description": "Initial status. Default draft."
},
"version": {
"type": "string",
"description": "Sprint-version bucket in scope, if any — also used to scope the regenerated revision when regenerate=true."
},
"output_dir": {
"type": "string",
"description": "Only used when regenerate=true; defaults to the server's data directory."
},
"project_id": {
"type": "string"
},
"regenerate": {
"type": "boolean",
"description": "When true, also repairs pointers, invalidates the source handoff, and produces a new deterministic revision in this SAME call. Default false (record only)."
},
"session_id": {
"type": "string",
"description": "The blocked executor session recording this correction."
},
"project_name": {
"type": "string",
"description": "Project name — an alternative to project_id; resolved to the id internally. project_id wins if both are given."
},
"source_token": {
"type": "string",
"description": "Optional: the <goal_token> value from the original /goal block, preserved for audit only (not re-verified by this call)."
},
"added_pointers": {
"type": "array",
"items": {
"type": "object"
},
"description": "Pointer dicts (same shape as add_sprint_item_pointer's source_type/targets/label) asserting new evidence. Re-resolved live when regenerate=true."
},
"idempotency_key": {
"type": "string",
"description": "Optional caller-supplied dedup key so a retried call returns the existing correction instead of duplicating it."
},
"requested_scope": {
"description": "Free-form JSON describing the scope the ORIGINAL handoff asked for, for comparison against what actually got emitted.",
"type": "string"
},
"removed_pointers": {
"type": "array",
"items": {},
"description": "Pointer dicts or ids being removed as evidence."
},
"changed_resources": {
"type": "array",
"items": {
"type": "string"
},
"description": "File/resource paths that changed since the source handoff was rendered."
},
"source_handoff_id": {
"type": "string",
"description": "The immutable handoffs.id row this correction is for (e.g. load_handoff's handoff.id is NOT the row id directly — use a handoff id you have from generate_handoff/get_handoffs)."
},
"superseded_pointers": {
"type": "array",
"items": {},
"description": "Pointer dicts or ids whose premise was replaced."
},
"blocker_classification": {
"enum": [
"evidence_invalid",
"scope_stale",
"pointer_unresolved",
"dependency_missing",
"environment_blocked",
"capability_unavailable",
"other"
],
"type": "string",
"description": "Controlled vocabulary for why the handoff needed correcting."
},
"investigation_evidence": {
"description": "Free-form JSON: what you found during investigation.",
"type": "string"
}
}
},
"annotations": {
"title": "Record Handoff Correction",
"readOnlyHint": false,
"openWorldHint": false,
"idempotentHint": false,
"destructiveHint": false
},
"title": "Record Handoff Correction"
}{
"name": "request_hitl",
"description": "Surface a question to the human-in-the-loop queue. ALWAYS use this to ask the human a question — never just ask in chat, which is invisible to the dashboard and to an unattended/autonomous run. IMPORTANT: when the project's HITL auto-answer mode is on (1=safe, 2=aggressive) and the question is not destructive / not require_human, this tool RESOLVES IMMEDIATELY and returns the chosen answer inline in the response (it does NOT block) — so calling it is cheap and is the right move even when you exp",
"inputSchema": {
"type": "object",
"required": [
"question"
],
"properties": {
"kind": {
"enum": [
"question",
"correction"
],
"type": "string",
"description": "question (default, auto-answerable) or correction (non-blocking mid-run human correction)."
},
"context": {
"type": "string"
},
"options": {
"type": "array",
"items": {
"type": "string"
},
"description": "Answer choices rendered as selectable buttons in the dashboard."
},
"urgency": {
"enum": [
"normal",
"high",
"blocking"
],
"type": "string"
},
"question": {
"type": "string"
},
"project_id": {
"type": "string"
},
"session_id": {
"type": "string"
},
"assigned_to": {
"type": "string"
},
"recommended": {
"description": "The safe-default option — an option string or a 0-based index into options. Highlighted in the dashboard; Enter submits it; auto-answer prefers it.",
"type": "string"
},
"project_name": {
"type": "string",
"description": "Project name — an alternative to project_id; resolved to the id internally. project_id wins if both are given."
},
"require_human": {
"type": "boolean",
"description": "When true, the HITL can never be auto-answered — only an explicit human response unblocks it. Reserve for irreversible/destructive actions."
}
}
},
"annotations": {
"title": "Request HITL",
"readOnlyHint": false,
"openWorldHint": false,
"idempotentHint": false,
"destructiveHint": false
},
"title": "Request HITL"
}Get an email or webhook when this server's readiness drops by 10+ points, tool-poisoning text appears, or a tool breaks:
curl -X POST https://glimind.com/v1/subscriptions -H 'content-type: application/json' -d '{"tools":["mcp-registry/io.github.ajc3xc/meridian"],"email":"[email protected]"}'Agents: watch_tool({"toolId": "mcp-registry/io.github.ajc3xc/meridian"}) over MCP.
update_sprint_item ~3,044 tokensadd_sprint_item ~2,672 tokensgenerate_handoff ~2,400 tokenscomplete_sprint_item ~1,041 tokensaccept_handoff ~940 tokensStatic checks of the advertised tools/list (schema, descriptions, annotations, tool-poisoning patterns, names, size) plus observed protocol, uptime, latency and contract changes. Read-only: no tool is ever called. Weights: schema 15, docs 20, safety 15, efficiency 15, compatibility 15, protocol 5, reliability 10, stability 5. Token counts are estimates (~3.6 characters per token).
Operator? Fix these, then re-check live. Embed the readiness badge:
[](https://glimind.com/server/mcp-registry%2Fio.github.ajc3xc%2Fmeridian?ref=badge)
<a href="https://glimind.com/server/mcp-registry%2Fio.github.ajc3xc%2Fmeridian?ref=badge"><img src="https://glimind.com/v1/readiness/badge/mcp-registry%2Fio.github.ajc3xc%2Fmeridian.svg" alt="MCP agent-readiness"></a>
.. image:: https://glimind.com/v1/readiness/badge/mcp-registry%2Fio.github.ajc3xc%2Fmeridian.svg :target: https://glimind.com/server/mcp-registry%2Fio.github.ajc3xc%2Fmeridian?ref=badge :alt: MCP agent-readiness
Glimind records every version of this server's tool definitions in a signed, append-only transparency log. Current manifest sha256:6c5c193f0d654a04…, first seen 2026-10-17, included at leaf 4060 of 26,816. Version history · verify what your client received.
Compare: most reliable communication servers · most reliable files servers · most reliable other servers · most reliable code servers · most reliable knowledge servers
Glimind tells agents whether a server is up right now and how to call it, then fails over to a live alternative when it isn't.
Claude Code
claude mcp add --transport http glimind https://glimind.com/mcp
Claude Desktop · Windsurf · Cline (mcpServers JSON)
{
"mcpServers": {
"glimind": {
"type": "http",
"url": "https://glimind.com/mcp"
}
}
}
As of 2026-10-19 12:09 UTC, the Ajc3xc Meridian MCP server is up (it requires sign-in) with a Glimind reliability score of 90/100 (grade A). Over the last 30 days it answered 100% of Glimind's liveness checks. It had 15 outages in 90 days, with a median recovery of 3 minutes.
Ajc3xc Meridian MCP server advertises 235 tools, including accept_handoff, acquire_docx_document_lease, activate_profile_layer, add_custom_hook, add_insight.
Point your MCP client at this streamable-http endpoint: https://usemeridian.us/mcp/sse
Glimind scanned all 235 tool definitions for tool-poisoning patterns — hidden or invisible characters, instructions that override the model, concealment from the user, requests to read credential or MCP config files, conversation exfiltration and cross-tool shadowing — and found none. This checks what the server tells the model, not what its code does; review the source before granting access to sensitive data.
Status page: 90-day uptime, every outage and how long it lasted.
Claim this listing to get the Verified operator marker, a remediation checklist and owner analytics, or embed the live badge from any of the tool pages above. Maintainers: alerts, deploy attestation and monthly reports.
Status is an automated estimate from Glimind's liveness checks (handshake and tool listing only; no tool is ever called) and may lag or differ from your network. Glimind is not affiliated with this server or its operator. Operator? Request a correction or opt out at https://glimind.com/opt-out.