Skip to main content
Glama
sebastienrousseau

noyalib-mcp

by sebastienrousseau
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

Contents

Getting started

The noyalib-mcp ecosystem

Library reference

Operational

Related MCP server: mcp-json-yaml-toml

Install

As a Rust library

[dependencies]
noyalib-mcp = "0.0.51"

Install or run the server through the channel that fits the host:

cargo install noyalib-mcp --locked
npx @sebastienrousseau/noyalib-mcp
docker run --rm -i ghcr.io/sebastienrousseau/noyalib-mcp:latest

Requirements

  • Rust 1.88.0 or newer when building from source.

  • Linux, macOS, and Windows are tested by CI.

  • The crate pins noyalib at exactly =0.0.51 under the lockstep contract.

  • An MCP client is required to drive the server.

Surface

Minimum toolchain

Enforcement

Server and library

Rust 1.88.0

manifest and MSRV CI

Complete test surface

Rust 1.88.0

all-target CI

Quick Start

Use stdio for a child-process integration:

noyalib-mcp

A stdio client begins with an MCP initialization request before sending the initialized notification or listing tools:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-11-25",
    "capabilities": {},
    "clientInfo": {
      "name": "example",
      "version": "0.0.1"
    }
  }
}

Serve streamable HTTP at /mcp, or the legacy HTTP+SSE bridge at /sse and /messages/:

noyalib-mcp --transport streamable-http --host 127.0.0.1 --port 8000
noyalib-mcp --transport sse --host 127.0.0.1 --port 8001

The server negotiates supported MCP revisions during initialize; clients should not send raw tool calls before completing that handshake.

The noyalib-mcp ecosystem

Component

Role

noyalib-mcp

MCP server, transports, tools, prompts, and resources

noyalib

YAML parser, CST editor, and schema validator

noya-cli

Human-facing formatting and validation commands

rmcp

Official Rust MCP SDK used for protocol handling

Capabilities at a glance

Area

Capability

Status

Transport

stdio, streamable HTTP, and HTTP+SSE

Supported

Protocol

Revisions from 2024-11-05 through 2026-07-28

Negotiated

Results

Text plus typed structuredContent

Supported

YAML

Parse, get, set, multidocument set, edit, and validate

Supported

Metadata

Tool schemas, annotations, examples, prompts, and resources

Published

Ecosystem comparison

Delivery surface

Lossless YAML edits

Remote transport

Typed tool results

noyalib-mcp

Yes

HTTP and SSE

Yes

noya-cli

Yes

No

Not applicable

noyalib

Yes

No

Native Rust types

See docs/COMPARISON.md for scope and evidence.

Benchmarks

The checked-in mcp_tools Criterion harness measures tool dispatch and YAML operations without treating noisy timing values as correctness gates.

cargo bench --bench mcp_tools

See docs/BENCHMARKS.md for methodology.

Features

  • Six typed tools for YAML reads, edits, parsing, and validation.

  • Declared outputSchema, structuredContent, annotations, and examples.

  • stdio, streamable HTTP, and legacy HTTP+SSE transports.

  • Prompts and resources for agent integration.

  • Protocol revision negotiation and session-aware routing.

Configuration

Option

Effect

--transport stdio

Use process stdin and stdout; this is the default

--transport streamable-http

Serve MCP at /mcp

--transport sse

Serve /sse and /messages/

--host ADDRESS

Bind an HTTP transport to an address

--port PORT

Select the HTTP listening port

Bind remote transports deliberately. The default loopback host avoids exposing the server beyond the local machine.

Examples

Client configuration recipes are in docs/agent-integration.md.

When not to use noyalib-mcp

  • Use noyalib directly inside a Rust application that does not need MCP.

  • Use noya-cli for shell pipelines and repository-wide validation.

  • Do not expose an HTTP transport to an untrusted network without an authentication and authorization layer in front of it.

  • The server does not fetch remote schemas; callers must supply trusted schema content.

The detailed README reference retains client setup, tool detail, verification steps, and conformance discussion.

Development

make
make test
make clippy
make fmt
cargo fuzz run fuzz_tool_call

CI checks Rust formatting, linting, tests, documentation, dependency policy, fuzz regressions, protocol behaviour, and the shared YAML test suite. See DEVELOPMENT.md.

Security

Report vulnerabilities through SECURITY.md. The crate forbids unsafe code, audits dependencies, uses bounded noyalib operations, and emits release attestations and SBOMs. Treat file content, YAML, schemas, and MCP metadata as untrusted input.

Documentation

Stability guarantees

  • During 0.0.x, the patch component is the breaking-change axis.

  • Tool names, argument schemas, output schemas, and transport routes form the public compatibility surface.

  • Protocol revisions are negotiated rather than inferred.

  • The MSRV may rise only on the breaking axis with a changelog explanation.

License

Licensed under either Apache License 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.

  1. 2 tool updates
    • First observednoyalib_get
    • First observednoyalib_set
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

A4.6/5.0

Scored across 2 tools

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

Resources

Related MCP Connectors

Related MCP Servers

  • mcp-server-llmling

    phil65
    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

  • mcp-ollama

    true-alter
    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.
    19 npm
    Apache 2.0