How do I use ironxyz?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ironxyz list all API endpoints" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

ironxyz

by ironxyz

Overview Schema Related Servers Score Discussions

TypeScript

Remote

@ironxyz/mcp-server

Official MCP (Model Context Protocol) server for Iron.xyz API, designed to work with Claude Desktop, Cursor IDE and other MCP compatible clients.

Features

This MCP server provides three main tools for exploring and interacting with the Iron.xyz API:

list-all-endpoints - Lists all API endpoints from the Iron.xyz OpenAPI specification in a concise format suitable for LLM consumption
get-api-specs - Gets detailed OpenAPI specification for a specific endpoint
invoke-api-endpoint - Actually calls the Iron.xyz API endpoints with proper authentication and validation

Related MCP server: MCP Server Example

Quick Start

No installation required! Use with npx in your host:

Configuration

Add this to your MCP Host (Claude Desktop / Cursor IDE etc) configuration:

{
  "mcpServers": {
    "ironxyz": {
      "command": "npx",
      "args": ["-y", "@ironxyz/mcp-server"],
      "env": {
        "IRON_ENVIRONMENT": "production"
      }
    }
  }
}

Configuration Options

Configure the server using environment variables:

Variable	Description	Default	Options
`IRON_ENVIRONMENT`	Iron.xyz environment to use	`production`	`production`, `sandbox`
`IRON_API_KEY`	Iron.xyz API key for authentication	None	Your API key from Iron.xyz dashboard
`IRON_READ_ONLY_MODE`	Restrict to GET requests only	`false`	`true`, `false`
`IRON_BASE_URL`	Custom base URL for API calls	Auto-detected based on environment	Any valid URL
`IRON_OPENAPI_SPEC_URL`	Custom OpenAPI spec URL	Auto-detected based on environment	Any valid URL
`IRON_LOCAL_SPEC_PATH`	Local fallback spec file path	`./ironxyz-openapi-spec.yaml`	Any valid file path

Environment Examples

Production Environment (default):

{
  "env": {
    "IRON_ENVIRONMENT": "production"
  }
}

Sandbox Environment:

{
  "env": {
    "IRON_ENVIRONMENT": "sandbox"
  }
}

With API Key (for endpoint invocation):

{
  "env": {
    "IRON_ENVIRONMENT": "production",
    "IRON_API_KEY": "your-iron-api-key-here"
  }
}

Read-only mode (GET requests only):

{
  "env": {
    "IRON_ENVIRONMENT": "production",
    "IRON_API_KEY": "your-iron-api-key-here",
    "IRON_READ_ONLY_MODE": "true"
  }
}

Custom OpenAPI Spec URL:

{
  "env": {
    "IRON_ENVIRONMENT": "production",
    "IRON_OPENAPI_SPEC_URL": "https://your-custom-spec-url.com/spec"
  }
}

Development

Local Installation

Install dependencies:
```
pnpm install
```
Build the project:
```
pnpm run build
```

Running Locally

pnpm start

Or for development:

pnpm run dev

Tools Available

`list-all-endpoints`

Lists all API endpoints from the Iron.xyz OpenAPI specification.

Parameters:

filterByTag (string, optional): Filter endpoints by tag

Example usage:

{
  "tool": "list-all-endpoints",
  "arguments": {
    "filterByTag": "users"
  }
}

`get-api-specs`

Gets detailed OpenAPI specification for a specific endpoint.

Parameters:

path (string, required): The API path (e.g., '/v1/users')
method (string, required): The HTTP method (GET, POST, PUT, DELETE, etc.)

Example usage:

{
  "tool": "get-api-specs",
  "arguments": {
    "path": "/v1/users",
    "method": "GET"
  }
}

`invoke-api-endpoint`

Actually calls the Iron.xyz API endpoints with proper authentication and validation.

Parameters:

path (string, required): The API path (e.g., '/customers') - /api prefix is added automatically
method (string, required): The HTTP method (GET, POST, PUT, DELETE, etc.)
parameters (object, optional): Query parameters as key-value pairs
headers (object, optional): Additional headers as key-value pairs
body (object, optional): Request body for POST/PUT/PATCH requests

Features:

✅ Authentication: Automatically adds API key if configured
✅ Read-only mode: Optional restriction to GET requests only
✅ Validation: Validates endpoints against OpenAPI specification
✅ Error handling: Comprehensive error responses with details
✅ Environment awareness: Works with both sandbox and production

Example usage:

{
  "tool": "invoke-api-endpoint",
  "arguments": {
    "path": "/customers",
    "method": "GET",
    "parameters": {
      "limit": 10,
      "offset": 0
    }
  }
}

Example with POST request:

{
  "tool": "invoke-api-endpoint",
  "arguments": {
    "path": "/customers",
    "method": "POST",
    "headers": {
      "IDEMPOTENCY-KEY": "123e4567-e89b-12d3-a456-426614174000"
    },
    "body": {
      "name": "John Doe",
      "email": "john@example.com",
      "type": "individual"
    }
  }
}

Error Handling

The server includes comprehensive error handling for:

Missing or invalid OpenAPI specification API
Invalid endpoint paths or methods
Network issues with external services
Malformed tool arguments

Available Tools

3 tools

get-api-specsA

Read-only

Get detailed specifications for a specific API endpoint including parameters, request/response schemas, and examples. Should be used to get a deeper understanding of an API endpoint you will use for code generation or for real API invoking. In case you intend to use the invoke-api-endpoint MCP tool, ALWAYS use this before, so you understand the full context of an API.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	The API endpoint path — use the template form from list-all-endpoints (e.g., '/customers', '/identifications/{id}') or a resolved path (e.g., '/identifications/abc123')
`method`	Yes	HTTP method

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, so the description's burden is lower. It adds context that the tool returns parameters, schemas, and examples, which is helpful beyond the annotation.

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 sentences, front-loaded with purpose, then usage guidance. No redundant information.

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?

Tool is a read-only spec retrieval. Annotations cover safety, schema covers parameters, description covers purpose and usage. No output schema but description states what is returned. Complete for its role.

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 100% with detailed descriptions for both parameters. The description does not add additional meaning beyond what the schema provides, so baseline of 3 is appropriate.

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 clearly states 'Get detailed specifications for a specific API endpoint including parameters, request/response schemas, and examples.' The verb 'get' and resource 'specifications' are precise. It distinguishes from sibling 'list-all-endpoints' by focusing on a single endpoint, and from 'invoke-api-endpoint' by being informational.

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

Usage Guidelines5/5

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

Explicitly states 'Should be used to get a deeper understanding...' and 'ALWAYS use this before' invoking the API endpoint tool. This provides clear when-to-use guidance and differentiates from siblings.

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

invoke-api-endpointA

Make an actual API call to the Iron API. Use this ONLY after getting complete endpoint specifications with the get-api-specs MCP tool. This tool requires proper authentication and can be in read-only mode if configured.

ParametersJSON Schema

Name	Required	Description
`path`	Yes	The API endpoint path — either a template (e.g., '/identifications/{id}') with path params in parameters, or an already-resolved path (e.g., '/identifications/abc123')
`method`	Yes	HTTP method
`parameters`	No	Path and query parameters as key-value pairs. Path parameters (e.g., {id}) are substituted into the path template; remaining parameters are appended as query string
`body`	No	Request body for POST/PUT/PATCH requests
`headers`	No	Additional headers as key-value pairs

TDQS

A4.4/5.0

Behavior3/5

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

Description adds context beyond annotations (authentication required, read-only mode) but does not disclose potential side effects or error handling, especially given openWorldHint annotation.

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 sentences, front-loaded with purpose, then usage constraints. 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?

Explains parameter behavior clearly but lacks return value description (no output schema) and does not mention error states or rate limits. Still reasonably complete for a tool with rich schema.

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%, and description adds valuable semantics for path parameter (template vs resolved), method (enum), and parameters (path vs query substitution).

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 clearly states 'Make an actual API call to the Iron API' with specific verb and resource. It distinguishes from siblings by requiring prior use of get-api-specs.

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

Usage Guidelines5/5

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

Explicitly states 'Use this ONLY after getting complete endpoint specifications with the get-api-specs MCP tool', providing clear when-to-use guidance and referencing sibling tool.

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

list-all-endpointsA

Read-only

Get a comprehensive overview of all available API endpoints organized by category/tag. Use this to explore the API structure and find endpoints related to your goal.

ParametersJSON Schema

Name	Required	Description	Default
`filterByTag`	No	Filter endpoints by tag (e.g., 'Customer', 'Autoramp')

TDQS

A4/5.0

Behavior3/5

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

The description adds that the overview is organized by category/tag, which is beyond the readOnlyHint annotation. However, it does not disclose details like rate limits, response format, or any limitations, which are not needed given the tool's simplicity.

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 very concise with two short sentences that front-load key information. No unnecessary words or 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?

Despite lacking an output schema, the description sufficiently conveys what the tool returns (a structured overview by tag). The tool is simple with one optional parameter, so the description is complete enough for effective use.

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 only parameter 'filterByTag' is fully described in the schema (100% coverage). The description does not add additional meaning beyond what the schema already provides, so baseline 3 applies.

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 provides a comprehensive overview of all API endpoints organized by tag. It distinguishes itself from siblings like 'get-api-specs' and 'invoke-api-endpoint' by focusing on exploration and categorization.

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 explicitly advises using this tool to explore the API structure and find endpoints related to a goal. While it does not articulate when not to use it or compare directly with siblings, the usage context is clear.

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.

3 tool updatesv0.2.0May 29, 2026
- First observedget-api-specs
- First observedinvoke-api-endpoint
- First observedlist-all-endpoints

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0

Disambiguation5/5

Each tool serves a unique purpose: list-all-endpoints for discovery, get-api-specs for detailed specs, and invoke-api-endpoint for actual API calls. No overlap in functionality.

Naming Consistency5/5

All tool names follow the verb_noun pattern with snake_case: 'list-all-endpoints', 'get-api-specs', 'invoke-api-endpoint'. Consistent and predictable.

Tool Count4/5

Three tools is minimal but covers the essential workflow of exploring and using an API. Falls just short of the ideal range (3-15) but is not too sparse for the purpose.

Completeness4/5

The set covers the core lifecycle: list all endpoints, get specs for one, then invoke. Minor gaps like search/filtering but no dead ends in the primary workflow.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
QuallaaOAuth
com.quallaa
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
AI & Machine Learning Communication
2
Apideck MCP A
dev.apideck.mcp
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Developer Tools
42
OpenRouter AFeaturedOAuth
ai.openrouter.mcp
The OpenRouter MCP server plugs OpenRouter into the AI tools you already use. Once connected, your assistant can pull live OpenRouter data (models, prices, your credits, rankings, and docs) and send quick test messages, all without leaving your editor.
AI & Machine Learning
221

Related MCP Servers

MCP OpenAI Server
Agent Orchestration Command Line
mzxrai
A
license
B
quality
C
maintenance
A Model Context Protocol (MCP) server that lets you seamlessly use OpenAI's models right from Claude.
Updated 2 years ago (2024-12-06 18:15 UTC)
1
281
76
MIT
MCP Server Example
Developer Tools Code Execution Autonomous Agents
alejandro-ao
A
license
B
quality
D
maintenance
An educational implementation of a Model Context Protocol server that demonstrates how to build a functional MCP server for integrating with various LLM clients like Claude Desktop.
Updated a year ago (2025-04-29 10:58 UTC)
1
163
MIT
discord-mcp
Autonomous Agents Agent Orchestration Communication
SaseQ
A
license
Not graded
quality
B
maintenance
A Model Context Protocol (MCP) server for the Discord integration with MCP-compatible applications like Claude Desktop.
Updated 4 months ago (2026-04-25 13:55 UTC)
469
MIT
1mcpserver
Autonomous Agents Developer Tools
particlefuture
A
license
Not graded
quality
D
maintenance
MCP of MCPs. Automatic discovery and configure MCP servers on your local machine. Integration with Claude and Cursor.
Updated 8 months ago (2025-12-31 12:01 UTC)
53
Apache 2.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/ironxyz/mcp-server'

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