NyxID
NyxID is an open-source Agent Connectivity Gateway that lets AI agents securely call any API (public, private, or localhost) without ever handling raw credentials, with full audit logging, human-in-the-loop approval, and automatic MCP tool wrapping.
Proxy HTTP requests (
nyx_proxy_request): Forward GET, POST, PUT, PATCH, or DELETE requests to any connected downstream service (cloud APIs like OpenAI, GitHub, Slack; internal REST endpoints; or localhost services via NAT-pierced credential nodes). NyxID automatically injects credentials at proxy time, rate-limits calls, and audit-logs every request.Discover available services (
nyx_list_services): Enumerate all services the agent is authorized to call, including slug, display name, base URL, auth method, and rate limits — optionally with parsed OpenAPI endpoint lists for tool discovery.Request human approval (
nyx_request_approval): Block execution and notify a human (via Telegram or mobile push) before performing sensitive, destructive, or financial actions — with configurable timeouts and pre-configured grant rules for unattended automation.Exchange identity tokens (
nyx_exchange_identity): Perform RFC 8693 OAuth token exchange to obtain a delegated OIDC access token, allowing the agent to act on behalf of a specific user without holding their long-lived credentials, while keeping actions fully auditable.Automatic MCP tool wrapping: REST APIs with OpenAPI specs are automatically transformed into discoverable MCP tools, simplifying integration with agents like Claude Code and Cursor.
Per-agent isolation & NAT traversal: Each agent operates with a scoped token for fine-grained access control, and localhost services can be reached from cloud-hosted agents without VPNs or port forwarding via SSH tunneling over WebSocket.
Provides credential injection capabilities for APIs, allowing AI agents to access services without exposing raw keys, similar to 1Password Universal Autofill but with broader API support.
Provides NAT traversal capabilities similar to Cloudflare Tunnel but with additional credential injection features for reaching localhost services and internal APIs.
Used as the deployment platform for self-hosting the NyxID server stack, enabling containerized deployment of the gateway with backend, frontend, and MongoDB services.
Example service that can be accessed by AI agents through the NyxID gateway with per-agent isolation, allowing secure API access without exposing credentials.
Provides OIDC/OAuth 2.0 identity layer with RBAC, service accounts, and authentication capabilities similar to Keycloak but integrated with API credential injection.
Used as the database backend for the NyxID server stack, storing configuration, credentials, and user data in a containerized MongoDB instance.
Supported as an AI agent client that can connect to any API through the NyxID gateway with automatic credential injection and MCP tool wrapping capabilities.
Example LLM provider that can be integrated as a service, allowing AI agents to access OpenAI APIs through credential injection without exposing API keys.
Provides OIDC/OAuth 2.0 authentication with PKCE for secure agent authentication and authorization to access various API services through the gateway.
Example service that can be accessed by AI agents through the NyxID gateway with per-agent isolation, allowing secure API access without exposing credentials.
Integrated for transaction approval workflows, providing mobile push notifications for approving API access requests from AI agents.
Connect AI agents to any API, anywhere. Securely. Open-source Agent Connectivity Gateway.
NyxID lets your AI agents (Claude Code, Cursor, n8n) reach any API you have, public or private, and handles all the credentials so your agent never sees a raw key.
flowchart LR
subgraph Agents["AI Agents"]
CC[Claude Code]
CU[Cursor]
N8[n8n]
end
subgraph NyxID["NyxID Gateway"]
AUTH[OIDC and API Key Auth]
PROXY[Credential Injection Proxy]
MCP[MCP Tool Wrapping]
end
subgraph Connectivity["Private Reach"]
NODE[Credential Node]
end
subgraph Targets["Connected Services"]
PUB[Public APIs]
INT[Internal APIs]
LOC[Localhost Services]
end
CC --> AUTH
CU --> AUTH
N8 --> AUTH
AUTH --> PROXY
PROXY --> MCP
PROXY -->|Direct proxy| PUB
PROXY -->|Private network| INT
PROXY -->|NAT traversal| NODE
NODE --> LOC
classDef agents fill:#eef2ff,stroke:#4f46e5,color:#111827,stroke-width:1.5px;
classDef gateway fill:#111827,stroke:#22d3ee,color:#ffffff,stroke-width:2px;
classDef tooling fill:#e0f2fe,stroke:#0284c7,color:#0f172a,stroke-width:1.5px;
classDef node fill:#fef3c7,stroke:#f59e0b,color:#111827,stroke-width:1.5px;
classDef targets fill:#ecfeff,stroke:#14b8a6,color:#0f172a,stroke-width:1.5px;
class CC,CU,N8 agents;
class AUTH,PROXY gateway;
class MCP tooling;
class NODE node;
class PUB,INT,LOC targets;NyxID proxies requests, injects credentials automatically, punches through NAT (Network Address Translation) to reach your local services, and wraps any REST API as MCP (Model Context Protocol) tools.
What NyxID Does
Reach anything — public APIs, internal APIs, localhost services via credential nodes (
nyxid node). SSH (Secure Shell) tunneling (nyxid ssh) reaches remote hosts. No VPN (Virtual Private Network), no port forwarding.Never expose keys — the reverse proxy injects credentials automatically. Your agent talks to NyxID; NyxID talks to the API with the real key.
MCP auto-wrap — REST APIs with OpenAPI specs become MCP (Model Context Protocol) tools.
nyxid mcp config --tool cursorgenerates the config. Works with Claude Code, Cursor, VS Code, and any MCP client.Per-agent isolation — each agent gets a scoped token. Agent A accesses Slack and Gmail. Agent B only accesses your internal API. Revoke any session without touching the underlying credentials.
Full identity layer — OIDC (OpenID Connect) / OAuth 2.0 with PKCE (Proof Key for Code Exchange), RBAC (Role-Based Access Control), service accounts, transaction approval (Telegram + mobile push), LLM (Large Language Model) gateway for 7 providers.
Related MCP server: mcpgate
See It in Action
The end-to-end loop is short: connect a service to NyxID once, then any AI agent pointed at your NyxID MCP endpoint can use it — without ever seeing the raw API key.
Add a service in the web console — paste your OpenAI (or Anthropic, GitHub, etc.) key once; NyxID stores it encrypted.
Wire up your AI tool —
claude mcp add --transport http --scope user nyxid http://localhost:3001/mcp(or one-click install for Cursor inSettings→MCP).Use it — Claude Code, Cursor, or any MCP client can now call the service through NyxID. The agent sees the response; never the key.
Why NyxID
Other tools solve parts of this — NyxID combines credential injection, NAT traversal, and MCP tooling in one open-source gateway:
NyxID | 1Password Universal Autofill | Cloudflare Tunnel | Keycloak | |
Open source | Yes | No | No | Yes |
NAT traversal to localhost | Yes ( | No | Yes (no credentials) | No |
Credential injection | Yes (any API) | Partner integrations | No | No |
REST to MCP auto-wrap | Yes | No | No | No |
Per-agent isolation | Yes | No | No | No |
OIDC / OAuth 2.0 | Yes | No | No | Yes |
Use Cases
Give Claude Code access to your private APIs without sharing keys
Expose internal microservices to AI agents through a single MCP endpoint
Secure AI agent access to self-hosted tools (Grafana, Jenkins, n8n) behind your firewall
Getting Started
NyxID is used in two phases — install the nyxid CLI client, then pick a workflow. The CLI logs into either the hosted service or a self-hosted backend and can create the Agent Key your workflow needs.
1. Install NyxID
The default "install NyxID" path installs the lightweight nyxid CLI. It is user-scoped, needs no Docker, and does not start a backend server.
Just need the client? Install the CLI. Running your own backend? Self-host with Docker.
bash -c "$(curl -fsSL https://raw.githubusercontent.com/ChronoAIProject/NyxID/main/skills/nyxid/scripts/install.sh)"After the CLI is installed, choose where it should log in:
Hosted | Self-host | |
What it is | We run the NyxID backend for you in the cloud | You run the NyxID backend on your own machine |
Best for | Getting started quickly, no server setup | Full control, private networks, offline use |
Status | Early access (invite code below) | Open — anyone can run it |
Driving NyxID from an AI coding agent? Hand it this single line at any point — it tells the agent to install the
nyxidCLI plus the Nyx skill files:Install nyx skills from https://github.com/ChronoAIProject/NyxID/blob/main/skills/INSTALL.mdThe agent reads
skills/INSTALL.mdend-to-end. It should use the CLI installer by default and only run the Docker backend setup if you explicitly ask to self-host.
Prefer a plugin install? If your agent has a plugin marketplace, add the NyxID skill that way instead of copying files — it stays in sync with the repo on update. The skill still calls the
nyxidCLI (installed above), so keep that step.Claude Code
/plugin marketplace add ChronoAIProject/NyxID /plugin install nyxid@nyxidCodex / Cursor — point the runtime at
https://github.com/ChronoAIProject/NyxID; it reads.codex-plugin/plugin.json/.cursor-plugin/plugin.jsonand loads the bundled skills fromskills/.
Hosted (Recommended)
Start using NyxID in under a minute — no Docker, no setup.
Open nyx.chrono-ai.fun/register in a new tab (Cmd/Ctrl-click, or right-click → Open Link in New Tab) so you can keep this checklist open.
Enter invite code:
NYX-FGNY85AFSign in with Google, GitHub, or Apple
Open
AI Services, add and connect your first external service, and run the API Usage verification curlAfter the service is verified, wire your AI tool to NyxID's MCP endpoint
The full click-through flow is in Add your first AI Service. Early access is limited to 20 users.
Self-Host
Run your own NyxID backend on your machine. This is the optional server-side path and sets up three Docker containers (database, backend, frontend) — takes about 2 minutes.
Prerequisites: Docker and a bash shell. macOS and Linux already have one — Windows users, see docs/WINDOWS_SETUP.md before going further. Docker is required only for this backend path. Full prereqs and disk budgets are in SETUP.md.
AI-Assisted (Recommended)
If you have Claude Code, Cursor, or any AI coding assistant open, paste the prompt below into it only when you explicitly want a self-hosted backend. It will drive the entire self-host flow for you — preflight, clone, env generation, Docker stack, health check, CLI login, first credential, and MCP config.
I want to self-host the NyxID backend on this machine (the repo is https://github.com/ChronoAIProject/NyxID). This is the Docker server path, not the default CLI install. Walk me through the full setup interactively. If anything fails or I'd prefer to follow the manual steps myself, the full step-by-step with troubleshooting is at https://github.com/ChronoAIProject/NyxID/blob/main/docs/SETUP.md. If I'm on Windows, confirm I'm running from a WSL Ubuntu shell (not native PowerShell or CMD) before proceeding — see https://github.com/ChronoAIProject/NyxID/blob/main/docs/WINDOWS_SETUP.md.
Confirm Docker is installed and running before touching anything (check
git,docker,openssl,curl,docker composev2, anddocker info).Before cloning or generating anything, check whether NyxID install STATE is present — look for a
./NyxID/.env.devfile OR any Docker volume matchingnyx*_mongodb_data(rundocker volume ls --format '{{.Name}}' | grep -E 'nyx.*_mongodb_data$'— this catches the defaultnyxid_mongodb_dataplus any variant from a renamed checkout). A bare./NyxIDdirectory alone does NOT count as "installed" —uninstall.shleaves the source tree in place, so the directory can exist with no state. If install state is present, stop and tell me the quickstart is a first-time-only install. Ask whether I want to (a) uninstall first — if./NyxIDexists, runcd NyxID && ./scripts/uninstall.sh --yes && cd ..; if only the stale Docker volume is orphaned (checkout was manually deleted earlier), rundocker volume ls --format '{{.Name}}' | grep -E 'nyx.*_mongodb_data$' | xargs -r docker volume rmdirectly. Either path wipes the volume, containers, and (for the script path).env.dev/keys — destroys all NyxID accounts and encrypted credentials. Or (b) keep my existing install and stop here — I can verify it's still running withcurl -sf http://localhost:3001/health. Do not proceed to step 3 until I answer.If
./NyxIDalready exists (post-uninstall reinstall),cdinto it; otherwise clone the repo into the current directory andcdin. Generate.env.devwith a freshENCRYPTION_KEYandMONGO_ROOT_PASSWORD(setENVIRONMENT=development,INVITE_CODE_REQUIRED=false,AUTO_VERIFY_EMAIL=true, andEMAIL_AUTH_ENABLED=trueso I don't get stuck on email verification or a locked-down signup page), symlink it to.env.production, create the PKCS#1 JWT signing keys underkeys/(with a LibreSSL fallback using-puboutif-RSAPublicKey_outisn't supported), then pull images and start the stack withdocker compose -f docker-compose.yml -f docker-compose.prod.yml --env-file .env.production up -d. Wait up to 90 seconds forhttp://localhost:3001/healthto return 200 — if it times out, tell me to rundocker logs nyxid-backend. If the logs showSCRAM failure: Authentication failed, that means the MongoDB volume has a stale password from a previous install — tell me to run./scripts/uninstall.sh --yes(or, if the checkout is gone,docker volume ls --format '{{.Name}}' | grep -E 'nyx.*_mongodb_data$' | xargs -r docker volume rmto remove any nyx-flavored orphan volume) and retry. Show me the generatedENCRYPTION_KEYso I can back it up.Tell me to open http://localhost:3000 and register my account (no email verification needed — accounts are auto-verified in dev mode), and wait until I confirm I've done that.
Ensure the
nyxidCLI is available. If it is not installed, ask me whether I want to install thenyxidCLI plus the Nyx skill so you can drive NyxID from the terminal afterwards. Explain that the installer downloads a roughly 10 MB prebuilt binary plus a small set of skill files (no Rust toolchain required), installs the CLI into a versioned layout with rollback support, and that only unsupported OS/arch combinations fall back to a Rust source build. If I say yes, follow the install manifest at https://raw.githubusercontent.com/ChronoAIProject/NyxID/main/skills/INSTALL.md end-to-end (it installs the CLI under~/.local/share/nyxid/, drops the skill into your skill directory, and tells you toexport PATH="$HOME/.local/bin:$PATH"if needed). Then verify withnyxid doctor, log me in withnyxid login --base-url http://localhost:3001, add my OpenAI key withnyxid service add llm-openai --credential-env OPENAI_API_KEY, and verify withnyxid proxy request <slug> modelsusing the slug the previousservice addcommand printed underSlug:(typicallyllm-openai, but suffixed if I already had a service with that slug). If I do not want the CLI, walk me through adding the same OpenAI credential in the web console instead.Finish by connecting my AI tool to NyxID's MCP endpoint at
http://localhost:3001/mcp. For Claude Code:claude mcp add --transport http --scope user nyxid http://localhost:3001/mcp. For Codex:codex mcp add nyxid --url http://localhost:3001/mcp. For Cursor: openSettings>MCPin the web console and clickInstall to Cursor.
Manual Setup
Prefer to run the optional backend setup yourself, or need the full troubleshooting guide? Follow docs/SETUP.md (macOS, Linux, or Windows via WSL).
It covers:
System preflight check — Step 1
One paste-block install — Step 2
Register your account — Step 3
Uninstall & reinstall, orphan volume recovery, and SCRAM failure troubleshooting
Once NyxID is running and you've registered at http://localhost:3000, continue to 2. Pick a workflow.
For production deployment (TLS, custom domain, email verification), see docs/DEPLOYMENT.md.
2. Pick a workflow
With NyxID running and an Agent Key in hand, pick the workflow that matches what you want to build. Each is a step-by-step procedure that ends with a working integration; the four are independent and can be completed in any order.
Quickstart | Outcome | NyxID capability |
An n8n workflow pulls an RSS feed, summarizes each article with Gemini, and posts to Telegram — using one | Per-service credential injection | |
Two coding agents on one machine, each scoped to a distinct service and credential, attributed independently in the audit log. | Agent isolation, scoped Agent Keys | |
A private-host API is reachable from a cloud agent without VPN, port forwarding, or a tunneling service. | Credential Node, outbound-only NAT traversal | |
An OpenAPI spec is exposed as typed MCP tools to Claude Code / Cursor / VS Code / Codex with no MCP server code. | OpenAPI → MCP auto-wrap |
For a per-interface reference walkthrough that ends with
HTTP/1.1 200from your first proxied call (Web UI · CLI · AI-driven · Direct API), see the Connecting AI Services hub.
Connecting AI Services (interface reference)
Pick a workflow in Getting Started is organized by use case. For an interface-oriented reference that ends with a verified proxy call (HTTP/1.1 200) using your preferred entry point — Web UI, CLI, AI-driven (MCP), or Direct API — see docs/connecting-services/. The hub distinguishes external service credentials from NyxID Agent Keys and links to one walkthrough per interface.
Resources
Topic | Link | Description |
Quickstarts | End-to-end recipes — n8n, per-agent keys, node proxy, MCP wrapping | |
Connecting AI Services | Add your first (or Nth) AI Service — Web UI / CLI / AI-driven / Direct API | |
Setup | Optional self-hosted backend + troubleshooting (macOS, Linux, Windows via WSL) | |
Deployment | Start here for production setup | |
AI Agent Playbook | Start here for agent integration | |
Architecture | System design and data flows | |
API Reference | Full endpoint documentation | |
Credential Nodes | NAT traversal setup | |
MCP Integration | MCP protocol details | |
SSH Tunneling | Remote host access over WebSocket | |
Security | Threat model and hardening | |
Environment Variables | Full config reference | |
Telemetry | Opt-in usage analytics — hot-swap contract, event taxonomy, consent + GDPR erasure | |
Developer Guide | Local development setup |
Contributing
We welcome contributions. See CONTRIBUTING.md.
License
Available Tools
4 toolsnyx_exchange_identityA
Exchange the agent's NyxID identity for a delegated access token bound to a downstream OIDC service (RFC 8693 token exchange). Lets the agent call APIs on behalf of a specific user without holding that user's long-lived credentials. The returned token carries the original user's identity claims while remaining auditable as an agent action.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | Space-separated OAuth scopes to request on the exchanged token. Must be a subset of what the subject_user has approved for this agent. | |
| audience | Yes | Target downstream service identifier (resource URI or audience claim) the exchanged token should be valid for. | |
| ttl_secs | No | Requested token lifetime in seconds. Bounded by the audience's configured maximum (typically 900-3600 seconds). | |
| subject_user | Yes | User ID or email of the principal whose identity the agent is acting on behalf of. Must already exist in NyxID and have granted the agent delegation rights. |
TDQS
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 performs token exchange, does not hold user credentials, and that the token carries user identity claims while remaining auditable. It doesn't cover rate limits or auth details, but is transparent about the core behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences only, with key information front-loaded. No wasted words, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the purpose, mechanics, and security implications, but could mention prerequisites like existing delegation rights. Nonetheless, it is reasonably complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The description adds context beyond the schema, explaining the overall delegation and auditing aspects, which enhances understanding of how parameters like subject_user and audience are used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: exchanging the agent's NyxID identity for a delegated access token bound to a downstream OIDC service, citing RFC 8693. It uses a specific verb ('exchange') and resource, and distinguishes from sibling tools like nyx_list_services and nyx_proxy_request.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the use case: letting the agent call APIs on behalf of a user without holding long-lived credentials. It provides clear context but does not explicitly mention when not to use or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nyx_list_servicesA
Enumerate the downstream services this agent can call through NyxID. Returns each service's slug, display name, base URL, auth method, configured rate limits, and (when an OpenAPI spec is available) its callable endpoints. Use this for tool discovery before issuing nyx_proxy_request — agent-key scope determines which services are visible.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Optional filter by service category. Omit to list all categories. | |
| include_endpoints | No | When true, include the parsed OpenAPI endpoint list per service. Adds latency on services with large specs. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry burden. It mentions that include_endpoints adds latency and that agent-key scope affects visibility. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: purpose then usage and return fields. No wasted words, well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description lists all return fields (slug, display name, etc.) and mentions endpoint inclusion condition. Covers parameter effects and usage context completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 100% means schema already describes parameters. Description adds latency note for include_endpoints but otherwise no additional semantics beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it enumerates downstream services with specific fields returned (slug, display name, etc.). Differentiates from siblings by mentioning tool discovery before nyx_proxy_request.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this for tool discovery before issuing nyx_proxy_request' and notes agent-key scope determines visibility. Does not explicitly state when not to use, but context makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nyx_proxy_requestA
Forward an HTTP request through NyxID to any downstream service the agent has been granted access to. NyxID injects the appropriate credential at proxy time so the agent never holds raw API keys. Supports cloud APIs (OpenAI, GitHub, Slack, Lark, Telegram, etc.), internal REST endpoints, and localhost services reached over a NAT-pierced credential node. Every call is rate-limited and audit-logged per agent identity.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | Request body for POST/PUT/PATCH. Object values are JSON-encoded; string values are sent verbatim. Omit for GET/DELETE. | |
| path | Yes | Path on the downstream service, beginning with '/'. NyxID prepends the service's base URL automatically. | |
| method | Yes | HTTP method for the downstream request. | |
| headers | No | Additional headers to forward. Authorization / API-key headers are injected by NyxID and MUST NOT be set here. | |
| service_slug | Yes | Slug of the connected service (e.g. "llm-openai", "api-github"). Use nyx_list_services to enumerate the slugs visible to this agent. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses credential injection, rate limiting, audit logging, and supported service types. It does not detail the response format or error handling, but covers key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no waste. Purpose is front-loaded, followed by capability examples and constraints. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should mention the response format (e.g., returns the downstream response). It also omits details like timeout limits or size constraints. Adequate for a proxy tool but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing baseline 3. The description adds meaning: body encoding rules, header restrictions, path base URL prepending, and service slug enumeration via another tool. This exceeds the schema's descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool forwards HTTP requests through NyxID to downstream services with credential injection. It lists supported service types (cloud APIs, internal endpoints, localhost) and distinguishes itself from sibling tools like nyx_list_services by referencing them for service enumeration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (accessing downstream services) and includes explicit guidance to not set Authorization headers. It also references nyx_list_services for available service slugs. However, it does not explicitly contrast with nyx_exchange_identity or nyx_request_approval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nyx_request_approvalA
Request human approval before performing a sensitive action. NyxID delivers the request to the user via push notification (Telegram or mobile app) and blocks the agent until the user approves, denies, or the request times out. Use this for destructive operations, financial transactions, or any action where unattended automation is inappropriate. Approvals can be granted ad-hoc per call or via pre-configured grant rules.
| Name | Required | Description | Default |
|---|---|---|---|
| details | No | Optional longer description with the full context the user needs to decide. Keep under 1000 characters; rendered as plain text in the approval UI. | |
| service_slug | Yes | Slug of the service the agent will call after approval. Used to scope approval grants and audit logs. | |
| timeout_secs | No | How long to wait for a human decision before failing. Bounded by the user's configured maximum. | |
| action_summary | Yes | One-line summary of what the agent intends to do, written for a human reader (e.g. "Send $500 wire to vendor X", "Delete production database backup older than 30 days"). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses key behaviors: it blocks the agent, delivers via push notification, and times out. However, it does not describe the return value or how the agent receives the decision (e.g., approved/denied), which is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four efficient sentences front-load the purpose and mechanism, then provide usage guidance and options. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage, behavior, and parameter constraints. However, it omits any mention of the tool's output or return value, which is needed since no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents parameters well. The description adds some context (e.g., timeout bounded by user max), but does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Request human approval before performing a sensitive action,' specifying the verb and resource. It differentiates from sibling tools like nyx_exchange_identity and nyx_proxy_request by focusing on human-in-the-loop approval for sensitive actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'for destructive operations, financial transactions, or any action where unattended automation is inappropriate.' Also indicates alternative approval methods via pre-configured grant rules, helping the agent decide contextually.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
Each tool addresses a distinct function: token exchange, service discovery, proxied requests, and human approval. No two tools could be confused for the same purpose.
All tools follow the nyx_verb_noun pattern consistently (exchange_identity, list_services, proxy_request, request_approval). No mixing of styles.
Four tools is well-scoped for an identity-and-proxy server; each tool fills a necessary role without redundancy or excessive granularity.
The set covers the core lifecycle: identity exchange, service discovery, proxy calling, and human approvals. Minor gaps like token revocation or listing active approvals exist but are workable.
Maintenance
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
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
Self-hosted MCP gateway: turn any API, database or MCP server into AI connectors — no code.
Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows
Real-time chat hub for AI agents — Claude Code, Cursor, Cline, Codex over MCP or REST.
Related MCP Servers
- AlicenseAqualityFmaintenanceA Model Context Protocol (MCP) server for authenticated REST APIs. Drop it into any project, point it at your API, and let AI agents call endpoints — with auto-login, 2FA support, Swagger spec fetch, and fuzzy endpoint search — all without writing a single line of auth code.3126MIT

mcpgateofficial
FlicenseNot gradedqualityAmaintenanceSelf-hosted MCP gateway that connects Claude, ChatGPT, and other AI agents to 20+ enterprise tools (GitLab, Jira, Notion, Google Workspace, Slack, Grafana, …) with OAuth, audit logs, and zero data leaving your infrastructure- AlicenseAqualityAmaintenanceOne local gateway for all your MCP servers — shared by every AI coding tool (Claude, Cursor, VS Code, Codex). Set up each server once; keys stay in the OS keychain; lazy discovery keeps agent context small. Local-first, open source.431198MIT
- AlicenseCqualityCmaintenanceTurn any REST API into an MCP server in one command. Point mcpify at an OpenAPI spec and every endpoint becomes a tool your AI agent (Claude, Cursor, Windsurf) can call — zero glue code, always in sync with the spec.35MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/ChronoAIProject/nyxid'
If you have feedback or need assistance with the MCP directory API, please join our Discord server