mcpField
T
topiclint

topiclint

Local
github.com/CloudCorpRecordsDeveloper Tools0Updated 1w ago

About topiclint

topiclint is a local, offline CLI and stdio MCP server for checking MQTT topic strings against Sparkplug B grammar and reviewing Unified Namespace paths for naming consistency. It reports syntax findings and namespace patterns without connecting to a broker.

Key features

  1. 01Lint Sparkplug B topic grammar
  2. 02Check UNS path consistency
  3. 03Detect duplicates and empty levels
  4. 04Flag wildcard and whitespace issues
  5. 05Report naming and depth patterns

Use cases

  1. 01Validate topics before broker publishing
  2. 02Review UNS paths during namespace design
  3. 03Find inconsistent casing or hierarchy depth

MCP support

Exposes two tools to MCP clients: one parses and checks Sparkplug topics, and the other reviews a set of paths for UNS naming issues. Both operate locally without network access.

Configuration

Local server config is the same for every client. Copy it into your client’s MCP config file.

mcp.json · Universal config
{
"mcpServers": {
"cloudcorprecords-topiclint": {
"command": "npx",
"args": [
"-y",
"@reneturcios/topiclint"
]
}
}
}
Run commandnpx -y @reneturcios/topiclint

Local servers need a runtime on your machine (e.g. Node.js 18+). Config file locations differ by client; see your client’s docs.

Packages
npm@reneturcios/topiclint0.1.0
ocighcr.io/cloudcorprecords/topiclint:0.1.0

Tools

2

Saved tool list · updated 1w ago

ParameterTypeRequiredDescription
topicsanyYesMQTT topic strings to validate against the Sparkplug B topic grammar or check for UNS naming consistency.

Details

From the project README

topiclint

topiclint checks MQTT topic strings before they reach a broker or a namespace design review. It lints individual topics against the Sparkplug B topic grammar (Sparkplug 3.0), and it reviews a whole set of Unified Namespace (UNS) topic paths for naming consistency — the kind of drift (mixed casing, uneven depth, near-duplicate siblings) that makes a namespace hard to browse, query, and hand over. One binary serves a command-line interface and a stdio MCP server.

Everything is local and offline. There is no broker connection, no network access, no API key, and no account. The linter validates grammar only: it does not decode payloads or check that a device exists. The naming check judges consistency only: it does not know your plant and will not design a namespace for you.

Install

npx @reneturcios/topiclint lint spBv1.0/Plant1/NBIRTH/Edge1

Or run the container image:

docker run -i ghcr.io/cloudcorprecords/topiclint

The container defaults to the MCP server (see below); pass CLI arguments to use it as a CLI instead.

CLI

topiclint lint spBv1.0/Plant1/NBIRTH/Edge1 spBv1.0/Plant1/DDATA/Edge1/Dev1
topiclint check enterprise/site1/line1 enterprise/site1/line2

topiclint --version

Each topic or path is one argument; a single argument may also be a newline-delimited list. Both commands print a JSON report. A report full of findings is still a successful run — findings are the output, not an error. Exit codes: 0 on success, 1 on a runtime error, 2 for usage errors.

What the Sparkplug lint checks

For every topic: the spBv1.0 namespace level; the message type (one of NBIRTH, NDEATH, DBIRTH, DDEATH, NDATA, DDATA, NCMD, DCMD, plus STATE); the level count (node messages and STATE carry exactly four levels, device messages exactly five); the legacy Sparkplug 2.2 STATE form (STATE/<host_id> with no namespace), reported as its own failure; publish-side MQTT wildcards (+ / #); empty levels; and identifier characters in the group, node, and device levels — whitespace fails, and characters outside [A-Za-z0-9_-] warn, because both break downstream consumers that split, quote, or map topics.

Each result carries the parsed topic parts (namespace, group id, message type, edge node id, device id) plus ordered findings with levels fail / warn / pass / info.

What the UNS check looks for

Across the whole set: duplicate paths, empty levels, whitespace in segments, and stray MQTT wildcards all fail. Siblings under the same parent whose names differ only by case fail as a case-collision — they read as one node but are two. Inconsistent hierarchy depth and mixed casing styles (lower, upper, snake_case, kebab-case, PascalCase, camelCase) warn. The report opens with a one-line summary, then the per-issue findings.

MCP server

One bin serves both faces. The mcp subcommand starts a stdio MCP server:

npx -y @reneturcios/topiclint mcp

MCP client configuration:

{
  "mcpServers": {
    "topiclint": {
      "command": "npx",
      "args": ["-y", "@reneturcios/topiclint", "mcp"]
    }
  }
}
Tools

Both tools take a single topics argument: a single string, a newline-delimited string, or an array of topic strings.

ToolInputWhat it returns
lint_sparkplug_topictopics (string or string array)Per-topic parsed parts plus ordered findings, with pass/fail counts and a summary.
check_uns_namespacetopics (string or string array)A summary line plus per-issue findings for the whole path set.

Development

npm install
npm run build   # tsc -> dist/
npm test        # node test runner over test/*.test.ts, no network
npm run dev     # run the CLI from source via tsx

License

MIT — see LICENSE.

Comments

Markdown supported

New to MCP?

From what the protocol is to installing your first server, these answers cover most first questions.

An open protocol that defines how AI applications connect to external tools and data in a uniform way. Clients talk to the model; MCP servers provide tools, resources and prompt templates. They exchange standard messages, so one server can be reused by many clients.