Skip to main content
Glama

Export Project

export_project

Export a user-side distribution package containing only runtime and diagnostic capabilities. Specify project and output directories to generate a ready-to-run package from your captured web API project.

Instructions

导出用户态分发包:仅运行与诊断能力,不含任何 registry 写入/再生成代码。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
output_dirYes
project_dirYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.2/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and it does provide a meaningful constraint: the tool only performs runtime and diagnostic export, with no registry writes or code regeneration. This clarifies the side-effect profile better than a generic 'export' phrase, though it does not describe what files are produced or how output is written.

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 a single front-loaded sentence with no filler; the action and the key exclusion are both stated efficiently. It is terse, but the brevity is more under-specification than wasted words.

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?

The tool is simple and has an output schema, but the description omits parameter semantics and any clear when-to-use guidance. Given the lack of annotations, the description is not sufficient for an agent to confidently call the tool with correct inputs in the right situation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage and the description does not explain project_dir or output_dir at all. An agent must infer the meaning of both required parameters from their names, so the description adds no parameter-level value.

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 states a specific action and resource: '导出用户态分发包' (export user-mode distribution package). It also distinguishes itself from siblings such as regenerate_server by disclaiming registry writes and regeneration. Some vagueness remains about what exactly constitutes the package, but the core purpose is clear.

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 implies a diagnostic/runtime scope and explicitly rules out registry-write and code-regeneration tasks, which gives some indirect usage signal. However, it never names an alternative tool or states a clear condition for when to select export_project over siblings.

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