Skip to main content
Glama

apipost_smart_create

Generate API documentation from field lists for headers, query, body, cookies, and responses using structured data with real examples and clear descriptions.

Instructions

API接口文档生成器(字段列表驱动)。规则:responses 只传 fields,不传 data;headers/query/body/cookies 统一用字段列表,嵌套用 .,数组用 [];example 填真实值(不要 JSON 字符串);所有字段含父级都必须写 desc,父级需显式声明。例如:{"key":"data","desc":"返回体","type":"object"},{"key":"data.user","desc":"用户","type":"object"},{"key":"data.user.id","desc":"用户ID","type":"integer","example":1}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
methodYesHTTP方法
urlYes接口URL路径
nameYes接口名称
parent_idNo父目录ID,使用"0"表示根目录,默认为"0"
descriptionNo接口详细描述(可选)
headersNoHeaders字段列表字符串,格式:[{"key":"X-Request-ID","type":"string","required":false,"example":"req-1","desc":"说明"}]
queryNoQuery字段列表字符串,格式同上。嵌套用 .,数组用 [](如 meta.flags.debug 或 items[].id)。
bodyNoBody字段列表字符串,仅用字段列表生成 raw/参数描述,example 用真实值,不要放 JSON 字符串。
cookiesNoCookies字段列表字符串,格式同上。
authNo认证配置JSON字符串(可选)。格式:{"type":"bearer","bearer":{"key":"your_token"}}
responsesNo响应字段列表字符串(必填 fields),格式:[{"name":"成功","status":200,"fields":[{"key":"code","type":"integer","example":0,"desc":"状态码"},{"key":"data.items[].id","type":"string","example":"1"}]}]

Implementation Reference

  • src/index.ts:882-903 (registration)
    Tool registration in the ListToolsRequestSchema handler, including name, description, and inputSchema.
    {
        name: 'apipost_smart_create',
        description: 'API接口文档生成器(字段列表驱动)。规则:responses 只传 fields,不传 data;headers/query/body/cookies 统一用字段列表,嵌套用 .,数组用 [];example 填真实值(不要 JSON 字符串);所有字段含父级都必须写 desc,父级需显式声明。例如:{"key":"data","desc":"返回体","type":"object"},{"key":"data.user","desc":"用户","type":"object"},{"key":"data.user.id","desc":"用户ID","type":"integer","example":1}',
        inputSchema: {
            type: 'object',
            properties: {
                method: { type: 'string', enum: ['GET', 'POST', 'PUT', 'DELETE'], description: 'HTTP方法' },
                url: { type: 'string', description: '接口URL路径' },
                name: { type: 'string', description: '接口名称' },
                parent_id: { type: 'string', description: '父目录ID,使用"0"表示根目录,默认为"0"' },
                description: { type: 'string', description: '接口详细描述(可选)' },
                headers: { type: 'string', description: 'Headers字段列表字符串,格式:[{"key":"X-Request-ID","type":"string","required":false,"example":"req-1","desc":"说明"}]' },
                query: { type: 'string', description: 'Query字段列表字符串,格式同上。嵌套用 .,数组用 [](如 meta.flags.debug 或 items[].id)。' },
                body: { type: 'string', description: 'Body字段列表字符串,仅用字段列表生成 raw/参数描述,example 用真实值,不要放 JSON 字符串。' },
                cookies: { type: 'string', description: 'Cookies字段列表字符串,格式同上。' },
                auth: { type: 'string', description: '认证配置JSON字符串(可选)。格式:{"type":"bearer","bearer":{"key":"your_token"}}' },
                responses: { type: 'string', description: '响应字段列表字符串(必填 fields),格式:[{"name":"成功","status":200,"fields":[{"key":"code","type":"integer","example":0,"desc":"状态码"},{"key":"data.items[].id","type":"string","example":"1"}]}]' }
            },
            required: ['method', 'url', 'name'],
            additionalProperties: false
        }
    },
  • The main execution logic for the apipost_smart_create tool: validates permissions, builds config from input args, generates API template, and creates the API via ApiPost endpoint.
    case 'apipost_smart_create':
        if (!checkSecurityPermission('write')) {
            throw new Error(`🔒 安全模式 "${APIPOST_SECURITY_MODE}" 不允许创建操作。需要 "limited" 或 "full" 模式。`);
        }
        // 构建配置对象
        const { config } = buildApiConfig(args);
        const template = generateApiTemplate(args.method, args.url, args.name, config);
        template.project_id = currentWorkspace.projectId;
        // 设置父目录ID
        template.parent_id = args.parent_id || '0';
        const headerCount = config.headers?.length || 0;
        const queryCount = config.query?.length || 0;
        const bodyCount = config.body?.length || 0;
        const responseCount = config.responses?.length || 0;
        const createResult = await apiClient.post('/open/apis/create', template);
        if (createResult.data.code !== 0) {
            throw new Error(`创建失败: ${createResult.data.msg}`);
        }
    
        return {
            content: [{
                    type: 'text',
                    text: `API创建成功!\n名称: ${args.name}\n方法: ${args.method}\nURL: ${args.url}\nID: ${createResult.data.data.target_id}\n\n字段统计:\n• Headers: ${headerCount}个\n• Query参数: ${queryCount}个\n• Body参数: ${bodyCount}个\n• 响应示例: ${responseCount}个`
                }]
        };
  • Helper function to parse and validate input arguments into API config object, tracking which fields were provided.
    function buildApiConfig(args) {
        const config = {};
        const providedFields = new Set();
        if (args.description !== undefined) {
            config.description = args.description;
            providedFields.add('description');
        }
        if (args.headers !== undefined) {
            config.headers = parseConfigParam(args.headers);
            ensureFieldsHaveDesc(config.headers, 'headers');
            providedFields.add('headers');
        }
        if (args.query !== undefined) {
            config.query = parseConfigParam(args.query);
            ensureFieldsHaveDesc(config.query, 'query');
            providedFields.add('query');
        }
        if (args.body !== undefined) {
            config.body = parseConfigParam(args.body);
            ensureFieldsHaveDesc(config.body, 'body');
            providedFields.add('body');
        }
        if (args.cookies !== undefined) {
            config.cookies = parseConfigParam(args.cookies);
            ensureFieldsHaveDesc(config.cookies, 'cookies');
            providedFields.add('cookies');
        }
        if (args.auth !== undefined) {
            config.auth = parseApiConfig(args.auth);
            providedFields.add('auth');
        }
        if (args.responses !== undefined) {
            config.responses = parseConfigParam(args.responses);
            ensureResponsesFieldsHaveDesc(config.responses);
            providedFields.add('responses');
        }
        return { config, providedFields };
    }
  • Helper function that generates the full ApiPost API template object from method, url, name, and config.
    function generateApiTemplate(method, url, name, config = {}) {
        return {
            target_id: generateId(),
            target_type: 'api',
            parent_id: '0',
            name,
            method,
            url: applyUrlPrefix(url),
            protocol: 'http/1.1',
            description: config.description || `${name} - ${method} ${url}`,
            version: 3,
            mark_id: 1,
            is_force: -1,
            request: {
                auth: config.auth || { type: 'inherit' },
                pre_tasks: config.pre_tasks || [],
                post_tasks: config.post_tasks || [],
                header: {
                    parameter: convertParams(config.headers || [])
                },
                query: {
                    query_add_equal: 1,
                    parameter: convertParams(config.query || [])
                },
                body: buildBodySection(config.body || []),
                cookie: {
                    cookie_encode: 1,
                    parameter: convertParams(config.cookies || [])
                },
                restful: {
                    parameter: convertParams(config.restful || [])
                }
            },
            response: normalizeResponses(config.responses, { useDefaultWhenMissing: true, keepEmpty: true, isCheckResult: 1 }),
            attribute_info: config.attribute_info || {},
            tags: config.tags || []
        };
    }
  • Input schema definition for the apipost_smart_create tool, specifying parameters and validation rules.
    inputSchema: {
        type: 'object',
        properties: {
            method: { type: 'string', enum: ['GET', 'POST', 'PUT', 'DELETE'], description: 'HTTP方法' },
            url: { type: 'string', description: '接口URL路径' },
            name: { type: 'string', description: '接口名称' },
            parent_id: { type: 'string', description: '父目录ID,使用"0"表示根目录,默认为"0"' },
            description: { type: 'string', description: '接口详细描述(可选)' },
            headers: { type: 'string', description: 'Headers字段列表字符串,格式:[{"key":"X-Request-ID","type":"string","required":false,"example":"req-1","desc":"说明"}]' },
            query: { type: 'string', description: 'Query字段列表字符串,格式同上。嵌套用 .,数组用 [](如 meta.flags.debug 或 items[].id)。' },
            body: { type: 'string', description: 'Body字段列表字符串,仅用字段列表生成 raw/参数描述,example 用真实值,不要放 JSON 字符串。' },
            cookies: { type: 'string', description: 'Cookies字段列表字符串,格式同上。' },
            auth: { type: 'string', description: '认证配置JSON字符串(可选)。格式:{"type":"bearer","bearer":{"key":"your_token"}}' },
            responses: { type: 'string', description: '响应字段列表字符串(必填 fields),格式:[{"name":"成功","status":200,"fields":[{"key":"code","type":"integer","example":0,"desc":"状态码"},{"key":"data.items[].id","type":"string","example":"1"}]}]' }
        },
        required: ['method', 'url', 'name'],
        additionalProperties: false
    }
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the tool's input formatting rules and constraints (e.g., 'example 填真实值' - fill example with real values), which adds useful context beyond the schema. However, it doesn't disclose critical behavioral traits such as whether this creates new documentation (implied by '生成器' - generator), what permissions are required, whether it's idempotent, what happens on errors, or what the output looks like (no output schema). For a creation tool with 11 parameters, this leaves significant gaps.

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

Conciseness3/5

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

The description is appropriately sized but not optimally structured. It front-loads the purpose ('API接口文档生成器') but then dives into detailed formatting rules without clear separation. The example at the end is helpful but makes the text somewhat dense. While every sentence contributes information, the flow could be improved for better readability, such as by grouping rules separately from examples.

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?

Given the complexity (11 parameters, no annotations, no output schema), the description is incomplete. It covers formatting rules and provides an example, but lacks crucial context: what the tool actually produces (API documentation object?), how to handle errors, authentication requirements, or rate limits. For a tool that likely creates resources in a system, this omission is significant, especially without annotations to fill these gaps.

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 description coverage is 100%, so the schema already documents all 11 parameters thoroughly with descriptions and examples. The description adds some semantic context by explaining the overall field-list-driven approach and providing formatting examples (e.g., nested用 .,数组用 [] - nested use ., arrays use []). However, it doesn't add significant meaning beyond what's already in the parameter descriptions, maintaining the baseline score for high schema coverage.

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 tool's purpose as an 'API接口文档生成器(字段列表驱动)' (API documentation generator driven by field lists), which is a specific verb+resource combination. It distinguishes from siblings like apipost_create_folder (creates folders) or apipost_test_connection (tests connections) by focusing on API documentation generation. However, it doesn't explicitly contrast with apipost_update (which might update documentation) or apipost_detail (which might retrieve documentation details).

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

Usage Guidelines3/5

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

The description provides implied usage guidelines through rules like 'responses 只传 fields,不传 data' (responses only pass fields, not data) and formatting conventions for headers/query/body/cookies. It suggests when to use this specific format-driven approach. However, it lacks explicit guidance on when to choose this tool over alternatives like apipost_update for modifications or apipost_detail for retrieval, and doesn't mention prerequisites or exclusions.

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

Install Server

Other Tools

Latest Blog Posts

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/jlcodes99/apipost-mcp'

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