Skip to main content
Glama

Contents


Related MCP server: mcp-json-yaml-toml

Install

cargo install noyalib-mcp

For environments without a Rust toolchain (the typical AI-agent deployment shape):

# npm wrapper — auto-downloads the matching binary on first run,
# caches under ~/.cache/noyalib-mcp/<version>/.
npx @sebastienrousseau/noyalib-mcp

# Container — multi-arch (linux/amd64, linux/arm64).
docker run --rm -i ghcr.io/sebastienrousseau/noyalib-mcp:latest

Split from the monorepo since v0.0.13. Prior versions shipped from sebastienrousseau/noyalib/crates/noyalib-mcp/ under the workspace-lockstep release cadence. From v0.0.13 onward noyalib-mcp lives here as its own crate, still released in strict lockstep with the parent noyalib at the same version. See ADR-0005 for the rationale and rollback recipe.

Both consume the same signed binary attached to every GitHub Release. See Verification for the verify commands.


Requirements

  • Rust 1.86.0 or newer to build from source: rust-version in the manifest, enforced by the msrv-core CI job on every push.

  • Any tier-1 platform. CI runs the tests on Linux, macOS, and Windows with the stable, beta, and nightly toolchains; stable is the gate, beta and nightly are early warning.

  • The matching core. This crate pins noyalib at the identical =0.0.X and releases in lockstep with it; Cargo resolves that pin for you.

  • An MCP client speaking JSON-RPC 2.0 over stdio (2025-06-18 or 2026-07-28 protocol eras); the README's Connect section lists tested hosts.

Quick Start

The server speaks JSON-RPC 2.0 over stdio with newline-delimited frames, per the MCP specification. A typical agent launches the binary as a child process, sends initialize, then dispatches tool calls:

{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"agent","version":"0.0.1"}}}
{"jsonrpc":"2.0","method":"notifications/initialized"}
{"jsonrpc":"2.0","id":2,"method":"tools/list"}
{"jsonrpc":"2.0","id":3,"method":"tools/call",
 "params":{"name":"format","arguments":{"yaml":"a:1\nb:2\n"}}}

Why this approach?

AI agents that edit YAML configuration today regex-replace and corrupt comments, indentation, and document structure. The same agent fixing a port number in a Kubernetes manifest can shift every comment by a line, reorder sibling keys, or strip trailing whitespace that a downstream linter cared about.

noyalib's CST does the edits losslessly — a set("server.port", "9090") rewrites only the byte span of the 8080 scalar; the surrounding comments and indentation pass through untouched. This server is the protocol shim that lets MCP-aware clients drive that engine safely:

  • Lossless mutation. tools/call set returns a document byte-identical to the input outside the touched span.

  • Surgical reads. tools/call get walks the dotted path and returns just the value, not the whole tree.

  • Schema validation. tools/call validate --schema runs the same JSON Schema 2020-12 engine noyavalidate ships.

  • Stdio transport. Standard MCP. Works with every spec-compliant client.


Connect

Claude Desktop / Claude Code

claude mcp add noyalib $(which noyalib-mcp)

Cursor

~/.cursor/mcp.json:

{
  "mcpServers": {
    "noyalib": {
      "command": "noyalib-mcp"
    }
  }
}

Zed

~/.config/zed/settings.json:

{
  "context_servers": {
    "noyalib": {
      "command": { "path": "noyalib-mcp" }
    }
  }
}

Continue.dev

~/.continue/config.json:

{
  "experimental": {
    "modelContextProtocolServers": [
      { "transport": { "type": "stdio", "command": "noyalib-mcp" } }
    ]
  }
}

Any other MCP-aware client

Point at the binary; the transport is stdio with newline- delimited JSON-RPC 2.0.


Tools

The v0.0.1 server registers two file-oriented tools — both operate on a YAML file at file: <path>, not on inline source strings, so an agent's edits land on disk losslessly:

  • noyalib_get — Takes { file: string, path: string }; returns the raw source fragment at the dotted/indexed path (e.g. server.host, items[0].name). No re-quoting; no canonicalisation.

  • noyalib_set — Takes { file: string, path: string, value: string }; returns the file rewritten via the lossless CST so only the touched span changes; comments, blank lines, and sibling formatting survive byte-for-byte. The value is a YAML fragment (0.0.2, "hello", [1, 2, 3]); a parse failure leaves the file unchanged.

Each tool's full input schema lives in the response to tools/list. The server also handles the standard initialize / initialized / notifications/cancelled lifecycle.

Format / parse / validate are not exposed as MCP tools today — they're available via the noya-cli binaries (noyafmt, noyavalidate) and the noyalib library API. Promotion to first-class MCP tools is on the v0.0.2+ roadmap.


Examples

Agent-driving demos under crates/noyalib-mcp/examples/:

Script

What it shows

handshake.sh

initializetools/list smoke test. Confirms the binary speaks the protocol and announces the expected tools.

format-call.sh

tools/call format on a poorly-spaced document. Demonstrates that comments + indentation pass through the CST formatter unchanged.

set-then-get.sh

Round-trip the mutation surface: set rewrites server.port, get reads it back. Surgical edit; surrounding bytes untouched.

chmod +x crates/noyalib-mcp/examples/*.sh
crates/noyalib-mcp/examples/handshake.sh | jq -c .

POSIX-shell only — no jq, no node dependencies. Pipe through jq -c . if you want pretty-printed JSON responses.


Verification

GitHub Releases ship the crate archive and a CycloneDX SBOM, each with a sigstore bundle and checksums; the GHCR image is built from the tagged source. Pre-built binaries are not attached to releases yet. To verify a release artefact:

COSIGN_EXPERIMENTAL=1 cosign verify-blob \
  --certificate-identity-regexp 'https://github.com/sebastienrousseau/noyalib-mcp/' \
  --certificate-oidc-issuer 'https://token.actions.githubusercontent.com' \
  --bundle <artefact>.bundle \
  <artefact>

The npm wrapper additionally carries an npm provenance attestation:

npm view noyalib-mcp provenance

Full cookbook: pkg/VERIFY.md.


When not to use noyalib-mcp

  • You don't trust your AI agent with filesystem access at all. noyalib-mcp doesn't read or write files itself — every operation takes the YAML document as a string argument and returns the result as a string. The agent decides what to do with the result. If the agent has filesystem access, it can persist the response wherever it wants.

  • You need a sandboxed schema registry. noyalib-mcp accepts schemas as inline strings in tools/call validate; it does not fetch schemas from URLs. If your workflow needs network-resolved schemas, the agent is responsible for fetching the schema first and passing the bytes.


Compatibility

MSRV: Rust 1.86.0 stable — the lowest toolchain this crate can be built and tested on, matching the noyalib core floor. criterion 0.8 (the benchmark dev-dependency) declares rust-version = 1.86, so cargo check --all-targets and the bench suite fail on 1.85 with criterion@0.8.2 requires rustc 1.86cargo check --lib alone still builds on 1.85. We publish the number we verify. The MCP wire surface itself is text-only JSON-RPC and pulls no nightly-only deps. CI verifies the floor on every PR via the Per-crate MSRV workflow job. The bump policy lives in docs/POLICIES.md.

Tier-1 platforms (CI-verified each PR): aarch64-apple-darwin, x86_64-unknown-linux-gnu, x86_64-pc-windows-msvc. The binary writes via atomic file replacement on every platform — on Windows via MoveFileExW(MOVEFILE_REPLACE_EXISTING | MOVEFILE_WRITE_THROUGH) semantics.


Documentation

The four entry points, identical across every repo in the family:


Sibling MCP servers by the same author — open-source, Apache-2.0 licensed, targeting banking and financial-services AI agents. noyalib-mcp complements them by giving agents lossless YAML editing for structured configuration files:

Server

Purpose

pain001-mcp

Generate & validate ISO 20022 pain.001 payment initiation files (Customer Credit Transfer)

bankstatementparser-mcp

Parse bank statements (BAI2, MT940/MT942, CAMT.053, OFX, CSV) into structured transactions

camt053-mcp

Parse & reconcile ISO 20022 camt.053 bank-to-customer statements — CBPR+/HVPS+ ready

acmt001-mcp

Generate & validate ISO 20022 acmt.001 account management messages


MCP Registry

mcp-name: io.github.sebastienrousseau/noyalib-mcp


License

Dual-licensed under Apache 2.0 or MIT, at your option.

Available Tools

2 tools
noyalib_getRead a YAML value (lossless)A
Read-onlyIdempotent

Read the YAML value at a dotted/indexed path in the given file and return the source slice exactly — no re-quoting, no canonicalisation, comments and formatting preserved. Use this to inspect a value before changing it; use noyalib_set to write a value back losslessly.

ParametersJSON Schema
NameRequiredDescriptionDefault
fileYesPath to the YAML file on disk.
pathYesDotted/indexed path into the YAML, e.g. `server.host` or `items[0].name`.

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, etc. Description adds specifics about returning source slice exactly, preserving comments and formatting, which adds value beyond annotations.

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

Conciseness5/5

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

Two sentences that efficiently convey purpose and usage guidance with zero wasted words.

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 read-only tool with two parameters, the description covers behavior, usage context, and alternatives. No output schema needed.

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

Parameters3/5

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

Schema coverage is 100% with adequate descriptions. The description provides example path formats, adding slight value over schema alone. Baseline 3 is appropriate.

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

Purpose5/5

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

The title and description clearly state it reads a YAML value at a path, with specific details about losslessness and preservation of formatting. It distinguishes from the sibling noyalib_set.

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 this to inspect a value before changing it; use noyalib_set to write back losslessly,' providing clear when-to-use and alternative guidance.

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

noyalib_setWrite a YAML value (lossless)A
DestructiveIdempotent

Set the YAML value at a dotted/indexed path in the given file, rewriting only the touched span so every comment, blank line, and sibling entry is preserved byte-for-byte (written atomically). Use this for Renovate-style version bumps and config patches; use noyalib_get first when you need to read the current value. On a parse error the document is left unchanged.

ParametersJSON Schema
NameRequiredDescriptionDefault
fileYesPath to the YAML file on disk.
pathYesDotted/indexed path into the YAML.
valueYesReplacement value as a YAML fragment (e.g. `0.0.2`, `\"hello\"`, `[1, 2, 3]`). Must parse in the target position; the document is left unchanged on parse error.

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already indicate mutating and idempotent. Description adds valuable context: lossless rewriting, atomicity, and preservation of comments/blanks. No contradiction with annotations.

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, front-loaded with core behavior. Every sentence adds unique information: purpose/feature, usage guidance, error behavior. No 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 mutation tool with no output schema, description covers essential aspects: input parameters, behavior (atomic, lossless), error handling. Sufficient for correct agent invocation.

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 100%, but description adds examples and constraints for the 'value' parameter (YAML fragment, parse requirement), enhancing understanding beyond 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 states a specific verb ('Set'), resource ('YAML value at a dotted/indexed path'), and key behavior ('lossless', 'atomic'). It clearly distinguishes from sibling 'noyalib_get' by focusing on writing vs reading.

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 when to use ('Renovate-style version bumps and config patches') and recommends reading first with 'noyalib_get'. Also explains behavior on parse error, leaving document unchanged.

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.

  1. 2 tool updates
    • First observednoyalib_get
    • First observednoyalib_set

TDQS

A4.6/5.0
Disambiguation5/5

The two tools have completely distinct and complementary roles: one for reading values (noyalib_get) and one for writing values (noyalib_set). There is no overlap in functionality, and the descriptions explicitly guide when to use each.

Naming Consistency5/5

Both tools follow a consistent 'noyalib_verb' pattern with clear action verbs 'get' and 'set'. The naming is predictable and matches conventional CRUD terminology.

Tool Count4/5

With only two tools, the set is minimal but appropriate for the focused purpose of reading and writing YAML paths losslessly. It covers the core operations without unnecessary bloat, though additional operations like deletion could be warranted.

Completeness4/5

The tools cover the essential read and write operations for YAML path manipulation. However, there is no tool for deleting or listing paths, which might be needed in some workflows. The set is complete for its stated use case (version bumps and config patches) but not fully generic.

Maintenance

ActivityActive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    C
    maintenance
    A server for the Machine Chat Protocol (MCP) that provides a YAML-based configuration system for LLM applications, allowing users to define resources, tools, and prompts without writing code.
    6
    MIT
  • A
    license
    Not graded
    quality
    B
    maintenance
    MCP server wrapping local Ollama models for offload from API-priced orchestrators. Nine stdio tools - generation, summarisation, analysis, drafting, code tasks (docstring/test/explain/review/types/refactor-suggest), diff-driven tasks (commit-message/pr-description/changelog/summary/impact), mechanical transforms, and model management (list/pull). Apache-2.0.
    20
    Apache 2.0

Latest Blog Posts

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/sebastienrousseau/noyalib-mcp'

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