What can you do with this server?

This server enables you to capture, manage, and finalize a structured provenance record (asset-record.json) for an agentic software asset during its build. * Inspect the record contract (get_record_schema): Retrieve the full JSON Schema defining the required fields, types, and validation rules for asset-record.json. * Record creation facts incrementally (record_facts): Deep-merge technical facts—language, framework, runtime, direct dependencies, repository identity, creation timestamp—into the record as they become known. Can be called repeatedly; each call merges into what is already on disk. * Read the current record (read_record): Fetch the existing asset-record.json to see which author-only fields (created_by, maintained_by, model_access.mode) are still missing. A missing file is treated as an empty state, not an error. * Finalize and lock the record (finalize_record): Mark the record as complete. Requires explicit author confirmation of the three author-only fields, either passed directly (after the agent asks the author in conversation) or collected via client-side elicitation. Writes a confirmation block; refuses to write if any confirmation is missing or the record would be invalid. * Target any directory: All tools accept a directory argument, writing asset-record.json in that location. * Secure and isolated: Runs with no network access, environment variables, or secrets—only local file manipulation. * Guided workflow prompt (create_asset_record): Walks through the capture → review → confirm process end to end.

How do I use CodeRoot-Authoring-MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@CodeRoot-Authoring-MCP Create the asset-record.json for my new agentic asset" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

CodeRoot-Authoring-MCP

Official

by SettleTop-Inc

Overview Schema Related Servers Score Discussions

Python

Local

CodeRoot-Authoring-MCP

An MCP server that captures an agentic asset's foundational record while the asset is being built. It writes and maintains a single file, asset-record.json, at the root of the repository being built — creation facts (language, framework, runtime, direct dependencies, repository identity) plus three facts only the author can assert (created_by, maintained_by, model_access.mode). The file is committed alongside the code and read downstream (by CodeRoot) as declared provenance. It never affects how the asset is classified.

This server has no configuration, no network access, and no secrets. It reads and writes one JSON file in a directory the caller names.

The record contract

{
  "record_version": 1,
  "created_by": "settletop-niles",
  "created_at": "2026-08-09T00:00:00Z",
  "source_repo": {"host": "github.com", "owner": "SettleTop-Inc", "name": "example"},
  "maintained_by": "SettleTop-Inc",
  "technologies": {
    "language": "python",
    "framework": "mcp",
    "runtime": "python>=3.11",
    "dependencies": ["mcp", "httpx"]
  },
  "model_access": {"mode": "byo", "provider": null, "model": null},
  "confirmation": {
    "mode": "elicitation",
    "confirmed": ["created_by", "maintained_by", "model_access.mode"],
    "complete": true
  }
}

record_version is required and always 1.
model_access.mode is "pinned" or "byo"; pinned requires a non-null provider and model, byo forces both null.
technologies.dependencies is DIRECT dependencies only (not the resolved tree) — at most 50 entries, 100 chars each.
Every string field must be non-blank and at most 200 chars.
Unknown top-level keys are ignored (forward compatible).

This is a summary. The machine-readable contract — the one the server itself validates against — is served live via the record://schema resource (and identically by the get_record_schema tool), so a client can always fetch the current shape instead of trusting a copy in this file.

Related MCP server: CarpeOS MCP Server

The creation workflow

The new_asset prompt is a twelve-step workflow for building a new MCP server or agent: decide what it does, whether it is really an agent, what it must never do, how you will know it worked, what it can use and when it stops — then make the repo, build, test on real work, containerise, prove the same tests pass inside the image, and ship a tag. The first six get worse if asked after a scaffold exists, which is why the order is enforced rather than suggested.

Two tools hold your place, so you are not tracking twelve steps by hand:

Tool	Arguments	Returns
`next_step`	`directory: str = "."`	`{"step": <int>, "title": ..., "asks": ..., "done": [...], "remaining": [...]}`, or `{"complete": true}`
`complete_step`	`step: int`, `answer: str`, `directory: str = "."`	`{"recorded": <int>, "next": {...}}`, or `{"error": "<code>", ...}`

They read and write WORKFLOW.md at the repo root — the checklist is the state, so the place you are up to survives a session ending or someone picking the work up a week later. complete_step refuses a step whose predecessors are unanswered (E_OUT_OF_ORDER), refuses a blank answer, and does not count a ticked box with nothing under it.

WORKFLOW.md is committed with the code and is the account of why the asset is the way it is. asset-record.json remains the facts of record — the file anything downstream reads. The workflow calls record_facts at steps 7 and 8 and finalize_record at step 12, so following it produces both.

Tools

Tool	Arguments	Returns
`get_record_schema`	—	`RECORD_SCHEMA` (the JSON-Schema-shaped contract) directly
`record_facts`	`patch: dict`, `directory: str = "."`	`{"record": ..., "missing": [...]}` on success, `{"error": "<code>", ...}` on rejection
`read_record`	`directory: str = "."`	`{"record": ..., "missing": [...]}` on success (an empty record if no file exists yet), `{"error": "<code>", ...}` on rejection
`finalize_record`	`confirmations: dict`, `directory: str = "."`, `mode: str = "conversation"`	`{"record": ..., "missing": []}` on success, `{"error": "<code>", ...}` on rejection — rejection writes nothing

record_facts deep-merges its patch into the existing record and is meant to be called repeatedly, as each fact is decided during the build. finalize_record is the only tool that marks a record complete: it requires the author's own confirmation of created_by, maintained_by, and model_access.mode, and refuses to write anything if the resulting record would be invalid or a confirmation is missing.

There is also a record://schema resource (identical to get_record_schema), the new_asset prompt above, and a create_asset_record prompt that walks the capture → review → confirm sequence on its own for an asset built without the full workflow.

Install

Two ways to run it: a prebuilt container from GHCR, or straight from a local checkout with uv. Both speak MCP over stdio and both write asset-record.json into a directory you name. Nothing else — no environment variables, no tokens, no network.

Run with Docker (GHCR)

The image is published to GitHub Container Registry as ghcr.io/settletop-inc/coderoot-authoring-mcp, but the package is private, so authenticate once on this machine before pulling — otherwise docker pull / docker run returns 403:

# One-time. Use a GitHub Personal Access Token (classic) with the
# read:packages scope as the password.
docker login ghcr.io -u <github-username>
# Or, with the gh CLI:
#   gh auth refresh -s read:packages && gh auth token | docker login ghcr.io -u <github-username> --password-stdin

Then run the server against the repo you are authoring. Because it writes into a directory, bind-mount that repo and attach stdin:

docker run --rm -i -w /work -v "$PWD:/work" ghcr.io/settletop-inc/coderoot-authoring-mcp

-i attaches stdin — required for a stdio MCP server; without it the server has no channel to speak on and exits immediately.
-v "$PWD:/work" mounts the repo being authored into the container, so the asset-record.json the server writes lands on your host and survives the container exiting.
-w /work makes /work the container's working directory, so the tools' default directory="." resolves to your mounted repo. The image's own working directory is /app, which is not mounted; without -w /work a tool called with the default . writes inside the container and the file is lost on exit. So either pass -w /work as shown, or call the tools with an explicit directory="/work". (Every tool also accepts an arbitrary directory argument, so the agent can target any repo path directly.)

On Windows, use ${PWD} in PowerShell or %CD% in cmd.exe in place of $PWD.

Tags: :latest and :sha-<short> track main; a release is tagged :vX.Y.Z. No -e flags are needed — this server reads no environment.

Run locally (uv)

Straight from a checkout, no container:

uv run --directory <path-to-this-repo> python -m authoring.server

Replace <path-to-this-repo> with wherever you've cloned CodeRoot-Authoring-MCP. Installing the package also exposes a coderoot-authoring-mcp console script (authoring.server:main), an equivalent entry point to python -m authoring.server for clients that prefer to invoke it directly. The server talks stdio and needs no environment variables, tokens, or network access.

Use with Claude Code

Register the server with claude mcp add. Claude Code launches it as a subprocess and speaks MCP over its stdin/stdout, so the whole launch command goes after the --.

Docker (private GHCR image — run docker login ghcr.io first, see above):

claude mcp add coderoot-authoring -- docker run --rm -i -w /work -v "$PWD:/work" ghcr.io/settletop-inc/coderoot-authoring-mcp

On Windows PowerShell, brace the variable — bare $PWD: is a PowerShell parser error (it reads : as a drive/scope qualifier) — so use ${PWD}:

claude mcp add coderoot-authoring -- docker run --rm -i -w /work -v "${PWD}:/work" ghcr.io/settletop-inc/coderoot-authoring-mcp

${PWD} is captured when you run claude mcp add, so run it from the repo you want to author (or replace it with an explicit path, e.g. "C:\path\to\repo:/work").

Local checkout (uv):

claude mcp add coderoot-authoring -- uv run --directory <path-to-this-repo> python -m authoring.server

Make it global, and reload. claude mcp add defaults to local scope — the server is available only in the directory you ran it in, so it won't appear in a session for a different project. Add --scope user to register it for every project. MCP servers connect when a session starts, so restart Claude Code (or open a new chat) after adding — a mid-session add won't show until then.

Confirm it connected. Run the /mcp command inside Claude Code (there is no MCP menu or button — /mcp lists each server, its connection status, and its tools), or claude mcp list in a terminal:

claude mcp list

coderoot-authoring should show as connected, and inside a Claude Code session its six tools — next_step, complete_step, record_facts, read_record, finalize_record, get_record_schema — plus the create_asset_record prompt become available.

Configuration

There is nothing to configure: authoring/server.py constructs the server at import with no settings to read, no config file, and no secrets. The only things that decide where the record is written are the bind mount and the directory argument the tools already take:

Name	Required?	Meaning
(environment variables)	—	None. The server reads no environment variables, tokens, or credentials, and makes no network calls.
`-v "<host-repo>:/work"` (docker)	Docker only	Bind-mounts the repo being authored into the container so writes survive the container exiting.
`-w /work` (docker)	Recommended	Makes the mount the container's working directory, so the tools' default `directory="."` lands in your repo. Otherwise pass `directory="/work"`.
`directory` (tool argument)	No (default `.`)	Every tool takes it; the record is always written to `<directory>/asset-record.json`. Local (uv) runs resolve `.` against the server process's working directory.

Skill

skills/creating-agentic-assets/SKILL.md teaches an agent to use this server proactively while building a new asset — capture facts as they're decided, finalize before the first push, and never assert the author-only fields on the author's behalf. Install it by copying or symlinking the skill directory into ~/.claude/skills/:

ln -s "$(pwd)/skills/creating-agentic-assets" ~/.claude/skills/creating-agentic-assets

(On Windows, copy the directory instead of symlinking, or use mklink /D from an elevated shell.)

Confirmation modes

finalize_record supports two ways to get the author's confirmation of the three author-only fields:

mode="conversation" (the default, and the floor) — the calling agent asks the author in the conversation, in its own words, and passes their answers in confirmations. This works with any MCP client, since it needs no special capability, and is what the skill instructs agents to use unless the client is known to support interactive prompting (see "Client support" below).
mode="elicitation" — the server asks the client to prompt the author directly, via a typed elicitation request (AuthorConfirmation). Prefer it only for a client you know supports interactive prompting: over MCP, a client that hasn't declared form-elicitation capability gets a protocol-level error (JSON-RPC -32021) before the tool body even runs, and as of this writing the interactive accept path has not been observed live for any client (see "Client support" below — only the cancel path has, over Claude Code headless). The {"error": "confirmation_unavailable", ...} shape only occurs for in-process/direct invocation, not over MCP.

Either way, the confirmation is checked against what was actually passed to finalize_record in that call — a value written earlier via record_facts is never treated as a confirmation of itself.

Client support

Live findings, Claude Code headless (claude -p --mcp-config, 2026-08-09):

Instructions: injected. A fresh instance quoted the server's instructions first sentence verbatim, unprompted, and listed all four tools — the ambient contract reaches the agent on this client.
Elicitation: capability declared. finalize_record(mode="elicitation") did not hit the JSON-RPC -32021 capability error; the elicit request went through, the non-interactive harness cancelled it, and the server returned {"error": "confirmation_cancelled"} with nothing written — the cancel path verified over the real wire.
Interactive accept path: not yet observed live. The SDK-level accept flow is covered end-to-end by this repo's tests (a real in-memory client answering the elicitation); whether interactive Claude Code renders the form to a human author remains to be confirmed the first time this server is used in a live interactive session. Until then, mode="conversation" stays the default and the floor — see "Confirmation modes" above.

Development

Requires Python >= 3.11.

uv sync --extra dev
uv run pytest -q

152 tests, all green.

License

GPL-3.0-or-later. See LICENSE.

Security

This server handles no secrets: no tokens, no credentials, no network calls. Its filesystem authority is broader than a single fixed file, though: the directory argument every tool takes is unrestricted — absolute paths and .. segments are honored as given, a missing directory is created rather than rejected, and an existing asset-record.json at the target is merged into rather than refused. The server runs with exactly the privileges of the client that launched it — the MCP client is the trust boundary, not this server — and what bounds what can be written is that the filename is never caller-controlled: every write lands at <directory>/asset-record.json, always that exact basename.

Available Tools

4 tools

finalize_recordA

Mark the asset record complete, before the first push. Requires the author's own confirmation of created_by, maintained_by and model_access.mode -- pass them in confirmations (mode="conversation", the default, after asking the author), or set mode="elicitation" to have the client prompt the author directly, in which case confirmations is ignored. Writes a confirmation block recording which fields were confirmed. Returns {"record": , "missing": []} on success, or {"error": "", ...} on rejection -- rejection writes nothing at all, and happens when a confirmation is missing or blank or when the resulting record would be invalid.

ParametersJSON Schema

Name	Required	Default
`mode`	No	conversation
`directory`	No	.
`confirmations`	Yes

TDQS

A4.5/5.0

Behavior5/5

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

With no annotations, the description carries the full burden. It discloses side effects ('Writes a confirmation block'), failure behavior ('rejection writes nothing at all'), and specific rejection conditions (missing/blank confirmation or invalid record). This is thorough behavioral transparency.

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 three sentences and front-loaded with the core action. It packs significant detail (confirmations, modes, side effects, return values) without excessive verbosity. Slightly longer than necessary but every sentence contributes value.

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?

For a state-changing operation with no output schema, the description is fairly complete: it explains success and error return shapes, prerequisites, and side effects. The only notable omission is the `directory` parameter, which is not explained, and there is no explicit mention of how the tool fits with sibling tools.

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 coverage is 0%, but the description adds substantial meaning for the key parameters: it explains `confirmations` (must contain created_by, maintained_by, model_access.mode) and `mode` (conversation vs elicitation, with elicitation ignoring confirmations). However, the `directory` parameter is not mentioned at all, leaving a gap in the otherwise strong parameter explanation.

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 action: 'Mark the asset record complete, before the first push.' This is a specific verb+resource+timing that distinguishes it from siblings like read_record, get_record_schema, and record_facts, which are all read-only or schema-related.

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 clear context for when to use the tool ('before the first push') and explains the two modes (conversation and elicitation). It does not explicitly name alternatives, but the read-only siblings clearly do not perform finalization, making the usage context sufficiently clear.

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

get_record_schemaA

Return the asset-record.json contract: the fields, their types, and the rules a valid record must satisfy. A deliberate duplicate of the record://schema resource, so that a client with no resource support still has a way to read the contract.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It says "Return" implying read-only, and notes it is a deliberate duplicate, but does not explicitly state safety, auth requirements, or idempotency. It adds the context of the duplicate resource, which is useful.

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 concise sentences, front-loaded with the main action, and includes a relevant implementation note without fluff.

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

Completeness5/5

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

For a parameterless schema getter, the description fully covers its purpose, content, and the reason for existing (duplicate of a resource). No additional context is needed given the simplicity.

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?

There are zero parameters, so the schema is empty. The description adds value by explaining what the tool returns (fields, types, rules), satisfying the baseline for no-parameter tools.

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 uses a specific verb ("Return") and identifies the resource ("asset-record.json contract") and the content (fields, types, rules). It also distinguishes from siblings like read_record by focusing on schema rather than data or finalization.

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 states a specific use case ("a client with no resource support") and points to an alternative resource (`record://schema`). It doesn't explicitly contrast with sibling tools but the purpose is clear enough.

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

read_recordA

Read the current asset-record.json and report which author-only fields are still missing. Returns {"record": <the record, {} if no file exists yet>, "missing": [...]}, or {"error": "", ...} on rejection. A missing file is a normal state, not an error.

ParametersJSON Schema

Name	Required	Description	Default
`directory`	No		.

TDQS

A4.4/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden. It discloses the exact return shape, the error format, and explicitly states that a missing file is a normal state, not an error. This is full behavioral transparency.

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 sentences, each serving a distinct purpose: what the tool does, the return format, and error/missing-file behavior. It is front-loaded and contains no redundant information.

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

Completeness5/5

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

For a simple tool with no output schema, the description fully covers the return structure and error cases. It appropriately notes that a missing file is normal, preventing potential misinterpretation. The only gap is the directory parameter, but that is already accounted for in parameter semantics.

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 schema has one parameter 'directory' with default '.', but the description does not mention it at all. With schema description coverage at 0%, the description should clarify how the directory parameter relates to reading the asset-record.json, but instead it only says 'current asset-record.json', leaving ambiguity about the parameter's role.

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 reads the current asset-record.json and reports missing author-only fields. The verb 'Read' and resource 'asset-record.json' are specific, and the action is distinct from sibling tools like get_record_schema or finalize_record.

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 conveys clear context: use to read the record and see which author-only fields are missing. It does not explicitly compare to sibling tools or state when not to use, so it gets a 4 rather than a 5.

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

record_factsA

Record creation facts you have just decided or just written: language, framework, runtime, direct dependencies, repository identity, creation timestamp. Deep-merges into the existing record, so call it as often as facts arrive. Returns {"record": , "missing": []}, or {"error": "", ...} on rejection. Do NOT use this for created_by, maintained_by or model_access.mode -- those are the author's to confirm via finalize_record.

ParametersJSON Schema

Name	Required	Description	Default
`patch`	Yes
`directory`	No		.

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses deep-merge behavior, return format (merged record plus missing fields), and error responses on rejection. However, it doesn't explain what causes rejection or prerequisites like whether a record must already exist, leaving some behavioral gaps.

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 concise—three sentences covering purpose, usage pattern, and exclusions—with no wasted words. It is front-loaded with the primary purpose. Slight downside is that the return format is crammed into the second sentence, making it dense, but overall well-structured.

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 tool's complexity (nested patch object, no output schema, no annotations), the description provides sufficient context: when to call, what to include, what to avoid, and what to expect in the response. It misses directory semantics and error code specifics, but it is complete enough for an agent to select and invoke correctly.

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 0%, so the description must compensate. It explains the 'patch' parameter by listing acceptable fact fields (language, framework, etc.) and explicitly excludes author fields. However, the 'directory' parameter is not explained at all, and no details are given about value formats or required structure.

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 records creation facts (language, framework, runtime, dependencies, repository identity, timestamp) and explicitly distinguishes from sibling finalize_record by excluding author-only fields. The verb 'Record' plus resource specification leaves no ambiguity about its function.

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?

Explicit guidance is provided: 'call it as often as facts arrive' and a direct exclusion—'Do NOT use this for created_by, maintained_by or model_access.mode -- those are the author's to confirm via finalize_record.' This clearly indicates when to use the tool and when not, referencing the alternative tool.

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. Dates show when Glama detected each change.

4 tool updatesv0.1.0Aug 10, 2026
- First observedfinalize_record
- First observedget_record_schema
- First observedread_record
- First observedrecord_facts

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.6/5.0

Disambiguation5/5

Each tool has a clearly distinct role: schema retrieval, fact recording, record reading, and finalization. There is no functional overlap, and the descriptions explicitly delineate boundaries (e.g., record_facts vs. finalize_record).

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (get_, record_, read_, finalize_). The naming is predictable and unambiguous, with no mix of conventions.

Tool Count5/5

Four tools is an appropriate size for a focused authoring workflow. Each tool serves a necessary, non-redundant function, and the count falls well within the ideal 3-15 range.

Completeness5/5

The tool set covers the complete lifecycle of an asset record: reading the schema, recording facts, reading the current state, and finalizing with author confirmation. No obvious dead ends or missing operations for the stated purpose.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

AccordTrace A
io.github.Kosta1985
Tamper-evident proof creation and verification for AI agents via MCP, A2A, and REST.
Security AI & Machine Learning
91
mcp
io.artifacta
Artifact store for AI agents. Hosted OAuth at mcp.artifacta.io/mcp; local stdio via npm/PyPI.
File Systems Cloud Storage Developer Tools
21
ainote A
io.github.seunghan91
Agent-native notes, tasks, dev-docs, vaults, sync & handoffs. MCP + OpenAPI dual surface.
Note Taking Developer Tools Knowledge & Memory
353
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

tatastu-proof
Blockchain Web3 & Decentralized Tech
Tatastu-Labs
A
license
Not graded
quality
B
maintenance
Enables creating and verifying permanent, publicly verifiable content provenance stamps via MCP tools.
Updated 22 days ago (2026-08-15 04:27 UTC)
126
MIT
CarpeOS MCP Serverofficial
Knowledge & Memory RAG Systems
innocarpe
A
license
Not graded
quality
A
maintenance
Enables AI agents to capture, search, and manage structured memory from agent sessions with append-only events and provenance tracking, providing eight local MCP stdio tools.
Updated 22 days ago (2026-08-15 13:35 UTC)
Apache 2.0
Hoplon
File Systems Code Analysis Version Control
justguy
A
license
Not graded
quality
C
maintenance
Enables AI coding agents and hosts to enforce deterministic repository boundaries via MCP, providing structured reads, supervised edits, snapshots, audits, and recovery with machine-readable evidence.
Updated 13 days ago (2026-08-24 13:41 UTC)
MIT
Portable-Agent-Memory
Knowledge & Memory RAG Systems Databases
skywaller0
A
license
Not graded
quality
B
maintenance
Local-first, MCP-first cross-agent cognitive asset layer that enables agents to store, retrieve, govern, and migrate memory, roles, and verified skills as portable assets via MCP tools and SQLite.
Updated 18 days ago (2026-08-19 06:51 UTC)
1
Apache 2.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/SettleTop-Inc/CodeRoot-Authoring-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

CodeRoot-Authoring-MCP

The record contract

The creation workflow

Tools

Install

Run with Docker (GHCR)

Run locally (uv)

Use with Claude Code

Configuration

Skill

Confirmation modes

Client support

Development

License

Security

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

CarpeOS MCP Serverofficial

Latest Blog Posts

MCP directory API