Skip to main content
Glama
deenesjakoruzh
nod-protocol

nod-mcp-server

Official
by nod-protocol
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

nod-mcp-server

이것은 AI 에이전트가 비즈니스와 상호작용하는 방식입니다. 스크래핑이 아닌 구조화된 매니페스트를 읽는 방식입니다. 이 참조 MCP 서버는 모든 MCP 호환 클라이언트(Claude Desktop, 에이전트 프레임워크, IDE)가 https://{domain}/.well-known/nod.json에 있는 비즈니스의 nod.json 매니페스트를 읽고, 음식 주문, 예약, 제품 검색, 가격 확인 등 비즈니스가 수행할 수 있는 작업에 대한 실제 질문에 답할 수 있도록 합니다.

이 서버는 lookup_nod와 check_capability라는 두 가지 도구를 제공하며, 로컬에서 실행되는 4개의 데모 매니페스트를 포함하고 있어 외부 의존성 없이 즉시 데모를 실행할 수 있습니다.

설치

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

Node.js 20+ 버전이 필요합니다.

Related MCP server: Vexi MCP Server

데모 매니페스트 서버 실행

아직 nod.json을 게시하는 실제 사이트가 거의 없으므로, 이 저장소에는 4개의 예제 매니페스트(레스토랑, 전자상거래, SaaS, 헬스케어)가 포함되어 있으며 로컬에서 실행됩니다.

npm run demo:manifests

다음과 같이 표시되어야 합니다:

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

데모가 진행되는 동안 이 터미널을 계속 실행해 두세요. MCP 서버는 모든 *.localhost 도메인을 이 서버로 자동으로 라우팅합니다.

Claude Desktop 설정

macOS의 경우 ~/Library/Application Support/Claude/claude_desktop_config.json을(를) 열거나 생성하고(Windows의 경우 %APPDATA%\Claude\claude_desktop_config.json), 다음을 추가하세요:

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

/ABSOLUTE/PATH/TO/nod-mcp-server를 이 체크아웃의 전체 경로(예: /Users/you/projects/nod-mcp-server)로 바꿉니다. Claude Desktop을 다시 시작하세요. 이제 Claude의 도구 선택기에서 lookup_nod와 check_capability라는 두 가지 도구가 포함된 nod 서버가 나열된 것을 볼 수 있습니다.

60초 데모 스크립트

한 터미널에서 데모 매니페스트 서버를 실행하고 Claude Desktop을 설정한 상태에서, 다음 프롬프트를 Claude에 차례대로 붙여넣으세요.

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

Claude는 lookup_nod({ domain: "demo-restaurant.localhost" })를 호출하고 다음과 같은 결과를 반환합니다:

# 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는 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는 lookup_nod({ domain: "demo-shop.localhost" })를 호출하고 제품 검색, 가격 책정, 재고 확인, OAuth2로 보호되는 주문 배치(500달러 이상의 인간 확인 임계값 및 60일 반품 정책 포함)를 요약합니다.

보너스 프롬프트

  • "Book an appointment at demo-health.localhost — what does that flow require?" → 예약 엔드포인트, 필수 필드(patient_name, DOB, reason, provider_id, preferred_date), OAuth2 범위 및 취소 정책을 반환합니다.

  • "Does demo-saas.localhost allow automated purchases?" → 매니페스트가 allow_automated_purchases: false로 설정되어 있으므로 인간 대체 URL과 함께 NO를 반환합니다.

도구 참조

lookup_nod

입력

유형

설명

domain

string

도메인만 입력(스키마, 경로 제외). *.localhost 도메인은 번들된 데모 서버로 라우팅됩니다.

https://{domain}/.well-known/nod.json을 가져오고, 실패 시 https://{domain}/nod.json으로 대체합니다. 비즈니스 식별 정보, 선언된 기능, 지원되는 작업(엔드포인트 + 인증 포함), API 엔드포인트 및 연락처 방법을 포함한 구조화된 요약을 반환합니다. 실패 시 명확한 "매니페스트를 찾을 수 없음" 메시지를 반환합니다.

check_capability

입력

유형

설명

domain

string

도메인만 입력.

action

string

일반적인 값: 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.

매니페스트를 가져와 transactions.capabilities, discovery.mcp_server.capabilities, support.contact.mcp_server.capabilities 및 구조적 엔드포인트(transactions.purchase, discovery.search, information.pricing 등)에 대해 작업을 확인합니다. 예/아니오 판정, 엔드포인트 URL, 인증 방법 및 정책 제약 조건(속도 제한, 인간 확인 임계값)을 반환합니다.

*.localhost 라우팅 작동 방식

MCP 서버가 .localhost로 끝나는 도메인을 수신하면 일반적인 well-known URL 대신 http://localhost:3456/{domain}/nod.json에서 가져옵니다. 이를 통해 데모가 독립적으로 실행됩니다. DNS나 HTTPS 설정 없이도 Claude를 demo-restaurant.localhost로 지정하여 실제 결과를 얻을 수 있습니다.

환경 변수:

  • NOD_LOCAL_PORT — 데모 매니페스트 서버가 수신 대기하는 포트(기본값 3456)

  • NOD_LOCAL_MANIFEST_SERVER — MCP 서버가 .localhost 조회에 사용하는 기본 URL(기본값 http://localhost:3456)

  • NOD_FORCE_LOCAL=1 — 모든 도메인을 로컬 매니페스트 서버를 통해 라우팅(새 예제 매니페스트를 테스트하는 기여자에게 유용)

다음 단계

opennod.ai/protocol의 NOD 프로토콜 사양을 사용하여 귀하의 비즈니스를 위한 nod.json을 게시하세요. 최소한의 유효한 매니페스트를 작성하는 데는 약 30분이 소요되며, https://yourdomain.com/.well-known/nod.json에 게시되면 이 MCP 서버(또는 다른 NOD 인식 클라이언트)를 사용하는 모든 에이전트가 귀하의 비즈니스를 발견하고 그 기능에 따라 행동할 수 있게 됩니다.

라이선스

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

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 disclosure. It explains what the tool does and returns, but does not mention side effects, prerequisites (e.g., domain validity), or that it is read-only.

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 covering purpose, input, and output. Very concise with no wasted words, though slightly dense; could be broken into two sentences for readability, but still effective.

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?

No output schema, but description adequately covers return fields (supported status, endpoint, auth, policies). Input is fully described. Missing error handling and sibling differentiation, but sufficient for the tool's simplicity.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. The description adds value by listing common actions, providing concrete examples that aid selection beyond the schema's generic string type.

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 checks if an action is supported for a given domain, listing output details. It differentiates from the sibling 'lookup_nod' by focusing on a specific action check.

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 'lookup_nod' or when not to use it. The description only implies usage through examples, lacking explicit context.

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

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 must carry full behavioral transparency. It discloses the fetch action and return summary but does not address potential failure modes (e.g., domain not found, malformed manifest), rate limits, or authentication requirements. The description is adequate but incomplete for a safe agent invocation.

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 that efficiently conveys the main purpose and key details (URL pattern, return contents). It is front-loaded and includes relevant information without excess words. However, it is somewhat dense and could be split into two sentences for improved readability.

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 low complexity (single parameter, no output schema), the description provides sufficient context: it specifies the source URL, the domain format, and the contents of the returned summary. It does not cover error handling or exact output structure, but for a simple lookup tool it is reasonably 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 for the single 'domain' parameter. The description adds context about the URL pattern but reiterates the format constraint already present in the schema. Since schema coverage is high, the baseline of 3 is appropriate; the description does not significantly add meaning 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 it fetches a NOD Protocol manifest from a well-known URL and returns a structured summary including business identity, capabilities, actions, endpoints, and contact methods. It uses a specific verb-resource combination and distinguishes itself from the sibling tool 'check_capability' by focusing on the full manifest.

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 explains what the tool does but provides no guidance on when to use it versus the sibling 'check_capability', nor does it mention prerequisites or exclusions. The usage context is implied (looking up a domain's manifest) but lacks explicit alternative differentiation.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv0.1.0
    • First observedcheck_capability
    • First observedlookup_nod
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored across 2 tools

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
ResponsivenessNo issues

Resources

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
    8 npm
    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 npm
    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