Skip to main content
Glama
michaelneale

Goose App Maker MCP

by michaelneale

app_create

Create a new web application directory with starter files for development. Set up your app structure and customize content while keeping essential API utilities.

Instructions

Create a new web application directory and copy starter files.
The starter files are for you to replace with actual content, you don't have to use them as is.
the goose_api.js file is a utility you will want to keep in case you need to do api calls as part of your app via goose.

Args:
    app_name: Name of the application (will be used as directory name)
    description: Brief description of the application (default: "")

Returns:
    A dictionary containing the result of the operation

After this, consider how you want to change the app to meet the functionality, look at the examples in resources dir if you like.
Or, you can replace the content with existing html/css/js files you have (just make sure to leave the goose_api.js file in the app dir)

Use the app_error tool once it is opened and user has interacted (or has started) to check for errors you can correct the first time, this is important to know it works.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
app_nameYes
descriptionNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • main.py:197-266 (handler)
    The core handler function for the 'app_create' tool. It is decorated with @mcp.tool() which registers it as an MCP tool. Creates a new application directory, copies starter files from resources/kitchen-sink, generates a manifest.json, handles naming sanitization and errors.
    @mcp.tool()
    def app_create(app_name: str, description: str = "") -> Dict[str, Any]:
        """
        Create a new web application directory and copy starter files.
        The starter files are for you to replace with actual content, you don't have to use them as is.
        the goose_api.js file is a utility you will want to keep in case you need to do api calls as part of your app via goose.
        
        Args:
            app_name: Name of the application (will be used as directory name)
            description: Brief description of the application (default: "")
        
        Returns:
            A dictionary containing the result of the operation
    
        After this, consider how you want to change the app to meet the functionality, look at the examples in resources dir if you like.
        Or, you can replace the content with existing html/css/js files you have (just make sure to leave the goose_api.js file in the app dir)
    
        Use the app_error tool once it is opened and user has interacted (or has started) to check for errors you can correct the first time, this is important to know it works.
    
        """
        global http_server, server_port
    
        if http_server:
            return "There is already a server running. Please stop it before creating a new app, or consider if an existing app should be modified instead."
        try:
            # Sanitize app name (replace spaces with hyphens, remove special characters)
            safe_app_name = "".join(c if c.isalnum() else "-" for c in app_name).lower()
            
            # Create app directory
            app_path = os.path.join(APP_DIR, safe_app_name)
            if os.path.exists(app_path):
                return {
                    "success": False, 
                    "error": f"App '{safe_app_name}' already exists at {app_path}"
                }
            
            os.makedirs(app_path, exist_ok=True)
            
            
            # Copy kitchen-sink template files
            kitchen_sink_dir = os.path.join(RESOURCES_DIR, "kitchen-sink")
            copied_files = ["index.html", "style.css", "script.js", "goose_api.js"]
            
            for file_name in copied_files:
                src_file = os.path.join(kitchen_sink_dir, file_name)
                dest_file = os.path.join(app_path, file_name)
                shutil.copy2(src_file, dest_file)
            
            # Create manifest file
            manifest = {
                "name": app_name,
                "description": description,
                "created": time.strftime("%Y-%m-%d %H:%M:%S"),
                "files": copied_files
            }
            
            with open(os.path.join(app_path, "goose-app-manifest.json"), 'w') as f:
                json.dump(manifest, f, indent=2)
            
            return {
                "success": True,
                "app_name": safe_app_name,
                "app_path": app_path,
                "files": copied_files,
                "message": f"App '{app_name}' created successfully at {app_path}"
            }
        except Exception as e:
            logger.error(f"Error creating app: {e}")
            return {"success": False, "error": f"Failed to create app: {str(e)}"}
  • main.py:99-99 (registration)
    Mention of the 'app_create' tool in the system instructions provided to the MCP server, listing available tools for the AI model.
    app_create - use this when starting new
  • Function signature and docstring defining the input schema (parameters: app_name (str, required), description (str, optional)) and output type (Dict[str, Any]) for the app_create tool.
    def app_create(app_name: str, description: str = "") -> Dict[str, Any]:
        """
        Create a new web application directory and copy starter files.
        The starter files are for you to replace with actual content, you don't have to use them as is.
        the goose_api.js file is a utility you will want to keep in case you need to do api calls as part of your app via goose.
        
        Args:
            app_name: Name of the application (will be used as directory name)
            description: Brief description of the application (default: "")
Behavior2/5

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

With no annotations provided, the description carries full burden. It mentions creating directories and copying files, but doesn't disclose critical behavioral traits like whether this requires specific permissions, if it overwrites existing directories, what happens on failure, or rate limits. The description adds some context about starter files but misses key operational details.

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 verbose and poorly structured, mixing operational instructions with usage advice. Sentences like 'After this, consider how you want to change the app...' don't belong in a tool description. It's front-loaded but then diverges into tangential guidance, reducing clarity.

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?

Given 2 parameters with 0% schema coverage and an output schema exists, the description adds some parameter semantics but lacks completeness. It doesn't explain the return dictionary structure or error conditions, and with no annotations, it should provide more behavioral context for a creation tool.

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?

Schema description coverage is 0%, so the description must compensate. It explains app_name will be used as the directory name and description is a brief description with a default, adding meaningful semantics beyond the bare schema. However, it doesn't cover constraints like character limits or validation rules.

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 creates a new web application directory and copies starter files, specifying the verb (create) and resource (web application directory). It distinguishes from siblings like app_delete or app_list by focusing on creation, though it doesn't explicitly contrast with app_open or app_serve.

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 usage for creating new apps and mentions using app_error after creation, but doesn't explicitly state when to use this tool versus alternatives like app_open for existing apps or app_list for viewing. It provides some context but lacks clear when/when-not guidance.

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/michaelneale/goose-app-maker-mcp'

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