What can you do with this server?

AgentNexus is a service-boundary-aware coordination server for managing versioned documents and facilitating communication across heterogeneous LLM code agents. Document Management * push_document — Push a full new document version * patch_document — Apply a unified diff patch to an existing document (efficient partial updates) * get_document — Retrieve the latest or a specific version of a document * list_documents — List all documents in a sub-project * publish_draft — Confirm and publish a draft, triggering subscriber notifications Update & Notification Handling * get_my_updates_with_context — Fetch unread notifications with diffs and full content in one call * get_my_updates — Fetch unread notifications without full content * ack_update — Acknowledge (mark as read) a specific notification * add_subscription — Subscribe a project to updates from a document ID or type Task & Configuration Access * get_my_tasks — Retrieve pending/in-progress tasks for a project * get_config — Fetch configuration document for a project and lifecycle stage Space & Project Management * create_space — Create a new Project Space grouping related services * register_project — Register a sub-project (service) within a space * list_projects — List all sub-projects in a space * get_project_id_by_name — Look up a project ID by name AI & Search * Full-text search (FTS5/BM25) across all documents in a space * AI Planner: conversational Q&A, service-split proposals, and project overviews via integrated LLMs Agent Onboarding (SDAOP) * generate_steering_file — Auto-generate IDE onboarding files (AGENTS.md, CLAUDE.md, Kiro steering, Cursor rules) to configure agents for automatic document-update checks

Which integrations are available for this server?

Provides integration with OpenAI's language models for the Planner AI layer, enabling conversational document Q&A and service planning.

agent-nexus

by dugubuyan

Overview Schema Source Related Servers Discussions Admin

Python

Local

AgentNexus

The coordination layer for heterogeneous LLM code agents. Let a backend agent, a frontend agent, and an infra agent — running on different IDEs and different models — stay in sync automatically, with zero hand-written glue.

License: MIT Python 3.11+ Tests DOI agent-nexus MCP server Available on CodeGuilds

An MCP server that coordinates AI code agents across service boundaries. (Not affiliated with the MIT Lincoln Laboratory project of the same name.)

The problem

Your product isn't one codebase. It's a backend, a frontend, some infra, a test suite — each with its own repo, stack, and agent. When the backend changes its API, the frontend has to adapt. Today that coordination is done by humans copy-pasting specs into chat, or by hand-written CLAUDE.md / AGENTS.md files that go stale the moment the service changes.

Role-playing multi-agent frameworks (ChatDev, MetaGPT) don't help here: they assume all agents live in one simulated org, one codebase. Real systems are a mesh of independently-owned parts.

Related MCP server: en-quire

What AgentNexus does

AgentNexus coordinates agents at the service boundary — the unit real systems are actually built from. Each boundary registers as a sub-project, publishes versioned Markdown documents (requirements, design, API specs, config), and subscribes to the documents it depends on. When a document changes, subscribers get a diff-aware notification — the exact change plus the full latest content — so an agent can make a targeted edit without a human in the loop.

Backend Agent              AgentNexus               Frontend Agent
  (Claude Code)                                        (Cursor)
      │                        │                          │
      │── POST /api/documents ▶│                          │
      │   (api spec, v5)       │── notification ─────────▶│
      │                        │                          │── get_my_updates_with_context()
      │                        │── diff + full content ──▶│
      │                        │                          │── applies targeted code change
      │                        │◀──────── ack_update() ───│

Two ideas make this practical, and they're the parts worth stealing even if you never run the server:

1. Content travels out-of-band → zero token cost

Coordination signals (what changed, who must react) are small and belong in the model's context. Document bodies are large and don't need to be reasoned about the moment they're written — they need to be stored and fetched on demand. So AgentNexus splits the two:

Control plane (MCP): notifications, subscriptions, queries — a notification carries a version number and a unified diff, enough to decide if and how to react.
Data plane (plain HTTP POST /api/documents): full document body, never passed as an MCP tool argument.

A document of any size costs zero model tokens on the write path. You pay tokens for coordination, not for content.

2. SDAOP — the service onboards the agent, not the other way around

AGENTS.md, CLAUDE.md, Cursor rules, Kiro steering — they all share one model: a human writes a static file, commits it, and the IDE loads it at startup. It goes stale, it drifts, and it's per-human busywork.

Service-Driven Agent Onboarding Protocol (SDAOP) flips this. The service generates and delivers client-specific onboarding at connection time. A new agent only needs the endpoint:

generate_instruction_file(project_name="my-service", project_space_id="<space_id>", client_type="kiro")

Emits the right artifact for the client — .kiro/steering/, CLAUDE.md, AGENTS.md, or .cursor/rules/ — plus a push-tool script with the server URL baked in.
Each artifact is content-hash versioned. Change a convention on the server, or move the server to a new URL, and the version bumps — connected workspaces detect the drift and re-onboard. No stale files, no manual notification.
The service is the single source of truth; the client-side file is a derived artifact that regenerates as the service evolves.

Supported clients: kiro, claude, codex, cursor.

Quick Start

# 1. Install
pip install -e .

# 2. Start the server — auto-creates the database on first run
#    (default: http://0.0.0.0:10086/mcp, dashboard at http://0.0.0.0:10086/)
python -m agent_nexus.main

That's it — no separate DB migration or .env needed to get started. Everything has sane defaults; copy .env.example to .env only when you want to change the port, point at Postgres, or enable the Planner LLM.

Run with Docker

docker build -t agent-nexus .
docker run -p 10086:10086 agent-nexus

To persist documents and the database across restarts, mount volumes:

docker run -p 10086:10086 \
  -v "$(pwd)/workspace:/app/workspace" \
  -v "$(pwd)/data:/app/data" \
  -e AGENT_NEXUS_DB_URL=sqlite:////app/data/agent_nexus.db \
  agent-nexus

Connect from Kiro / any MCP client:

{
  "mcpServers": {
    "agent-nexus": {
      "url": "http://localhost:10086/mcp"
    }
  }
}

First steps:

# Create a project space
create_space(name="my-project")

# Register two boundaries
register_project(name="backend-api", type="development", project_space_id="<space_id>")
register_project(name="frontend",    type="development", project_space_id="<space_id>")

# Push a document via HTTP POST (content stays out of LLM context)
# curl -X POST http://localhost:10086/api/documents -H 'Content-Type: application/json' \
#   -d '{"project_id":"<backend_id>","doc_id":"<backend_id>/api","content":"# API Spec..."}'

# Subscribe the frontend to the backend's API docs
add_subscription(subscriber_project_id="<frontend_id>", project_space_id="<space_id>", target_doc_id="<backend_id>/api")

# Frontend checks for updates (returns diff + full content)
get_my_updates_with_context(project_id="<frontend_id>")

Web Dashboard

Once the server is running, open http://localhost:10086/ in your browser to browse spaces, sub-projects, and documents, run full-text search, and use the built-in AI Chat for conversational document Q&A and service planning.

LLM configuration: AI Chat requires PLANNER_LLM_API_KEY. Set PLANNER_LLM_PROVIDER (openai or anthropic), PLANNER_LLM_MODEL, and optionally PLANNER_LLM_BASE_URL (Azure / Ollama / compatible APIs). Leave the key unset to disable AI features while keeping all browse/search functionality.

Key Features

Versioned document store — SHA-256 dedup, full version history, per-boundary namespacing
Publish-subscribe notifications — subscribe by exact doc ID or doc type
Diff-aware updates — get_my_updates_with_context returns unified diff + full content in one call
Control/data plane split — coordination over MCP, content over out-of-band HTTP (zero LLM token cost)
SDAOP — services auto-generate versioned, client-specific onboarding files for any connecting agent
Planner — a read-only, boundary-spanning observer (planner_chat, planner_plan, planner_overview) that answers cross-boundary questions no single agent can
MCP HTTP server — streamable-HTTP transport, multiple agents connect simultaneously
FTS5 full-text search — search_documents with BM25 ranking, phrase/prefix/boolean queries
Web Dashboard + AI Chat — browser UI over spaces, projects, and documents
337 tests — unit + property-based (Hypothesis)

Out-of-Band Write Endpoint

The primary document write path. Content travels via HTTP body — never entering LLM context — so it's practical for documents of any size. Supports optional base_version for optimistic concurrency control (fast-forward check).

curl -X POST http://localhost:10086/api/documents \
  -H "Content-Type: application/json" \
  -d '{
    "project_id": "<project_id>",
    "doc_id": "<project_id>/requirement",
    "content": "# Requirements\n\nContent here..."
  }'

MCP Tools

Tool	Description
`create_space`	Create a Project Space
`register_project`	Register a sub-project (boundary)
`list_projects`	List all sub-projects in a space
`list_documents`	List all documents in a sub-project
`get_document`	Retrieve a document (latest or specific version)
`get_my_updates_with_context`	Get unread notifications with diff + full content
`ack_update`	Mark a notification as read
`get_my_tasks`	Get pending tasks for a project
`get_config`	Get config document for a stage
`add_subscription`	Add a subscription rule
`publish_draft`	Confirm a draft document
`generate_instruction_file`	Generate client-specific onboarding file (SDAOP)
`get_project_id_by_name`	Look up project_id by name
`search_documents`	Full-text search across documents in a space
`planner_chat`	Conversational Q&A with LLM over project documents (streaming)
`planner_plan`	Generate service-split proposal from a description
`planner_overview`	Get a high-level overview of a project space

Configuration

Environment Variable	Default	Description
`AGENT_NEXUS_DB_URL`	`sqlite:///agent_nexus.db`	Database URL
`AGENT_NEXUS_DOCS_ROOT`	`./workspace`	Workspace root (docs live under `{root}/{space_id}/docs/`)
`AGENT_NEXUS_HOST`	`0.0.0.0`	Server bind host
`AGENT_NEXUS_PORT`	`10086`	Server port
`AGENT_NEXUS_PUBLIC_URL`	(derived from host/port)	Outward-facing URL baked into onboarding files; changing it bumps the SDAOP version
`AGENT_NEXUS_DEFAULT_SPACE_ID`	`default`	Default space ID for bootstrap imports
`PLANNER_LLM_PROVIDER`	`openai`	LLM provider for Planner AI (`openai` \| `anthropic`)
`PLANNER_LLM_MODEL`	(provider default)	LLM model name
`PLANNER_LLM_API_KEY`	(none)	API key; leave empty to disable AI features
`PLANNER_LLM_BASE_URL`	(none)	Custom API endpoint for OpenAI-compatible APIs (Azure, Ollama, proxies)

Running Tests

python -m pytest tests/ -q

Paper

The accompanying research papers are in the paper/ directory:

paper/agentnexus-v4.md — v4 (current): generalizes the coordination unit from service to ownership boundary, adds the control/data plane split and the Planner (中文版)
paper/agentnexus-v3.md — v3: introduces SDAOP
paper/agentnexus.md — v2

dugubuyan. AgentNexus: A Boundary-Aware Coordination Architecture for Heterogeneous LLM Code Agents (v4). Zenodo, 2026. https://doi.org/10.5281/zenodo.21257426

License

MIT

Available Tools

16 tools

ack_updateC

Acknowledge (mark as read) a notification.

ParametersJSON Schema

Name	Required	Description	Default
`project_id`	Yes
`update_id`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries full burden. It only states the action but doesn't disclose side effects, idempotency, or required permissions. The agent cannot infer behavioral traits beyond the simple verb.

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 a single, front-loaded sentence with no filler. However, it is arguably too sparse, sacrificing informative content for brevity.

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

Completeness2/5

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

Given the tool's simplicity, the description lacks completeness. It does not explain the effect of acknowledgment, return behavior (void?), or how to obtain valid parameter values. Agent is left with significant gaps.

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

Parameters2/5

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

Schema description coverage is 0%, and the description does not explain the parameters project_id and update_id. Parameter names provide some hints, but the description adds no value beyond the schema. The agent relies on guessing or external knowledge.

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 verb 'acknowledge' and the resource 'notification', with parenthetical 'mark as read' for clarity. It is specific and distinct from sibling tools like get_my_updates, which list notifications.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, such as needing a valid project_id or update_id, or context like what happens after acknowledging.

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

add_subscriptionB

Add a subscription rule. Provide target_doc_id for exact doc or target_doc_type for all docs of that type.

ParametersJSON Schema

Name	Required	Description	Default
`subscriber_project_id`	Yes
`project_space_id`	Yes
`target_doc_id`	No
`target_doc_type`	No

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It implies a creation operation ('Add') but lacks details on side effects, permissions, idempotency, or what happens if a subscription already exists. The description is minimal and does not adequately inform the agent of behavioral constraints.

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 extremely concise, consisting of a single sentence that conveys the core purpose and usage of the two key parameters. No unnecessary words or repetition.

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

Completeness2/5

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

Given the tool has 4 parameters, no output schema, and no annotations, the description should provide more context. It only partially explains two parameters and omits the required ones. There is no mention of return values, error conditions, or typical use cases, making it incomplete for an AI agent to reliably use.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. It explains target_doc_id and target_doc_type, but the required parameters subscriber_project_id and project_space_id are left unexplained. This leaves a significant gap in understanding the tool's input requirements.

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

Purpose4/5

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

The description clearly states 'Add a subscription rule', specifying the verb and resource. It also distinguishes between targeting a specific document or all documents of a type, which helps differentiate from sibling tools that don't involve subscriptions. However, the concept of 'subscription rule' is not further explained, leaving some ambiguity.

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 guidance on when to use each targeting parameter: 'Provide target_doc_id for exact doc or target_doc_type for all docs of that type'. This is clear context for usage. However, it does not mention when not to use the tool or compare to alternatives, though sibling tools are not directly related.

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

create_spaceC

Create a new Project Space. Returns the space_id needed for registering projects.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavioral traits. It only states creation and return of space_id, omitting details about idempotency, authorization, naming constraints, or side effects.

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

Conciseness3/5

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

The description is a single sentence, which is concise, but it lacks front-loading of critical information. It is under-specified given the missing annotations and schema descriptions.

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

Completeness2/5

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

Given the simple one-parameter tool, the description identifies the primary output (space_id) but does not cover prerequisites, error cases, or confirmation of creation. Without annotations, it is incomplete for reliable agent use.

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

Parameters1/5

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

The input schema has 0% description coverage for parameters. The description adds no meaning to the 'name' parameter beyond what the schema provides (a string). No constraints or expectations are communicated.

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 verb 'Create', the resource 'Project Space', and the outcome 'Returns the space_id needed for registering projects.' It also implies a dependency on register_project, helping differentiate from sibling tools.

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

Usage Guidelines3/5

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

The description hints at usage (space_id needed for registering projects) but does not explicitly state when to use this tool, when not to, or name alternatives. It provides no usage guidance.

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

generate_steering_fileB

Generate the content for a .kiro/steering/doc-exchange.md Steering file. The sub-project Kiro should create this file to enable automatic doc-update checks.

ParametersJSON Schema

Name	Required	Description	Default
`project_name`	Yes
`project_space_id`	Yes

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided; description fails to disclose whether the tool writes to disk or returns content, side effects like overwriting, or required permissions. The agent is left guessing about behavioral aspects.

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?

Two concise sentences with the main purpose front-loaded. No waste, though parameter details are missing; could be more structured but efficient.

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

Completeness2/5

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

Simple tool with 2 required params and no output schema, but description omits behavioral details (what is returned?), parameter semantics, and usage conditions. Incomplete for an agent to use confidently.

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

Parameters1/5

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

Schema description coverage is 0%, and the description adds no meaning to the parameters 'project_name' and 'project_space_id'. Agent has no guidance on valid values, formats, or constraints.

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?

Clearly states the verb 'generate' and the specific resource 'Steering file' with a defined purpose 'enable automatic doc-update checks'. Distinguishes well from sibling tools which do not involve steering file generation.

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 for setting up automatic doc-update checks via the sub-project Kiro. Does not explicitly mention when not to use or alternatives, but the context is clear given sibling tools.

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

get_configB

Return the config document for the given project and stage.

ParametersJSON Schema

Name	Required	Description	Default
`project_id`	Yes
`stage`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided, and the description fails to disclose whether the operation is read-only, destructive, or has side effects; minimal behavioral context.

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?

Single, clear sentence with no unnecessary words; efficiently conveys the core purpose.

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

Completeness2/5

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

No output schema, yet description does not indicate what the returned config document looks like (e.g., format or structure), leaving the agent underinformed.

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

Parameters2/5

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

Schema description coverage is 0%, and the description adds no extra meaning to parameters beyond their names; does not explain format or constraints.

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 returns a config document for a given project and stage, with a specific verb and resource, distinguishing it from sibling tools like get_document.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives such as get_document or list_documents; lacks context for selection.

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

get_documentB

Retrieve a document (latest or specific version).

ParametersJSON Schema

Name	Required	Description	Default
`project_id`	Yes
`doc_id`	Yes
`version`	No

TDQS

B3.2/5.0

Behavior3/5

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

No annotations are provided, so the description must carry the full burden. It implies read-only retrieval but lacks details about what is returned (e.g., content vs metadata) or any constraints. The version option is mentioned but not explained how it affects behavior.

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 very concise at one sentence, with no fluff. However, the extreme brevity omits necessary details, so it balances conciseness and completeness poorly.

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

Completeness2/5

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

For a tool with 3 parameters, no output schema, and no annotations, the description is insufficient. It does not cover return format, error cases, or how version is used, leaving an agent without enough information to invoke the tool correctly.

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

Parameters2/5

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

The input schema has 0% description coverage, and the tool description does not add any meaning beyond parameter names and types. It does not explain the purpose of project_id, doc_id, or the version parameter (e.g., null for latest).

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 retrieves a document, specifying that it can retrieve the latest or a specific version. This matches a specific verb+resource and distinguishes it from siblings like list_documents and patch_document.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like list_documents. There are no exclusions or context about prerequisites or appropriate scenarios.

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

get_my_tasksC

Return all pending/in-progress tasks for the given project.

ParametersJSON Schema

Name	Required	Description	Default
`project_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

No annotations are provided, so the description must convey behavior. It implies a read operation but does not confirm idempotency, data limits, or whether pending/in-progress status is dynamic. The lack of behavioral detail is a gap.

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

Conciseness3/5

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

The description is a single sentence, which is concise but omits important structural details. It front-loads the action and resource but is too brief to be fully effective.

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?

The tool is simple with one parameter and an output schema, but the description does not explain return format or error cases. It covers the basic purpose but lacks completeness for an agent to fully understand usage.

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

Parameters2/5

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

Schema description coverage is 0%, so the description should explain the parameter 'project_id'. It only says 'for the given project' without clarifying format, origin, or required access. The description adds minimal value beyond the schema.

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

Purpose4/5

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

The description clearly states the verb 'Return' and resource 'pending/in-progress tasks' for a project. It distinguishes from sibling tools like 'get_my_updates' by specifying task status, but does not explicitly differentiate from similar list operations.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus siblings such as 'get_my_updates' or 'list_documents'. The description does not mention prerequisites, filters, or alternatives, leaving the agent without context for selection.

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

get_my_updatesA

Return all unread notifications for the given project.

ParametersJSON Schema

Name	Required	Description	Default
`project_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior3/5

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

The description implies a read-only operation ('Return'), but does not disclose details like authentication needs, pagination, or what happens with no unread notifications. With no annotations, it partially covers behavioral traits but lacks depth.

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?

A single concise sentence of 7 words effectively captures the tool's purpose with no redundancy or wasted information.

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?

While the tool is simple with one parameter and an output schema, the description lacks context on the 'my' in the name (personal updates?) and does not differentiate from the sibling 'get_my_updates_with_context'. Overall sufficient but could be more 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?

The description mentions 'for the given project' linking the project_id parameter to the purpose, but does not explain its format or constraints. With 0% schema description coverage, the description adds minimal value 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 the action ('Return') and the resource ('all unread notifications') scoped to a project. It is specific and distinguishes from siblings by implying a simpler update set.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives, such as the sibling 'get_my_updates_with_context'. No when-not-to-use or context for choosing.

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

get_my_updates_with_contextA

Return all unread notifications with diff and full latest document content. One call gives everything needed to understand what changed and act on it. After processing, call ack_update for each update_id to mark as read.

ParametersJSON Schema

Name	Required	Description	Default
`project_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior3/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 of disclosing behavioral traits. It accurately conveys that the tool returns information (read operation) but does not address permissions, rate limits, or whether the operation has side effects. The post-processing instruction is noted, but transparency is basic.

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 three concise sentences. The first sentence states the core function, the second emphasizes the tool's value, and the third gives a critical follow-up action. No extraneous words; front-loaded with key information.

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 that an output schema exists, the description does not need to detail return values. It covers the main output (diff and full content), the one-call convenience, and the required ack_update step. However, it does not clarify the scope (e.g., user-specific vs. project-specific) or explain the 'update_id' referenced in the post-processing step, leaving minor gaps.

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

Parameters2/5

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

Schema description coverage is 0%, meaning the description adds no information about the required 'project_id' parameter beyond the schema. The schema itself only provides a title and type, offering minimal semantic guidance. The description should explain what project_id represents or how it filters updates.

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 it returns all unread notifications with diff and full latest document content, and distinguishes from sibling get_my_updates by indicating this provides comprehensive context in one call. The verb 'Return' identifies it as a retrieval operation.

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 instructs the agent to call ack_update after processing to mark notifications as read, which provides clear post-processing context. However, it does not explicitly state when to prefer this tool over the simpler sibling get_my_updates, though the emphasis on 'everything needed' implies use cases requiring full context.

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

get_project_id_by_nameB

Look up a sub-project's project_id by its human-readable name.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes
`project_space_id`	Yes

TDQS

B3/5.0

Behavior2/5

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

No annotations exist, so the description carries the full burden. It does not disclose behavioral traits such as read-only nature, required permissions, or error states.

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 a single sentence with no wasted words, front-loaded with the main action.

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?

The tool is simple and the description conveys the core purpose, but it lacks explicit mention of the return format, edge cases, or the role of project_space_id.

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

Parameters1/5

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

Schema coverage is 0% with no descriptions. The description only explains the 'name' parameter (by human-readable name) but ignores 'project_space_id', leaving its role unclear.

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 verb 'look up', the resource 'sub-project's project_id', and the method 'by its human-readable name'. It distinguishes this tool from siblings like list_projects and register_project.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives, nor are there any exclusions or prerequisites mentioned.

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

list_documentsA

List all documents belonging to the given sub-project.

ParametersJSON Schema

Name	Required	Description	Default
`project_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior2/5

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

No annotations provided, so the description carries full burden. It only states 'List all documents' which implies a read operation, but does not disclose permissions, error handling, pagination, or safety details. Minimal behavioral info beyond the action.

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?

One sentence of 9 words, perfectly front-loaded with the action and resource. No wasted words.

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 simple operation (list documents) and the presence of an output schema (which likely covers return format), the description is largely complete. However, it lacks clarification on the 'sub-project' terminology versus the parameter name 'project_id', and does not mention how to obtain the ID. Minor gaps prevent a perfect score.

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 description explains that project_id identifies the sub-project whose documents are listed, adding meaning beyond the schema (which only has type and required). With 0% schema description coverage, the description compensates adequately for a single 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 action (List), resource (documents), and scope (belonging to a given sub-project). It distinguishes from sibling tools like get_document (singular) and push_document (mutating). No tautology.

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

Usage Guidelines3/5

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

The description implies when to use (when you need all documents for a project), but does not provide explicit when-not-to-use or alternatives. No mention of prerequisites like how to obtain the project_id. Sibling names offer some context but the description itself lacks explicit guidance.

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

list_projectsC

List all sub-projects in the given project space.

ParametersJSON Schema

Name	Required	Description	Default
`project_space_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.6/5.0

Behavior1/5

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

No annotations are provided, so the description carries full burden. It fails to disclose any behavioral traits such as read-only nature, required permissions, pagination, or output format. The description is too minimal for a tool with no annotations.

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 a single sentence, highly concise and front-loaded with the verb and resource. However, it sacrifices informativeness for brevity.

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

Completeness2/5

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

With only one parameter, no annotations, and a simple purpose, the description still lacks important context such as authentication requirements, output format, or pagination. It is inadequate for a complete understanding.

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

Parameters1/5

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

Schema description coverage is 0%. The description does not add any meaning to the parameter 'project_space_id' beyond its name. It only implies that the parameter identifies a project space, but no format, restrictions, or examples are given.

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 action ('List all sub-projects') and the context ('in the given project space'). It distinguishes from sibling tools like 'list_documents' which lists documents, and 'get_project_id_by_name' which retrieves a single project by name.

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

Usage Guidelines2/5

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

No guidance on when to use this tool over alternatives, no prerequisites mentioned, and no exclusions provided. The description only states what it does without any contextual usage advice.

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

patch_documentA

Apply a unified diff patch to an existing document, producing a new version.

Use instead of push_document when only part of the document changed — avoids sending the full content and works around tool-call payload size limits.

patch must be in unified diff format (output of difflib.unified_diff). base_version must match the current latest version; if not, returns PATCH_BASE_MISMATCH — call get_document to fetch latest and regenerate.

ParametersJSON Schema

Name	Required	Description	Default
`project_id`	Yes
`doc_id`	Yes
`base_version`	Yes
`patch`	Yes

TDQS

A4.6/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. Discloses patch format requirement, base version constraint, error return (PATCH_BASE_MISMATCH), and recommended follow-up. Lacks explicit mention of side effects (e.g., whether changes are persisted immediately), but 'producing a new version' implies non-destructive versioning.

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?

Three sentences with no fluff. First sentence states purpose, second gives usage comparison, third details format and error handling. Front-loaded with core information, each sentence earns its place.

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 no annotations, no output schema, and 4 required parameters, the description covers purpose, usage guidance, patch format, error case, and fallback. Could briefly mention what the tool returns (e.g., new version object) but overall quite 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 has 0% description coverage. Description adds meaning for 'patch' (must be unified diff format) and 'base_version' (must match latest, otherwise error). Does not elaborate on 'project_id' or 'doc_id', but these are self-explanatory from context. Overall, compensates well for missing schema descriptions.

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?

Clearly states 'Apply a unified diff patch to an existing document, producing a new version' with specific verb (apply), resource (document), and outcome (new version). Also explicitly distinguishes from sibling push_document by noting when to use it.

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

Usage Guidelines5/5

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

Explicitly says 'Use instead of push_document when only part of the document changed' and explains benefits (avoids full content, works around payload limits). Also describes error condition for base_version mismatch and remediation (call get_document).

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

publish_draftC

Confirm a draft document version, publishing it and triggering notifications.

ParametersJSON Schema

Name	Required	Description	Default
`project_id`	Yes
`doc_id`	Yes
`version`	Yes

TDQS

C2.9/5.0

Behavior2/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 mentions side effects (triggering notifications) but fails to disclose idempotency, error states, required permissions, or what happens if the draft is already published. Behavioral transparency is low.

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

Conciseness3/5

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

The description is very concise (one sentence, 9 words) with no fluff. However, it is too brief to convey necessary detail, sacrificing completeness for brevity. It earns a middle score for being efficient but insufficient.

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

Completeness2/5

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

Given the complexity (3 required parameters, no annotations, no output schema), the description is incomplete. It lacks information on return values, error conditions, parameter details, and comprehensive behavioral context. The agent would need to guess or infer many aspects.

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

Parameters2/5

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

Schema description coverage is 0%, requiring the description to explain parameters. However, the description does not mention any parameter by name or role. The three required parameters (project_id, doc_id, version) remain unexplained, leaving the agent to infer their semantics.

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 action ('Confirm a draft document version, publishing it and triggering notifications') and identifies the resource type. It distinguishes this tool from siblings; no other sibling mentions publishing drafts or confirming versions, making its purpose unique.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like patch_document or push_document. It does not mention prerequisites, scenarios, or when not to use it, leaving the agent without decision support.

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

push_documentC

Push a new document version to the exchange center.

ParametersJSON Schema

Name	Required	Description	Default
`project_id`	Yes
`doc_id`	Yes
`content`	Yes
`metadata`	No

TDQS

C2.4/5.0

Behavior2/5

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

No annotations are present, and the description provides no behavioral details such as idempotency, side effects, required permissions, or error behavior. For a mutation tool, this is insufficient.

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

Conciseness3/5

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

The description is a single sentence, which is concise but at the expense of essential information. It could be expanded slightly to include parameter hints or usage context without losing brevity.

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

Completeness2/5

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

Given no output schema, no annotations, and 4 parameters (3 required) with no documentation, the description fails to provide enough context for correct tool usage. Critical details about input and behavior are missing.

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

Parameters1/5

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

Schema coverage is 0%, and the description does not explain any parameters (project_id, doc_id, content, metadata). The agent receives no hints about format, constraints, or expected values beyond schema names.

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

Purpose4/5

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

The description clearly states the action and resource: 'Push a new document version to the exchange center.' It distinguishes from siblings like 'patch_document' or 'get_document' by emphasizing a new version push.

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

Usage Guidelines2/5

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

No usage guidelines are provided. The description does not specify when to use this tool versus alternatives like 'publish_draft' or 'patch_document', nor does it mention prerequisites or contexts.

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

register_projectC

ParametersJSON Schema

Name	Required	Default
`name`	Yes
`type`	Yes
`project_space_id`	Yes
`stage`	No	design

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are present, so the description must cover behavioral traits. It does not mention permissions, side effects, error handling, or response behavior. Only the creation action and parameter examples are noted.

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 short (two sentences plus a list) and front-loaded with the core purpose. It could be structured more clearly, but it is concise without unnecessary fluff.

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

Completeness2/5

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

Given 4 parameters, no output schema, and no annotations, the description is insufficient. It lacks return value information, usage context, error conditions, and completeness on parameter meaning, leaving gaps for the agent.

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?

The description adds value for 'type' and 'stage' by listing example values, which the schema does not provide. However, 'name' and 'project_space_id' are left unexplained, and schema description coverage is 0%, so the description only partially compensates.

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

Purpose4/5

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

The description clearly states the tool registers a new sub-project in a given project space, with a specific verb and resource. It lists possible values for type and stage, adding clarity, but does not explicitly distinguish from siblings like create_space.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives, preconditions, or scenarios where it should not be used. The description only gives example parameter values.

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.

16 tool updatesv1.0.0Jun 3, 2026
- First observedack_update
- First observedadd_subscription
- First observedcreate_space
- First observedgenerate_steering_file
- First observedget_config
- First observedget_document
- First observedget_my_tasks
- First observedget_my_updates
- First observedget_my_updates_with_context
- First observedget_project_id_by_name
- First observedlist_documents
- First observedlist_projects
- First observedpatch_document
- First observedpublish_draft
- First observedpush_document
- First observedregister_project

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.4/5.0

Scored 2026-06-03 05:35 across 16 tools

Disambiguation5/5

Each tool has a clearly distinct purpose. The only potential overlap (get_my_updates vs. get_my_updates_with_context) is resolved by the latter being a superset with explicit context. push_document and patch_document are differentiated by full vs. partial updates.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case (e.g., create_space, list_documents, ack_update). Minor abbreviation like 'ack' is acceptable and does not break consistency.

Tool Count5/5

16 tools cover spaces, projects, documents, notifications, subscriptions, and tasks. This is well-scoped for a project/document management server, not too many or too few.

Completeness3/5

The tool surface covers core create and read operations but lacks update and delete for projects, documents, subscriptions, and tasks. Missing create tasks and delete operations for multiple resources are notable gaps.

Maintenance

ActivitySlowing

ResponsivenessWithin a week

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

ainote B
io.github.seunghan91
Agent-native notes, tasks, dev-docs, vaults, sync & handoffs. MCP + OpenAPI dual surface.
Note Taking Developer Tools Knowledge & Memory
353
mkdshare.DEV A
io.github.PhilipAnd
Publish and share access-controlled Markdown documents from any MCP-enabled AI tool.
Content Management Systems Documentation Access Developer Tools
112
TablaCognitaOAuth
io.github.PStryder
MCP-native collaborative markdown editor with real-time AI document editing
Workplace & Productivity Note Taking App Automation
22
ctlsurf
com.ctlsurf
System-of-record notebook for AI coding agents: pages, datastores, tasks, skills over MCP.
Knowledge & Memory Developer Tools Autonomous Agents
2

Related MCP Servers

Memory Bank MCP Server
Knowledge & Memory Developer Tools
yywdandan
A
license
C
quality
D
maintenance
MCP protocol server for managing multi-project Markdown documents, supporting project isolation and LLM tool integration.
Updated a year ago (2025-05-21 05:37 UTC)
29
7 npm
4
MIT
en-quire
File Systems Documentation Access Version Control
nullproof-studio
A
license
Not graded
quality
A
maintenance
MCP server for structured document management of markdown and YAML files, with RBAC, git-based approval workflows, and semantic search, enabling agents to read, edit, and maintain documents under governance.
Updated 4 days ago (2026-09-10 01:56 UTC)
MIT
artifacty
Knowledge & Memory Developer Tools Agent Orchestration
raeseoklee
A
license
Not graded
quality
A
maintenance
A local, agent-to-agent artifact exchange for LLM workflows. Enables MCP-capable tools like Claude, Codex, and Gemini to publish, list, read, update, and continue from artifacts without copying content through chat.
Updated 3 days ago (2026-09-10 07:54 UTC)
167 npm
MIT
Nyxdocofficial
Workplace & Productivity Note Taking
getnyxdoc
A
license
Not graded
quality
A
maintenance
MCP server for Nyxdoc, a document system where humans and external agents collaborate on documents with version history, agent to-dos, and workspace permissions.
Updated a month ago (2026-08-14 00:29 UTC)
MIT

AgentNexus

The problem

What AgentNexus does

1. Content travels out-of-band → zero token cost

2. SDAOP — the service onboards the agent, not the other way around

Quick Start

Run with Docker

Web Dashboard

Key Features

Out-of-Band Write Endpoint

MCP Tools

Configuration

Running Tests

Paper

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Nyxdocofficial