The Swiftcode MCP Server automates code generation to accelerate modern web development workflows.
Generate TypeScript API clients: Automatically creates TypeScript clients and type definitions from Swagger/OpenAPI specifications (supports JSON and YAML formats, Swagger 2.0 and OpenAPI 3.0+)
Generate Vue Components: One-click generation of Vue 3 list page components with tables, filters, and pagination using pre-defined templates
Template Management: Download and manage built-in code generation templates for Vue SFCs
Specification Validation: Validate Swagger/OpenAPI specifications
Mock Data Generation: Generate mock data to aid frontend development
Multiple Output Formats: Produces TypeScript interfaces, Vue components, and Element Plus elements
Automatically generates TypeScript API clients from Swagger/OpenAPI specifications with support for validation, type definitions, and interface generation.
Provides tools for generating TypeScript API clients and type definitions from Swagger/OpenAPI specifications, with support for type interfaces.
Generates Vue 3 list page components with filters, tables, and pagination based on configurable specifications, including support for Element Plus UI components.
Supports parsing and processing of YAML-formatted Swagger/OpenAPI specifications for API client generation.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Swiftcode MCP Server generate a TypeScript API client from our swagger.json file"
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.
English | 简体中文
Swiftcode MCP Server is a server based on the Model Context Protocol (MCP), focusing on automated code generation to support modern web development workflows. It can automatically generate TypeScript API clients from Swagger/OpenAPI specifications and quickly generate Vue list page components based on templates, greatly improving frontend and backend development efficiency.
Related MCP server: OpenAPI Client Generator MCP
Swagger/OpenAPI to TypeScript: Automatically generate TypeScript API clients and type definitions.
Vue Component Generation: One-click generation of Vue 3 list pages with tables, filters, and pagination.
Template Management: Obtain and use built-in code generation templates.
Specification Validation: Supports Swagger/OpenAPI validation.
Mock Data Generation: Optionally generate mock data for frontend development.
Frontend: Vue 3 (Composition API), Element Plus, TypeScript
API Specification: Swagger 2.0, OpenAPI 3.0+ (JSON/YAML)
Code Generation: TypeScript interfaces/types, Vue 3 components, Element Plus forms and tables
generate_api_clientGenerate TypeScript API client from Swagger/OpenAPI specification.
Parameters:
source (string): Swagger/OpenAPI file path or URL
dir (string): Output directory
Example:
{
"source": "/mock/swagger.json",
"dir": "./"
}generate_sfc_template_clientDownload and generate SFC/Vue list template files to the specified directory.
Parameters:
dir (string): Output directory
Example:
{
"dir": "./"
}generate_sfc_clientGenerate Vue list components based on template files.
Parameters:
source (string): Template file path
dir (string): Output directory
Example:
{
"source": "template.js",
"dir": "./"
}Start as an MCP Server:
{
"mcpServers": {
"swiftcode-npm": {
"command": "npx",
"args": ["-y", "@swiftcode/mcp"]
}
}
}pnpm install
# Build MCP
pnpm build
# Start MCP inspector
pnpm inspectorStart as an MCP Server:
{
"mcpServers": {
// Local development
"swiftcode-local": {
"command": "node",
"args": ["swiftcode-mcp-server/dist/index.js"]
}
}
}docker build -t swiftcode-mcp .
docker run -it swiftcode-mcp{
"source": "/user/swagger.json",
"dir": "./"
}{
"source": "template.js",
"dir": "./"
}Fork this repository
Create a feature branch
Commit your changes
Add tests if necessary
Submit a Pull Request
MIT
For more help or questions, please visit the GitHub.
Generate TypeScript API client from Swagger/OpenAPI specification
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | 使用本地文件路径或 swagger URL 生成 API 和类型文件 / URL or JSON file path. Examples: For full path: '//user/file.json', For file only: 'file.json' returns 'file json'. URLs should start with '/' for proper routing. | |
| dir | Yes | workspace dir |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool generates a TypeScript API client but doesn't explain what 'generate' entails (e.g., creates files, outputs code, requires write permissions), potential side effects (e.g., overwriting existing files), or any constraints (e.g., rate limits, authentication needs). This leaves significant gaps in understanding the tool's 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?
The description is a single, clear sentence: 'Generate TypeScript API client from Swagger/OpenAPI specification.' It is front-loaded with the core purpose, has zero wasted words, and efficiently communicates the essential information without unnecessary elaboration.
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 the complexity of generating code from specifications, the lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like what the tool outputs (e.g., files, code snippets), error handling, or dependencies. For a tool with 2 required parameters and no structured safety hints, more context is needed to ensure proper usage.
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?
The schema description coverage is 100%, so the input schema already documents both parameters ('source' and 'dir') with descriptions and examples. The tool description adds no additional parameter information beyond what's in the schema. According to the rules, when schema coverage is high (>80%), the baseline score is 3 even without param details in the description.
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: 'Generate TypeScript API client from Swagger/OpenAPI specification.' It specifies the verb ('generate'), resource ('TypeScript API client'), and source format ('Swagger/OpenAPI specification'). However, it doesn't explicitly differentiate from sibling tools like 'generate_sfc_client' or 'generate_sfc_template_client', which appear to be related but distinct generation tools.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools, prerequisites, or specific scenarios where this generation method is preferred. Without such context, users must infer usage based on the tool name alone, which is insufficient for effective tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
使用 sfc 模板生成 vue 列表组件 / Generate vue sfc component page.Examples: For file only returns vue sfc pages, default file name: 'template.js'
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | sfc 模板文件路径 / sfc template file path | |
| dir | Yes | workspace dir |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'For file only returns vue sfc pages' which suggests a file generation behavior, but doesn't disclose important traits like whether this overwrites existing files, what permissions are needed, error conditions, or what happens when generation fails. The description provides minimal behavioral context beyond the basic operation.
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 relatively concise but poorly structured. It mixes languages (Chinese and English) without clear separation, and the example about 'file only returns' feels tacked on rather than integrated. While not verbose, the structure could be improved for better readability and information hierarchy.
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?
For a code generation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the generated component looks like, what template features are supported, error handling, or success criteria. The example about 'default file name: template.js' adds some context but doesn't compensate for the missing behavioral and output information needed for effective tool use.
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 description coverage is 100%, so the schema already documents both parameters ('source' and 'dir') with clear descriptions. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain parameter relationships, constraints, or usage patterns. The baseline of 3 is appropriate when the schema does the heavy lifting.
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 states the tool '生成 vue sfc 组件页面 / Generate vue sfc component page' which indicates it creates Vue single-file components. However, it's vague about the specific resource being generated (just 'component page') and doesn't clearly distinguish from sibling tools like 'generate_sfc_template_client' which likely generates templates rather than components. The description provides basic purpose but lacks specificity about what makes this tool unique.
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 provides no guidance on when to use this tool versus alternatives. There's no mention of when this tool is appropriate versus 'generate_api_client' or 'generate_sfc_template_client', nor any prerequisites or context for usage. The example about file returns is operational rather than guidance about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
下载转换 sfc / vue 列表的模板文件当前目录下 / Download the transform sfc template files
| Name | Required | Description | Default |
|---|---|---|---|
| dir | Yes | workspace dir |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions downloading files to the current directory, which implies a write operation, but doesn't specify what happens if files already exist, whether this requires specific permissions, or what the expected outcome is. For a tool that presumably creates files, this is inadequate behavioral context.
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 brief but suffers from redundancy (providing both Chinese and English versions saying essentially the same thing). While not excessively wordy, it's not optimally structured - the bilingual approach adds length without adding clarity. The information could be more efficiently presented in a single language with clearer intent.
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?
For a tool with no annotations, no output schema, and sibling tools that suggest this is part of a code generation system, the description is insufficient. It doesn't explain what the templates contain, what 'transform sfc' means, or how this tool differs from generate_sfc_client. The user is left guessing about the tool's role in the broader context.
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?
The schema description coverage is 100%, with the single parameter 'dir' documented as 'workspace dir'. The description doesn't add any meaningful parameter semantics beyond what the schema already provides. It mentions '当前目录下' (current directory) which might imply something about the 'dir' parameter, but this is ambiguous rather than clarifying. The baseline of 3 is appropriate given complete schema coverage.
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 states '下载转换 sfc / vue 列表的模板文件当前目录下 / Download the transform sfc template files', which is tautological - it essentially restates the tool name 'generate_sfc_template_client' in different words. While it mentions downloading template files for SFC/Vue transformation, it doesn't specify what transformation occurs or what the templates are for, making the purpose vague rather than specific.
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 provides no guidance on when to use this tool versus its siblings (generate_api_client, generate_sfc_client). There's no mention of prerequisites, alternative tools, or specific scenarios where this tool is appropriate versus others. The user must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The tools have overlapping purposes focused on code generation from templates, with 'generate_sfc_client' and 'generate_sfc_template_client' both involving SFC/Vue components and potentially causing confusion. However, 'generate_api_client' is distinct for TypeScript API generation, and descriptions provide some differentiation.
All tool names follow a consistent 'generate_*_client' pattern with snake_case, making them predictable and readable. The naming convention is uniform across all three tools.
With only 3 tools, the server feels thin for a code generation domain, potentially lacking broader coverage. While each tool might be useful, the count is borderline low for the apparent scope.
Inferred domain is code generation from templates, but there are significant gaps: no tools for updating, deleting, or managing generated code, and coverage is limited to specific formats (Swagger/OpenAPI, Vue SFC). This could lead to agent failures in broader workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Generate a typed SDK, CLI, and MCP server from any OpenAPI or GraphQL spec, and keep them current.
A Model Context Protocol server for Wix AI tools
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
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
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/hongaah/swiftcode-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server