OpenAPI Client Generator MCP
openapi-client-generator MCP 서버
TypeScript를 사용하여 API 클라이언트를 생성하는 모델 컨텍스트 프로토콜 서버입니다.
특징
자원
API와 상호작용하는 데 사용할 수 있는 Axios 기반 API 클라이언트를 생성합니다.
클라이언트를 생성하기 위해 OpenAPI / Swagger 사양을 사용합니다.
프롬프트
generate_client- 지정된 OpenAPI 사양에 대한 API 클라이언트를 생성합니다.
Related MCP server: Emcee
개발
종속성 설치:
지엑스피1
서버를 빌드하세요:
npm run build자동 재빌드를 사용한 개발의 경우:
npm run watch설치
Claude Desktop과 함께 사용하려면 서버 구성을 추가하세요.
MacOS의 경우: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows의 경우: %APPDATA%/Claude/claude_desktop_config.json
{
"mcpServers": {
"openapi-client-generator": {
"command": "node",
"args": [
"< PATH TO >/openapi-client-generator/build/index.js"
]
}
}
}디버깅
MCP 서버는 stdio를 통해 통신하므로 디버깅이 어려울 수 있습니다. 패키지 스크립트로 제공되는 MCP Inspector를 사용하는 것이 좋습니다.
npm run inspector검사기는 브라우저에서 디버깅 도구에 액세스할 수 있는 URL을 제공합니다.
기여하다
이슈를 개설하거나 풀 리퀘스트를 제출하여 프로젝트에 기여해 주세요. 프로젝트 목표에 부합하는 개선 사항이나 새로운 기능은 언제든지 환영합니다.
특허
이 프로젝트는 MIT 라이선스에 따라 라이선스가 부여되었습니다. 자세한 내용은 라이선스 파일을 참조하세요.
클라인 과 함께 구축
Available Tools
1 toolgenerate_clientB
Generate TypeScript API client from OpenAPI specification
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | URL or file path to OpenAPI specification | |
| output | Yes | Output directory for generated client | |
| httpClient | Yes | HTTP client to use (fetch or axios) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral traits. It does not disclose side effects (e.g., file creation, overwriting), dependencies (valid spec), permissions, or error conditions. This is a significant gap for a generation tool.
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?
The description is a single, precise sentence with no wasted words. It is appropriately sized for a straightforward generation tool with three well-defined parameters.
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 and no annotations, the description is incomplete. It lacks details on what the generated client includes, whether existing files are overwritten, and any runtime behaviors. More context is needed for an AI agent to use it correctly.
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 parameter descriptions, satisfying the baseline. The tool description does not add any additional parameter semantics beyond what the schema already provides.
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 action ('Generate'), the output ('TypeScript API client'), and the source ('from OpenAPI specification'). It is specific and distinguishes the tool from any potential siblings (none defined).
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?
No explicit guidance on when or when not to use the tool. While there are no sibling tools, the description lacks context such as prerequisites (valid OpenAPI spec) or best practices for selecting the HTTP client.
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 tool update
v1.0.0- First observed
generate_client
TDQS
Scored across 1 tool
With only one tool, there is no possibility of confusion. The tool has a clear and singular purpose.
The single tool uses a clear verb_noun pattern ('generate_client'), which is consistent and descriptive.
A single tool feels thin for an OpenAPI client generator. While it may suffice for a minimal use case, most users would expect additional capabilities like validation or endpoint listing.
The tool only generates a client from a specification. Obvious gaps include validating the spec, listing endpoints, or configuring output options, which limits its usefulness.
Related MCP Connectors
MCP server for AI access to Swagger by SmartBear.
MCP server for generating rough-draft project plans from natural-language prompts.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceAn MCP server that exposes HTTP methods defined in an OpenAPI specification as tools, enabling interaction with APIs via the Model Context Protocol.8MIT
- AlicenseNot gradedqualityDmaintenanceGenerate an MCP server for any OpenAPI documented endpoint.332MIT
- FlicenseNot gradedqualityDmaintenanceAn auto-generated MCP server that enables interaction with the OpenAI API, allowing users to access OpenAI's models and capabilities through the Multi-Agent Conversation Protocol.-
- AlicenseNot gradedqualityDmaintenanceA service that converts OpenAPI specifications into MCP tools, enabling AI assistants to interact with your API endpoints through natural language.MIT