Skip to main content
Glama
leif-cipriani

nmos-mcp

by leif-cipriani
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Remote

nmos-mcp

An MCP server for AMWA NMOS. It connects to an NMOS Registry, lets an agent query everything on the network (IS-04) and — the headline feature — connect senders to receivers to route media between devices (IS-05).

  • IS-04 (Discovery & Registration) — read Nodes, Devices, Senders, Receivers, Flows, Sources and Subscriptions from the registry's Query API.

  • IS-05 (Device Connection Management) — connect/disconnect, enable/disable senders, inspect staged/active state, and bulk-route.

  • Works against a plain-HTTP lab registry or an HTTPS deployment with IS-10 OAuth2 bearer tokens.

  • Finds the registry from NMOS_REGISTRY_URL, or auto-discovers it over mDNS (_nmos-query._tcp).

  • Security-first — a permission policy is enforced inside the server so an AI agent gets exactly the access it should have, and no more (see Permissions).

Designed with security in mind. This server exists to let an AI agent operate a live broadcast network, where a wrong connect can take a service to air or off it. Authorization is therefore enforced in code, before any request leaves the server — never as a system-prompt guideline the model could ignore or be talked out of. You grant an agent the minimum it needs (read-only, or writes limited to specific devices/groups); everything else is denied by default.

Two ways to run it

Option A — Local (Python venv)

Option B — Docker

Setup

pip install -e . in a venv

docker build -t nmos-mcp .

Best for

A laptop on the same network/VPN as the NMOS registry

Linux hosts / servers, or reproducible/isolated deployments

Networking

Uses the host's DNS, routes and VPN directly — simplest

The container must be able to reach the registry and each Node's IS-05 endpoint (see the caveats in the Docker section)

mDNS discovery

Works

Only with --network host on Linux

Steps 1–4 below cover Option A. The Docker path is in Run with Docker. Both are configured with the same NMOS_* environment variables (see Configure).

On a corporate laptop where the NMOS network is reachable only over VPN, Option A is usually the least friction — containers don't inherit the host's VPN DNS/routes by default. Use Docker where the registry and nodes are directly reachable from containers (e.g. a Linux box on the media network).

Related MCP server: mcp-agent-proxy

1. Install

cd nmos-mcp
python3 -m venv .venv
source .venv/bin/activate
pip install -e ".[dev]"          # or: uv pip install -e ".[dev]"

This creates the nmos-mcp console command inside .venv/bin/.

Note (this machine): the shell auto-activates another project's virtualenv, so plain python3 may be the wrong interpreter. If python3 -m venv fails, build the venv with the real interpreter: env -i HOME="$HOME" PATH="/usr/bin:/bin" /opt/homebrew/bin/python3 -m venv .venv and use .venv/bin/python / .venv/bin/nmos-mcp directly.

2. Configure

Copy .env.example to .env and point it at your registry:

cp .env.example .env
NMOS_REGISTRY_URL=http://registry.example.local   # leave UNSET to auto-discover via mDNS
NMOS_QUERY_VERSION=v1.3
NMOS_CONNECTION_VERSION=v1.1
NMOS_USE_HTTPS=false
NMOS_VERIFY_TLS=true
# Permissions (optional; see the Permissions section below):
# NMOS_PERMISSIONS_FILE=permissions.yaml
# NMOS_PERMISSIONS_MODE=enforce            # 'open' disables all checks (dev only)
# IS-10 auth (optional, for secured deployments):
# NMOS_AUTH_ENABLED=true
# NMOS_AUTH_TOKEN_URL=https://auth.local/oauth2/token
# NMOS_AUTH_CLIENT_ID=...
# NMOS_AUTH_CLIENT_SECRET=...

.env is git-ignored — internal hostnames (e.g. registry.example.local) and credentials never get committed. .env.example is the only env file in git.

.env is read relative to the process working directory. When Claude Code launches the server the working directory may differ, so pass the registry URL via -e in the Claude Code registration below (that value is stored in your private Claude config, not in the repo).

3. Start the server

The server speaks the MCP protocol over a transport — you normally don't run it by hand; an MCP client (Claude Code) launches it. To run it manually:

nmos-mcp            # stdio transport (what Claude Code / Claude Desktop use)
nmos-mcp --http     # streamable-HTTP transport

To poke at the tools interactively with the MCP Inspector:

mcp dev src/nmos_mcp/server.py

4. Add it to Claude Code

Register the server with the CLI (from anywhere). Use -e to inject the registry URL and -s local so it stays in your private config rather than the shared repo:

claude mcp add nmos \
  -s local \
  -e NMOS_REGISTRY_URL=http://registry.example.local \
  -- /ABSOLUTE/PATH/TO/nmos-mcp/.venv/bin/nmos-mcp

Verify it connected:

claude mcp get nmos       # Status: ✔ Connected
claude mcp list

Then in a Claude Code session just ask, e.g.:

"List the NMOS senders, then connect 'AES67 sender 4' to 'AES67 receiver 4'."

To update or remove it:

claude mcp remove nmos -s local          # then re-add with new flags

Scopes: -s local (default) keeps the server private to you for this project (stored in ~/.claude.json). -s user makes it available in all your projects. Avoid -s project (writes a committed .mcp.json) unless you deliberately want the registry URL shared with the team via git.

Claude Desktop (alternative client)

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "nmos": {
      "command": "/ABSOLUTE/PATH/TO/nmos-mcp/.venv/bin/nmos-mcp",
      "env": { "NMOS_REGISTRY_URL": "http://registry.example.local" }
    }
  }
}

Run with Docker (Option B)

Build the image:

docker build -t nmos-mcp .

The image runs the stdio server by default and takes the same NMOS_* environment variables. .env and policy files are not baked in (see .dockerignore) — pass configuration at runtime.

Register the containerised server with Claude Code (note docker run -i — the -i keeps stdin open for the MCP stdio protocol):

claude mcp add nmos -s user -- \
  docker run -i --rm \
    -e NMOS_REGISTRY_URL=http://registry.example.local \
    -e NMOS_PERMISSIONS_MODE=open \
    nmos-mcp

Streamable-HTTP instead of stdio (long-running, exposes a port). Set NMOS_HTTP_HOST=0.0.0.0 so the server binds all interfaces and the published port is reachable (it defaults to 127.0.0.1):

docker run --rm -p 8000:8000 \
  -e NMOS_REGISTRY_URL=http://registry.example.local \
  -e NMOS_HTTP_HOST=0.0.0.0 \
  nmos-mcp --http
# clients connect to http://localhost:8000/mcp

With Docker Compose — a long-running HTTP service (binds 0.0.0.0, publishes 8000, restarts, health-checked); reads NMOS_* from your git-ignored .env:

docker compose up -d --build      # start
docker compose logs -f            # follow
docker compose down               # stop

Register the HTTP endpoint with Claude Code:

claude mcp add nmos-http -s user --transport http http://localhost:8000/mcp

A permission policy is mounted at runtime rather than built in:

docker run -i --rm \
  -e NMOS_REGISTRY_URL=http://registry.example.local \
  -e NMOS_PERMISSIONS_FILE=/policy.yaml \
  -v "$(pwd)/permissions.yaml:/policy.yaml:ro" \
  nmos-mcp

Networking — the important caveat

The container must be able to reach both the registry and every Node's IS-05 endpoint (often raw 192.168.x addresses on the media LAN).

  • Linux host: add --network host so the container resolves names and routes exactly like the host. This is also the only way mDNS auto-discovery works in a container.

  • Docker Desktop (macOS/Windows): --network host maps to Docker's Linux VM, not your machine, so corporate/VPN DNS names may not resolve and VPN-only subnets may be unroutable. Work around it by pointing NMOS_REGISTRY_URL at an IP, adding --add-host registry.example.local:<ip>, or --dns <corporate-dns> --dns-search <your.domain>. mDNS discovery does not work here. If the NMOS network is only reachable over the host's VPN, prefer Option A.

Tools

IS-04 (query): registry_info, list_nodes, list_devices, list_senders, list_receivers, list_flows, list_sources, get_resource, query_resources.

IS-05 (connection): get_sender, get_receiver, get_sender_transport_file, connect_sender_to_receiver, disconnect_receiver, enable_sender, disable_sender, bulk_connect, stage_receiver, stage_sender.

Visualisation: crosspoint_matrix (read-only — router-style grid of all routes).

Permissions: permissions_info (read-only — shows the active policy).

Crosspoint matrix

A broadcast-router-style overview of every connection at once: senders are columns, receivers are rows, and a cell shows X where a receiver is subscribed to a sender (o = subscribed but inactive, . = not connected), with legends mapping the S1/R1 codes to labels and IDs. It's built from the receivers' IS-04 subscription data — one registry query, no per-Node calls.

Two ways to view it:

  • From the terminal — the nmos-crosspoint CLI (installed alongside nmos-mcp):

    nmos-crosspoint              # colourised when the output is a TTY
nmos-crosspoint --no-color

  • From an agent — ask Claude to call the crosspoint_matrix tool ("show me the crosspoint matrix").

                         │ S1  S2  S3  S4  S5  S6  S7  S8  S9  S10
─────────────────────────┼────────────────────────────────────────
R5 AES67 receiver 3      │ .   .   .   .   .   X   .   .   .   .
R6 AES67 receiver 4      │ .   .   .   .   .   .   X   .   .   .

How a connection is made

The Query API lives on the registry; the Connection API (IS-05) lives on each Node. To wire a sender to a receiver the server:

  1. Looks the receiver up in the registry and reads its device's controls array to find the IS-05 endpoint (urn:x-nmos:control:sr-ctrl).

  2. Fetches the sender's SDP transport file.

  3. PATCHes the receiver's /staged with the sender id, master_enable: true, the transport file, and activation: { mode: activate_immediate }.

  4. Reads back the receiver's /active state to confirm the route.

The connection endpoint version is taken from the device's advertised control href, so nodes exposing IS-05 v1.0 or v1.1 both work.

Permissions (MCP-enforced authorization)

This is the server's core security mechanism: give an AI agent just the access it should have. Write actions can route real media, so the server enforces an authorization policy in code, before any HTTP call — it is not a system-prompt guideline and cannot be talked around by the LLM. Scope an agent down to read-only, or to writes on a single studio/rack, and everything else is denied by default.

Posture:

  • Reads/queries are always allowed (discovery is never blocked).

  • Every write action must be explicitly granted by a rule whose scope matches the target. Actions: connect, disconnect, enable, disable, stage (write = all five). Anything not granted is denied; explicit deny rules override allows.

  • connect/disconnect/stage on a receiver are checked against the receiver; enable/disable/stage on a sender are checked against the sender.

Enable it by pointing at a policy file:

NMOS_PERMISSIONS_FILE=permissions.yaml     # YAML or JSON
NMOS_PERMISSIONS_MODE=enforce              # 'open' bypasses all checks (dev/testing)

In enforce mode with no file, all write actions are denied. Copy permissions.example.yaml to start. One policy applies per running server; give someone a different role by registering a second MCP server with its own policy and NMOS_PERMISSIONS_FILE.

Groups of devices can be defined by NMOS tags, explicit device UUIDs, label regex, or by Node (a resource matches if any selector matches the resource or its owning device). Minimal example — allow routing only onto the AES67 receivers:

groups:
  aes67_rx:
    labels: ["^AES67 receiver"]
rules:
  - actions: [connect, disconnect]
    groups: [aes67_rx]

Ask the agent to call permissions_info to see exactly what the running server will allow. Every write decision is written to stderr as an AUDIT ALLOW/DENY line. See permissions.example.yaml for tags/UUID/node examples and deny rules.

Test

pytest

Unit tests mock both the Registry Query API and a Node Connection API (via respx), covering the connect/disconnect PATCH bodies, endpoint resolution, config coercion and URL handling.

End-to-end against a real registry

Point NMOS_REGISTRY_URL at a live registry (or a local EasyNMOS stack: docker run -d --net=host rhastie/easy-nmos), then use mcp dev or Claude Code to list_senders / list_receivers, run connect_sender_to_receiver, and confirm the receiver's /active shows the sender's multicast group.

Scope & roadmap

Current: IS-04 read/query + IS-05 connection management. The module layout leaves room to add IS-04 registration writes, IS-08 audio channel mapping, IS-07 events/tally and IS-09 system parameters as additional tool groups.

Available Tools

19 tools
bulk_connectA

Connect several Sender->Receiver pairs at once.

pairs is a list of objects like {"sender_id": "...", "receiver_id": "..."}. Batched per Node via the IS-05 /bulk/receivers endpoint.

ParametersJSON Schema
NameRequiredDescriptionDefault
pairsYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior2/5

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

No annotations are present, so the description carries full burden. It mentions batching via IS-05 endpoint but does not disclose potential partial failures, idempotency, atomicity, or error handling behavior for the batch operation.

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 concise sentences with no redundancy: purpose, parameter format, and implementation detail. Every sentence adds value.

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?

Despite having an output schema (unseen), the description lacks details on error handling, behavior on partial success, and comparison with connect_sender_to_receiver. For a bulk operation, this is insufficient context.

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 provides an explicit example of the expected object structure for the `pairs` parameter, compensating for the lack of schema descriptions and clarifying the required keys.

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 connects multiple Sender→Receiver pairs simultaneously, distinguishing it from the sibling tool connect_sender_to_receiver which handles single pairs.

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?

Implied usage from 'several' and 'at once', and 'Batched per Node' gives some context, but there is no explicit guidance on when to prefer this over connect_sender_to_receiver, nor on prerequisites or alternatives.

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

connect_sender_to_receiverA

Connect a Sender to a Receiver (route media) with an immediate IS-05 activation.

Pulls the Sender's SDP transport file and stages it on the Receiver with master_enable=true, then activates immediately. Returns the Receiver's resulting active state.

ParametersJSON Schema
NameRequiredDescriptionDefault
sender_idYes
receiver_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description discloses the internal steps: pulling SDP, staging with master_enable=true, and immediate activation. However, it does not cover prerequisites 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.

Conciseness5/5

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

Two concise sentences front-loading the main action with 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?

The description explains the process and mentions the return value (active state), but lacks prerequisites or compatibility requirements.

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 while the description uses sender_id and receiver_id in context (e.g., pulling transport file), it does not explicitly define their purpose or constraints 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 'Connect a Sender to a Receiver' with specific verb and resources, and distinguishes from siblings like bulk_connect by highlighting immediate activation.

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 usage for one-step connection with activation but does not explicitly state when to use this tool versus alternatives like stage_receiver or bulk_connect.

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

disable_senderB

Disable a Sender (master_enable=false) so it stops transmitting, with immediate activation.

ParametersJSON Schema
NameRequiredDescriptionDefault
sender_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.3/5.0
Behavior3/5

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

Without annotations, the description carries full burden. It discloses the core behavioral detail (immediate activation via master_enable=false), but does not cover side effects, reversibility, or permission requirements.

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 concise sentence. It could be slightly restructured to front-load critical info, but is efficient and readable.

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?

For a simple tool with one required parameter and no annotations, the description is minimally adequate. However, it lacks guidelines and param details, leaving gaps in actionable context.

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 coverage is 0% for the sole parameter sender_id. The description adds no semantic detail beyond the parameter name, leaving the agent without formatting or source context.

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 (disable), the resource (Sender), the mechanism (master_enable=false), and the effect (stops transmitting immediately). It effectively distinguishes from the sibling enable_sender.

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 disable vs enable_sender, or any prerequisites. The agent must infer usage from context.

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

disconnect_receiverA

Disconnect a Receiver (clear its subscription and disable it) with immediate activation.

ParametersJSON Schema
NameRequiredDescriptionDefault
receiver_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.5/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 discloses that the tool clears subscription and disables the receiver with immediate activation, but does not mention side effects, authorization needs, or destructive nature beyond 'disable'.

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 that efficiently conveys the action and its nuances. No unnecessary words or repetition.

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 simple tool with one parameter and an output schema (not shown), the description adequately explains the core action. It could be improved by mentioning what the output schema contains or return behavior, but it is largely complete.

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%. The description does not elaborate on the single parameter 'receiver_id' beyond what the schema provides (title 'Receiver Id'). No examples or format hints 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 verb 'Disconnect' and the resource 'Receiver', and explains that it clears the subscription and disables it with immediate activation. This is specific and distinguishes it from siblings like 'disable_sender' or 'connect_sender_to_receiver'.

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 explicit guidance on when to use this tool versus alternatives like 'disable_sender' or 'stage_receiver'. The description only states what it does, without context for choosing it over siblings.

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

enable_senderB

Enable a Sender (master_enable=true) so it transmits, with immediate activation.

ParametersJSON Schema
NameRequiredDescriptionDefault
sender_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations provided, the description must disclose behavioral traits itself. It mentions immediate activation and setting master_enable=true, but does not address side effects, reversibility, authorization needs, or any other behavioral characteristics. Critical information is missing.

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 and front-loaded, consisting of a single sentence that conveys the core purpose. However, it is slightly too brief, omitting needed details for the few dimensions it covers.

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 parameter minimalism and absence of behavioral details, the description is insufficient for confident tool selection and invocation, despite the presence of an output schema. It fails to provide enough context beyond the basic action.

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?

There is only one parameter (sender_id), but with 0% schema description coverage, the description should explain its meaning. It does not, assuming the agent knows what a sender ID is. This lack of semantic detail hampers correct invocation.

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 (enable a sender), the target resource (Sender), and the effect (master_enable=true, transmits, immediate activation), distinguishing it from sibling tools like disable_sender.

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 that the tool is used to activate a sender, but it provides no explicit guidance on when to use it versus alternatives (e.g., stage_sender) or any prerequisites. The context from sibling names offers some clarity, but the description itself lacks direct usage advice.

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

get_receiverC

Show a Receiver's IS-05 staged + active connection state and its constraints.

ParametersJSON Schema
NameRequiredDescriptionDefault
receiver_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

C2.9/5.0
Behavior2/5

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

No annotations provided, and description does not disclose behavioral traits such as read-only nature, authentication requirements, or side effects. It only states what is shown, not how it behaves.

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?

Single sentence, front-loaded with key information. Concise but at the cost of completeness.

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?

Output schema exists but not shown; description mentions connection state and constraints, covering main purpose. However, missing parameter guidance and usage context reduce completeness.

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 has one parameter with 0% description coverage. The description does not explain what receiver_id is or how to obtain it, leaving the agent with no guidance 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?

Description uses specific verb 'Show' and resource 'Receiver', and details IS-05 staged+active connection state and constraints, clearly distinguishing from sibling tools like 'get_sender'.

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 explicit guidance on when to use this tool vs alternatives like 'list_receivers' or 'get_resource'. The description does not help the agent decide.

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

get_resourceB

Get one resource by id. kind is one of: nodes, devices, sources, flows, senders, receivers, subscriptions.

ParametersJSON Schema
NameRequiredDescriptionDefault
kindYes
resource_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.4/5.0
Behavior3/5

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

No annotations exist, so the description carries full burden. It indicates a read operation, but does not disclose authorization needs, rate limits, or error handling. Acceptable for a simple retrieval.

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 that efficiently conveys the purpose and valid kinds with no unnecessary 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 an output schema exists and the tool is a simple retrieval, the description covers core functionality. However, it could mention that resource_id refers to a resource of the given kind.

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 0%, so description must compensate. It adds meaning for 'kind' by listing valid values, but provides no additional detail for 'resource_id'.

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 'Get one resource by id' and lists the possible values for 'kind', making the purpose clear. However, it does not explicitly distinguish from sibling tools like 'get_receiver' or 'get_sender'.

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 generic getter vs the specific getters (e.g., get_receiver). No when-not or alternatives provided.

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

get_senderB

Show a Sender's IS-05 staged + active connection state and its constraints.

ParametersJSON Schema
NameRequiredDescriptionDefault
sender_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.3/5.0
Behavior3/5

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

No annotations are provided, so the description bears full burden. It indicates a read-only operation ('Show') but does not disclose authentication needs, potential errors, or whether the operation is safe. Minimal behavioral disclosure.

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 extremely concise (one sentence) and front-loaded with the key action and resource. However, it lacks structure like bullet points or sections. It is appropriately sized for a simple read operation.

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?

Given the simplicity of the tool (one parameter, output schema present), the description is adequate but not fully complete. It does not mention return value structure (though output schema exists) or confirm read-only behavior comprehensively.

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 does not add any meaning for the 'sender_id' parameter beyond the schema title 'Sender Id'. It fails to explain what a sender_id is or how to obtain it.

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 a specific verb ('Show') and resource ('Sender's IS-05 staged + active connection state and its constraints'). It distinguishes itself from sibling tools like connect_sender_to_receiver or disable_sender by focusing on viewing state.

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 usage for viewing connection state but does not explicitly state when to use this tool versus alternatives (e.g., get_sender_transport_file or get_receiver). No guidance on prerequisites or limitations.

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

get_sender_transport_fileA

Fetch a Sender's SDP transport file (the description a Receiver needs to subscribe).

ParametersJSON Schema
NameRequiredDescriptionDefault
sender_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/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 full behavioral burden. It correctly indicates a read operation ('Fetch'), but lacks details on failure modes, authorization needs, or return value format.

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 one sentence of 14 words, concise and front-loaded with the essential action and purpose, with 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 tool's simplicity (one parameter, output schema exists), the description covers the key aspects: what it does and why it's needed. Minor omissions like expected output format are covered by the output schema.

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?

With 0% schema description coverage, the description must explain the sender_id parameter. While 'a Sender's SDP transport file' indirectly references it, there is no explicit description of the parameter's meaning or constraints, leaving ambiguity.

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 'Fetch a Sender's SDP transport file' and its purpose 'the description a Receiver needs to subscribe'. It uses a specific verb and resource, distinguishing it from sibling tools like get_sender.

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 usage context (needed by a Receiver to subscribe) but does not explicitly state when to use this tool versus alternatives, nor provide any exclusions or prerequisites.

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

list_devicesC

List NMOS Devices (a Node hosts one or more Devices).

ParametersJSON Schema
NameRequiredDescriptionDefault
labelNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

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 carry the full burden of behavioral disclosure. It only states basic listing function without mentioning read-only nature, pagination, ordering, or any 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 very short and front-loaded, but it sacrifices necessary detail for brevity. It is not maximally informative.

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?

Despite having an output schema, the description fails to explain return format or any behavioral context. For a tool with one optional parameter and no annotations, the description is too sparse to be fully useful.

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?

With 0% schema description coverage, the single parameter 'label' is undocumented. The description does not explain its purpose (e.g., filter by label) or format, leaving the agent to guess.

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 specifies the action 'List' and the resource 'NMOS Devices', and adds context that a Node hosts Devices, distinguishing it from other list tools like list_nodes.

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 does not provide any guidance on when to use this tool vs alternatives (e.g., list_nodes, list_receivers). It only implies hierarchical relationship but no explicit usage criteria.

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

list_flowsC

List Flows (the essence a Sender transmits).

ParametersJSON Schema
NameRequiredDescriptionDefault
labelNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.4/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden. It only states that it lists flows, but does not disclose whether it is read-only, whether there are limits, or any other behavioral aspects beyond the basic action.

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 short (two lines), but it lacks structure. It provides the purpose but no additional details. It earns a 3 because it is concise but not well-structured.

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 existence of an output schema, the description does not need to explain return values. However, it fails to provide usage context, parameter guidance, or behavioral details, making it incomplete for effective tool selection.

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 single parameter 'label' is not described in the description. Schema description coverage is 0%, so the description adds no meaning beyond the schema definition.

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 'List' and the resource 'Flows', and explains what a Flow is in parentheses. However, it does not differentiate from sibling tools like list_senders or list_receivers, which could be confused as listing similar entities.

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, context, or typical use cases.

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

list_nodesA

List NMOS Nodes in the registry. Optionally filter by label substring.

ParametersJSON Schema
NameRequiredDescriptionDefault
labelNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/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 states the action and optional filter but lacks details on read-only nature, pagination, or limits.

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, concise sentence that effectively communicates the tool's purpose and key feature without unnecessary 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 list tool with one optional parameter and an output schema, the description is complete enough; it covers purpose and filtering option.

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 adds meaning to the 'label' parameter beyond the schema by specifying it filters by substring, which is useful semantic context.

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 lists NMOS Nodes, which is a specific verb and resource, and distinguishes it from sibling list tools (e.g., list_devices, list_flows) by the resource type.

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 usage through the optional filter but does not provide explicit guidance on when to use this tool versus alternatives or any exclusions.

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

list_receiversC

List Receivers (media ingest points) advertised in the registry.

ParametersJSON Schema
NameRequiredDescriptionDefault
labelNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.7/5.0
Behavior2/5

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

No annotations provided, so description carries full burden. Merely states 'List' (read operation) without mentioning pagination, result format, side effects, or auth requirements. Misses opportunity to describe label parameter behavior.

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?

Single sentence, no waste, but under-specified. Could include parameter info or filtering hints without adding length.

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 a single optional parameter and an output schema, the description should at least explain the filtering capability. Many sibling tools make detailed descriptions necessary for correct selection, but this one is too brief.

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%, yet description omits any explanation of the 'label' parameter. Agent cannot infer its purpose or how it affects results.

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?

Description uses specific verb 'List' and resource 'Receivers' with clarifying parenthetical '(media ingest points)'. Clearly distinguishes from sibling list tools like list_senders or list_devices by naming the exact entity.

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 like list_senders, list_nodes, etc. Does not mention prerequisites, filtering behavior, or typical use cases beyond the vague 'advertised in the registry'.

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

list_sendersB

List Senders (media egress points) advertised in the registry.

ParametersJSON Schema
NameRequiredDescriptionDefault
labelNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3/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 only says 'advertised in the registry' but does not mention read-only nature, pagination, rate limits, or ordering. The minimal description leaves significant gaps for a list tool.

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 with no extraneous words. However, it could benefit from being more front-loaded with parameter info.

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 optional label parameter and sibling tools, the description is too sparse. It does not explain how filtering works, what the output contains (despite having an output schema), or how it differs from other list tools. Incomplete for a 1-parameter tool.

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?

With 0% schema description coverage, the description completely fails to address the optional 'label' parameter. It adds no meaning beyond what the schema provides, leaving the agent without guidance on filtering.

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 'List' and the resource 'Senders', and adds clarifying context '(media egress points)' that distinguishes it from sibling tools like get_sender (single) or disable_sender (action).

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 the tool is for listing many senders, but provides no explicit guidance on when to use it vs alternatives like get_sender or query_resources, nor any exclusions or conditions.

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

list_sourcesC

List Sources (the abstract origin of one or more Flows).

ParametersJSON Schema
NameRequiredDescriptionDefault
labelNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.7/5.0
Behavior2/5

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

No annotations provided, so the description bears full burden. It only states 'List', implying a read operation, but lacks details on side effects, permissions, or pagination.

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 concise sentence with no wasted words, though it is overly brief given the lack of schema descriptions.

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 description is adequate for a simple list tool with an output schema, but it fails to mention the optional 'label' parameter, leaving incomplete context.

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% (no descriptions in schema). The description does not mention the 'label' parameter at all, providing no added meaning.

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 lists 'Sources' (abstract origin of Flows), which is specific but does not differentiate from sibling tools like 'list_receivers' or 'list_senders'.

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. The description does not mention exclusions or context for use.

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

query_resourcesA

Query a resource collection with an IS-04 filter.

Pass label for a simple label match, or rql for an IS-04 RQL expression (e.g. eq(transport,urn:x-nmos:transport:rtp.mcast)).

ParametersJSON Schema
NameRequiredDescriptionDefault
rqlNo
kindYes
labelNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.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 should carry the burden of disclosure. It only implies a read operation ('query') without stating idempotency, safety, or side effects, leaving significant 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.

Conciseness5/5

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

Two concise sentences, front-loaded with purpose, no wasted words.

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?

Given no annotations and a required parameter 'kind' left unexplained, the description is adequate but incomplete. It lacks details on return format, pagination, or RQL behavior, though an output schema exists.

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 by explaining label and rql with an example, but it omits the required 'kind' parameter, which is not described anywhere. With 0% schema coverage, the description should compensate more fully.

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 explicitly states the tool queries a resource collection using an IS-04 filter, which clearly distinguishes it from sibling tools like list_* (*list all*) and get_resource (*single resource*).

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 explains how to use the two optional parameters (label for simple match, rql for RQL expressions) but does not explicitly state when to prefer this tool over siblings like list_devices.

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

registry_infoA

Show the resolved NMOS registry (config or mDNS), reachability and resource counts.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.1/5.0
Behavior3/5

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

The description indicates a read-only operation by stating 'Show', but does not explicitly declare non-destructive behavior. With no annotations provided, the description could more clearly assert that no state is modified.

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, front-loaded sentence that efficiently conveys the tool's purpose without extraneous words. Every phrase adds value.

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?

Given the presence of an output schema, the description appropriately summarizes the output (registry, reachability, resource counts) without redundancy. For a simple info tool with no parameters, the description is 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?

The tool has zero parameters, so the description naturally adds no parameter information. The input schema coverage is 100% (empty), making the description sufficient for parameter 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 tool shows the resolved NMOS registry, reachability, and resource counts. It uses a specific verb ('Show') and identifies the resource ('NMOS registry'), distinguishing it from siblings like list_devices or get_resource.

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 usage for inspecting registry configuration and status, but does not explicitly state when to use this tool versus alternatives such as list_devices or get_resource. No exclusion criteria or when-not-to-use guidance is provided.

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

stage_receiverC

Advanced: send a raw IS-05 staged PATCH body to a Receiver (full control of transport_params/activation).

ParametersJSON Schema
NameRequiredDescriptionDefault
patchYes
receiver_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

C2.4/5.0
Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It indicates a write operation that modifies receiver transport parameters and activation, but does not mention side effects (e.g., connection disruption), reversibility, permissions, error conditions, or rate limits.

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 concise sentence, which is efficient, but it is too short to provide necessary details for an advanced, low-level tool. It front-loads the 'Advanced:' qualifier but sacrifices substance 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 complexity (raw PATCH, nested object, no annotations, 0% schema coverage), the description is incomplete. It does not cover prerequisites, effects on receiver state, error handling, or the return value (though output schema exists). More context is needed for safe invocation.

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%, yet the description does not explain the two parameters: receiver_id (string) or patch (object with additionalProperties). It says 'raw IS-05 staged PATCH body' but does not clarify the expected structure or constraints, leaving the agent without guidance.

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 sends a raw IS-05 staged PATCH body to a Receiver, with 'Advanced:' flagging its intended audience. It distinguishes from siblings like connect_sender_to_receiver by emphasizing 'full control' and raw operation, but does not explicitly name alternatives.

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 explicit guidance on when to use this tool versus alternatives. The label 'Advanced:' implies it is for low-level control, but there are no when-to-use, when-not-to-use, or prerequisite instructions.

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

stage_senderB

Advanced: send a raw IS-05 staged PATCH body to a Sender (e.g. set multicast destination).

ParametersJSON Schema
NameRequiredDescriptionDefault
patchYes
sender_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are present, so the description carries full burden. It says 'send a raw... PATCH body' which is mutating, but does not disclose side effects, idempotency, state changes, or required permissions. The 'staged' term is ambiguous without further explanation.

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?

Single sentence with no redundancy, includes a helpful example in parentheses. Could benefit from brief additional structure (e.g., what 'staged' means) but remains 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?

Despite having an output schema (not shown), the description lacks information about return values, prerequisites, or how this tool fits among 17 siblings. The raw operation requires more context for safe 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 coverage is 0%, so description must compensate. It adds meaning by describing patch as a 'raw IS-05 staged PATCH body' and gives an example, but does not specify format, required fields, or constraints. sender_id remains underdescribed.

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 ('send') and resource ('raw IS-05 staged PATCH body to a Sender') with a concrete example ('set multicast destination'). This distinguishes it from sibling tools like connect_sender_to_receiver or enable_sender.

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 use for advanced raw operations but does not explicitly state when to use this tool vs alternatives like connect_sender_to_receiver or disable_sender. No exclusion criteria or prerequisites are given.

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. 19 tool updatesv0.1.0
    • First observedbulk_connect
    • First observedconnect_sender_to_receiver
    • First observeddisable_sender
    • First observeddisconnect_receiver
    • First observedenable_sender
    • First observedget_receiver
    • First observedget_resource
    • First observedget_sender
    • First observedget_sender_transport_file
    • First observedlist_devices
    • First observedlist_flows
    • First observedlist_nodes
    • First observedlist_receivers
    • First observedlist_senders
    • First observedlist_sources
    • First observedquery_resources
    • First observedregistry_info
    • First observedstage_receiver
    • First observedstage_sender
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

Scored across 19 tools

Disambiguation5/5

Each tool targets a distinct operation (list, get, connect, disconnect, enable, disable, stage, query, registry info) on specific resources (nodes, devices, sources, flows, senders, receivers). No two tools have overlapping functionality; the generic get_resource is clearly a fallback.

Naming Consistency5/5

All tools use a consistent verb_noun pattern (e.g., list_devices, connect_sender_to_receiver, disable_sender). Even bulk_connect follows the pattern with a compound verb. No mixing of styles.

Tool Count4/5

19 tools is slightly above the typical well-scoped range but still reasonable for an NMOS control server covering multiple resource types (nodes, devices, sources, flows, senders, receivers) and connection management. Each tool serves a clear purpose.

Completeness4/5

The tool set covers the core NMOS workflow: discovery, connection management, and transport file retrieval. Minor gaps exist, such as no subscription listing or resource creation, but these are not central to the server's apparent purpose.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • OBS MCP Server

    royshil
    A
    license
    B
    quality
    D
    maintenance
    A server that provides tools to control OBS Studio remotely via the OBS WebSocket protocol, enabling management of scenes, sources, streaming, and recording through an MCP client interface.
    100
    86
    125
    GPL 2.0

  • mcp-agent-proxy

    mashh-lab
    A
    license
    A
    quality
    F
    maintenance
    An MCP server that acts as a proxy to connect MCP clients to agent frameworks like Mastra and LangGraph, enabling agent discovery, dynamic server connections, and recursive agent networks.
    5
    8
    10
    MIT

  • quads-mcp

    grafuls
    A
    license
    Not graded
    quality
    D
    maintenance
    MCP server for interacting with QUADS infrastructure systems via API, enabling resource management and automation through LLM applications.
    MIT

  • nrs_llm

    eunseopsong
    A
    license
    Not graded
    quality
    D
    maintenance
    An MCP server for ROS 2 environments that connects via rosbridge WebSocket, enabling topic/service introspection, publish/subscribe, service calls, robot connectivity checks, and polishing pipeline operations.
    Apache 2.0