Skip to main content
Glama
zijin-zj

WujieAI MCP Server

by zijin-zj
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

无界AI生图的MCP服务集成指南

一、服务核心功能

  1. AI图像生成：通过MCP协议，可调用无界AI数十种模型生成图像

  2. 模型信息列表：可查看无界AI数十种作画生图模型介绍

  3. 多分辨率支持：支持512~4094主流尺寸的任意宽高组合

  4. 参数自定义：可调节采样步数、采样器类型、提示词相关性等专业参数

二、快速接入流程

步骤1：获取API密钥

  1. 访问无界AI控制台

  2. 注册/登录后进入「开发者中心」

  3. 在「密钥管理」模块创建新密钥

  4. 记录生成的WUJIEAI_API_KEY

步骤2 ：环境准备

# 验证Node.js环境（要求v18.0.0或更高版本）
node -v

步骤3：Server服务配置

# 本地客户端（推荐）
{
  "mcpServers": {
    "mcp-server-wujieai": {
      "command": "npx",
      "args": ["-y", "wujieai-mcp-server"],
  	  "env": {
        "WUJIEAI_API_KEY": ${YOUR_API_KEY}
      }
    }
  }
}

# HTTP SSE长连接
{
  "mcpServers": {
    "wujie-ai-sse": {
      "url": "https://pref-gate.wujieai.com/open-platform-mcp/sse?key=${YOUR_API_KEY}"
    }
  }
}

三、开发调用示例

const result = await client.callTool({
  name: "generate_image",
  arguments: {
    prompt: "一只优雅地坐着的猫",
    model: "1013"
  }
});

四、最佳实践建议

  1. 提示词优化：

    • 使用权重标记符( )强化关键元素：(neon lights:1.3)

五、技术支持

注：具体API参数请以最新版文档为准。建议通过npm update @wujieai/wujieai-mcp-server保持SDK版本同步更新。

Available Tools

3 tools
generate_imageC

AI生成图片

ParametersJSON Schema
NameRequiredDescriptionDefault
cfgNo提示词相关性，取值范围[1-30]，默认值7。（可选）
numNo生成数量，默认1张
seedNo随机种子，生成图片的seed，默认-1随机生成。（可选）-1
modelNo模型code，默认通用FLUX模型
stepsNo采样步数，默认20。（可选）
widthNo图片宽，默认512。（可选）
heightNo图片高，默认512。（可选）
promptYes作画描述，建议包含风格和细节
uc_promptNo作画负面描述。（可选）
sampler_indexNo采样模式是指扩散去噪算法的采样模式。（可选）
init_image_urlNo底图url。（可选）

TDQS

C2.2/5.0
Behavior2/5

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 doesn't mention mutation effects, side effects, asynchronous behavior, or that the tool returns a task ID or requires querying later. Given that sibling tools include query_generate_task, the generation is likely async, but this isn't disclosed. The description only restates the function and discloses no behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely short, only six characters, which is efficient in length but not structured as useful guidance. It doesn't front-load any distinguishing information beyond the name, so it is under-specification rather than conciseness. A minimal viable description should at least say what the tool does that the name alone doesn't convey.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 11 parameters, no annotations, no output schema, and two siblings that suggest an async workflow, the description is too sparse. It doesn't mention that the result might be a task, that users need to supply rich prompts, or how this relates to query_generate_task. The schema covers parameters well, but the overall operational context is missing. An agent could call it, but may not know what to expect back or what to do next.

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 description coverage is 100%, so the schema itself documents prompt, cfg, seed, steps, etc. The description adds no parameter-level nuance beyond the schema. Baseline 3 is appropriate when the schema is fully documented; the description doesn't need to repeat parameter definitions. However, it doesn't add any cross-parameter guidance (e.g., how cfg relates to prompt adherence) - though that is optional.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'AI生成图片' is a tautology that essentially restates the tool name 'generate_image' (generate an image). It identifies the resource (image generation) but doesn't provide specific detail about what kind of image generation model or output to expect, and the sibling tools are query_generate_task and query_model_infos, so some differentiation is needed to distinguish between initiation vs. querying. It's minimally recognizable to an agent but adds little beyond the name.

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?

The description provides no guidance on when to use this tool versus query_generate_task or query_model_infos. Siblings are clearly task-query and model-info functions, implying this tool initiates generation, but the description never states that. For an 11-parameter tool, an agent is left to infer that it should call this one first based on the schema rather than being told.

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

query_generate_taskB

查询作画任务结果

ParametersJSON Schema
NameRequiredDescriptionDefault
keyYes发起作画返回的任务key

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description must carry the behavioral disclosure burden. It only says 'query results' and does not mention whether tasks can be in progress, whether the tool polls, what the response contains, or whether this is read-only in any meaningful sense.

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 one short sentence with no filler and is front-loaded. It is concise, though a little additional context could be added without hurting clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description should at minimum clarify what kind of result is returned, whether the call blocks or returns a status, and how it connects to generate_image. Saying only '任务结果' leaves these essential details unspecified.

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 schema already fully documents the single key parameter as '发起作画返回的任务key'. The description adds no additional meaning about key format, where to get it, or how to use it, so it sits at the baseline for full schema coverage.

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 states a specific operation: '查询作画任务结果' (query the result of an image-generation task). The verb+resource combination clearly distinguishes it from siblings generate_image and query_model_infos.

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 text explains when to call this tool versus generate_image or query_model_infos. The agent must infer from sibling names that this is the follow-up after image generation; there are no explicit alternatives, conditions, or exclusions.

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

query_model_infosB

查询作画模型信息列表

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations provided, the description carries the full behavioral burden. It indicates a read-only query operation, which is useful, but it does not mention return format, pagination, caching, authentication, or any side effects. This is adequate for a simple list query but not deeply transparent.

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 one short, front-loaded sentence with no filler. Every word contributes to understanding the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter query tool, the description is minimally sufficient for invocation. However, with no output schema and no annotations, it does not describe what fields or format the model info list contains, nor how this tool relates to the sibling tools.

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?

The tool has zero parameters, so there is nothing for the input schema to document. The description adds meaning by clarifying that the result is a list of model information, which is sufficient given the zero-parameter baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the operation ('query') and the resource ('drawing model info list'), making it easy to understand what the tool does. However, it does not differentiate from sibling tools such as query_generate_task or generate_image, so it stops short of a 5.

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?

There is no guidance about when to use this tool instead of query_generate_task or generate_image, and no prerequisites or exclusions are mentioned. The only implied usage is 'when you need model info,' which does not help an agent decide among the sibling tools.

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. 3 tool updatesv0.1.4
    • First observedgenerate_image
    • First observedquery_generate_task
    • First observedquery_model_infos
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

B3.3/5.0

Scored across 3 tools

Disambiguation5/5

Each tool targets a distinct aspect: generating an image, querying task results, and listing model info. There is no overlap or ambiguity between them.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern (generate_image, query_generate_task, query_model_infos). The naming is predictable and uniform.

Tool Count5/5

With exactly 3 tools, the server provides a tightly scoped set that covers the essential lifecycle of image generation without unnecessary bloat. The count feels appropriate for the purpose.

Completeness4/5

The server covers generation, result querying, and model listing, which handles the core workflow. Missing features like task cancellation or listing all tasks are minor and not critical for basic usage.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers