Skip to main content
Glama
deenesjakoruzh
nod-protocol

nod-mcp-server

Official
by nod-protocol
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Hybrid

nod-mcp-server

This is how AI agents will interact with businesses — not by scraping, but by reading structured manifests. This reference MCP server teaches any MCP-compatible client (Claude Desktop, agent frameworks, IDEs) to read a business's nod.json manifest at https://{domain}/.well-known/nod.json and answer real questions about what the business can do: order food, book an appointment, search products, check pricing, and more.

It exposes two tools — lookup_nod and check_capability — and bundles four demo manifests served locally so the demo works out of the box with zero external dependencies.

Install

git clone <this repo> nod-mcp-server
cd nod-mcp-server
npm install
npm run build

Requires Node.js 20+.

Related MCP server: Vexi MCP Server

Run the demo manifest server

Almost no real sites publish nod.json yet, so this repo bundles four example manifests (restaurant, e-commerce, SaaS, healthcare) and serves them locally.

npm run demo:manifests

You should see:

NOD demo manifest server listening on http://localhost:3456
  http://localhost:3456/demo-restaurant.localhost/nod.json
  http://localhost:3456/demo-shop.localhost/nod.json
  http://localhost:3456/demo-saas.localhost/nod.json
  http://localhost:3456/demo-health.localhost/nod.json

Leave this terminal running during the demo. The MCP server automatically routes any *.localhost domain to this server.

Configure Claude Desktop

Open (or create) ~/Library/Application Support/Claude/claude_desktop_config.json on macOS (or %APPDATA%\Claude\claude_desktop_config.json on Windows) and add:

{
  "mcpServers": {
    "nod": {
      "command": "node",
      "args": ["/ABSOLUTE/PATH/TO/nod-mcp-server/dist/index.js"]
    }
  }
}

Replace /ABSOLUTE/PATH/TO/nod-mcp-server with the full path to this checkout (e.g. /Users/you/projects/nod-mcp-server). Restart Claude Desktop. You should now see the nod server listed in Claude's tool picker with two tools: lookup_nod and check_capability.

60-second demo script

With the demo manifest server running in one terminal and Claude Desktop configured, paste these prompts into Claude one after another.

1. "Look up the NOD manifest for demo-restaurant.localhost"

Claude calls lookup_nod({ domain: "demo-restaurant.localhost" }) and returns something like:

# Pike Place Noodle House  (restaurant)
Hand-pulled noodles, dumplings, and regional Chinese classics...

- URL: https://demo-restaurant.localhost
- Manifest: http://localhost:3456/demo-restaurant.localhost/nod.json

## Declared capabilities
  - purchase
  - booking
  - view_menu
  - order_food
  - book_table

## Supported actions
  - purchase → https://demo-restaurant.localhost/api/orders [auth: api_key]
  - booking  → https://demo-restaurant.localhost/api/reservations [auth: api_key]
  - search   → https://demo-restaurant.localhost/api/menu/search [auth: none]

2. "Can I order food from demo-restaurant.localhost?"

Claude calls check_capability({ domain: "demo-restaurant.localhost", action: "order_food" }):

YES — demo-restaurant.localhost supports "order_food".
Manifest declares "order_food" under discovery.mcp_server.capabilities.

Endpoint: POST https://demo-restaurant.localhost/api/orders
Authentication: api_key
Matched via: discovery.mcp_server.capabilities

Constraints:
{ "require_human_confirmation": { "purchases_above": 150, ... },
  "rate_limits": { "transactions": { "requests": 10, "period": "minute" } },
  "allow_automated_purchases": true }

3. "What actions does demo-shop.localhost support?"

Claude calls lookup_nod({ domain: "demo-shop.localhost" }) and summarizes: product search, pricing, inventory checks, and OAuth2-protected order placement — with a human-confirmation threshold at $500 and a 60-day returns policy.

Bonus prompts

  • "Book an appointment at demo-health.localhost — what does that flow require?" → returns the booking endpoint, required fields (patient_name, DOB, reason, provider_id, preferred_date), OAuth2 scopes, and the cancellation policy.

  • "Does demo-saas.localhost allow automated purchases?" → returns NO with the human-fallback URL, because the manifest sets allow_automated_purchases: false.

Tool reference

lookup_nod

Input

Type

Description

domain

string

Domain only (no scheme, no path). *.localhost domains are routed to the bundled demo server.

Fetches https://{domain}/.well-known/nod.json, falling back to https://{domain}/nod.json. Returns a structured summary: business identity, declared capabilities, supported actions (with endpoints + auth), API endpoints, and contact methods. Returns a clear "no manifest found" message on failure.

check_capability

Input

Type

Description

domain

string

Domain only.

action

string

Common values: order_food, place_order, view_menu, book_table, book_appointment, search_products, find_provider, get_pricing, check_inventory, check_status, create_account, get_docs, contact_support.

Fetches the manifest and checks the action against transactions.capabilities, discovery.mcp_server.capabilities, support.contact.mcp_server.capabilities, and the structural endpoints (transactions.purchase, discovery.search, information.pricing, etc.). Returns a yes/no verdict, the endpoint URL, authentication method, and policy constraints (rate limits, human-confirmation thresholds).

How *.localhost routing works

When the MCP server receives a domain ending in .localhost, it fetches from http://localhost:3456/{domain}/nod.json instead of the normal well-known URL. This makes the demo self-contained — you can point Claude at demo-restaurant.localhost and get real results without any DNS or HTTPS setup.

Env vars:

  • NOD_LOCAL_PORT — port the demo manifest server listens on (default 3456)

  • NOD_LOCAL_MANIFEST_SERVER — base URL the MCP server uses for .localhost lookups (default http://localhost:3456)

  • NOD_FORCE_LOCAL=1 — route every domain through the local manifest server (useful for contributors testing new example manifests)

What's next

Publish a nod.json for your own business using the NOD Protocol spec at opennod.ai/protocol. A minimal, valid manifest takes about 30 minutes to write — and once it's live at https://yourdomain.com/.well-known/nod.json, any agent using this MCP server (or any other NOD-aware client) will be able to discover your business and act on its capabilities.

License

MIT

Available Tools

2 tools
check_capabilityCheck a NOD capabilityA

Given a domain and an action (e.g. order_food, book_appointment, search_products, get_pricing, view_menu, book_table, check_status, create_account), fetches the business's NOD manifest and reports whether the action is supported, the endpoint URL, authentication requirements, and any policy constraints.

ParametersJSON Schema
NameRequiredDescriptionDefault
domainYesThe domain to check (e.g. "demo-restaurant.localhost").
actionYesThe action to check. Common values: order_food, place_order, view_menu, book_table, book_appointment, search_products, find_provider, get_pricing, check_inventory, check_status, create_account, get_docs, contact_support.

TDQS

A4/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: it fetches a manifest, reports on support status, endpoint URL, authentication requirements, and policy constraints. This covers critical operational aspects like auth needs and constraints, though it could add details on rate limits or error handling.

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 front-loaded and efficiently structured in a single sentence that covers purpose, inputs, and outputs without waste. Every element (e.g., action examples, reported details) serves to clarify the tool's function, making it concise and well-organized.

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 moderate complexity (2 parameters, no output schema, no annotations), the description is largely complete: it explains what the tool does, what it returns, and key behavioral aspects. However, it could improve by mentioning the sibling tool 'lookup_nod' for better context or detailing output format, though the absence of an output schema makes this less critical.

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 input schema has 100% description coverage, providing clear definitions for 'domain' and 'action'. The description adds minimal value beyond the schema by listing example actions, but it doesn't elaborate on parameter interactions or constraints. Baseline score of 3 is appropriate as the schema does the heavy lifting.

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

Purpose5/5

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

The description clearly states the tool's purpose with specific verbs ('fetches', 'reports') and resources ('business's NOD manifest'), and it distinguishes from the sibling tool 'lookup_nod' by focusing on capability checking rather than general lookup. It provides concrete examples of actions like 'order_food' and 'book_appointment' to illustrate scope.

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 by specifying it checks 'whether the action is supported' and lists common actions, but it does not explicitly state when to use this tool versus alternatives like 'lookup_nod' or provide exclusions. It offers some guidance through examples but lacks direct comparative instructions.

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

lookup_nodLook up NOD manifestA

Fetches a business's NOD Protocol manifest from https://{domain}/.well-known/nod.json (or the local demo server for *.localhost domains) and returns a structured summary: business identity, declared capabilities, supported actions, API endpoints, and contact methods.

ParametersJSON Schema
NameRequiredDescriptionDefault
domainYesThe domain to look up (e.g. "example.com" or "demo-restaurant.localhost"). Do not include scheme or path.

TDQS

A4/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses the HTTP fetch behavior, URL construction pattern, and return format. However, it doesn't mention error handling, timeout behavior, authentication requirements, rate limits, or whether this is a read-only operation (though implied by 'fetches').

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 efficiently structured in a single sentence that front-loads the core action and resource, followed by specific return details. Every element (source URL, localhost exception, return structure) serves a clear purpose with zero redundancy.

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 single-parameter read operation with no output schema, the description provides good context about what gets fetched and returned. However, without annotations or output schema, it could benefit from more detail about error cases or response format specifics to be fully complete.

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 input schema has 100% description coverage, so the baseline is 3. The description doesn't add parameter-specific details beyond what the schema provides (domain format examples are already in schema). It mentions the URL construction but doesn't elaborate on parameter usage beyond the schema's documentation.

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 specific action ('fetches'), resource ('business's NOD Protocol manifest'), source URL pattern, and structured return format. It distinguishes from the sibling tool 'check_capability' by focusing on manifest retrieval rather than capability verification.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context about when to use this tool (to get a structured summary of business identity, capabilities, actions, endpoints, and contacts) and mentions the alternative server for localhost domains. However, it doesn't explicitly state when NOT to use it or directly compare with the sibling tool 'check_capability'.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 2 tool updatesv0.1.0
    • First observedcheck_capability
    • First observedlookup_nod
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0
Disambiguation5/5

The two tools have clearly distinct purposes: check_capability validates a specific action against a business's manifest, while lookup_nod retrieves and summarizes the entire manifest. There is no overlap or ambiguity between them, as one is for targeted validation and the other for general information retrieval.

Naming Consistency5/5

Both tools follow a consistent verb_noun pattern with snake_case naming: check_capability and lookup_nod. The verbs 'check' and 'lookup' are semantically appropriate and distinct, and the naming style is uniform throughout the set.

Tool Count2/5

With only two tools, the server feels under-scoped for its apparent purpose of interacting with NOD Protocol manifests. While the tools cover basic retrieval and validation, the lack of tools for actions like updating manifests, managing policies, or executing supported actions suggests a thin surface that may limit agent functionality.

Completeness2/5

The tool set is significantly incomplete for the NOD Protocol domain. It provides read-only access to manifests but lacks tools for creating, updating, or deleting manifests, or for actually executing the supported actions (e.g., order_food, book_appointment). This creates dead ends where agents can inspect but not interact with the business capabilities.

Maintenance

ActivityInactive
ResponsivenessSyncing

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

  • nod-mcp-server

    opennod
    A
    license
    A
    quality
    D
    maintenance
    Enables AI agents to discover and interact with business capabilities by reading structured nod.json manifests from domains, supporting actions like ordering, booking, and searching.
    2
    MIT
  • Vexi MCP Server by getvexi

    Vexi MCP Serverofficial

    getvexi
    A
    license
    A
    quality
    D
    maintenance
    Enables MCP clients to search and retrieve structured business data from the Vexi API, allowing AI agents to get clean, typed business objects with identity, offerings, and trust signals.
    4
    14
    MIT

  • agentweb-mcp

    zerabic
    A
    license
    A
    quality
    D
    maintenance
    Enables agents to search, retrieve, and contribute business data from a directory of 11M+ businesses across 195 countries, returning markdown prose by default.
    22
    115
    3
    MIT

  • AgentRank MCP

    saviodamato
    A
    license
    A
    quality
    C
    maintenance
    Provides AI agents with access to real, verifiable businesses with provenance and source URLs, enabling natural-language business search and profile retrieval.
    2
    MIT

Latest Blog Posts

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/nod-protocol/nod-mcp-server'

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