Skip to main content
Glama

manus_project_create

Create a project with an optional default instruction that applies to every task created within that project.

Instructions

Create a new project with an optional default instruction that will be applied to every task created with this project_id.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
instructionNo

Implementation Reference

  • Handler function for the manus_project_create tool. Sends a POST request to /v2/project.create with the input schema body and returns a ProjectCreateResponse.
    async def project_create(req: ProjectCreateRequest, ctx: ToolCtx) -> ProjectCreateResponse:
        return await ctx.client.call(
            "POST",
            "/v2/project.create",
            json_body=req,
            response_model=ProjectCreateResponse,
            rate_limit_key="project.create",
        )
  • Input schema for project creation: requires a name and optionally an instruction.
    class ProjectCreateRequest(ManusModel):
        name: str
        instruction: str | None = None
  • Output schema wrapping a ProjectRecord in the standard response envelope.
    class ProjectCreateResponse(ResponseEnvelope):
        project: ProjectRecord
  • Registration of the tool via the @manus_tool decorator. This stores the ToolDef in the global _REGISTRY dict with name, description, and schemas.
    @manus_tool(
        name="manus_project_create",
        description=(
            "Create a new project with an optional default instruction that will be applied to "
            "every task created with this project_id."
        ),
        input_schema=ProjectCreateRequest,
        output_schema=ProjectCreateResponse,
    )
  • The @manus_tool decorator and ToolDef data class that power tool registration. The decorator stores the tool's metadata and handler into the _REGISTRY dictionary.
    class ToolDef(Generic[TIn, TOut]):
        """Metadata + handler for a single MCP tool."""
    
        name: str
        description: str
        input_schema: type[TIn]
        output_schema: type[TOut]
        handler: Callable[[TIn, ToolCtx], Awaitable[TOut]]
        rate_limit_key: str | None = None
    
    
    _REGISTRY: dict[str, ToolDef[Any, Any]] = {}
    
    
    def manus_tool(
        *,
        name: str,
        description: str,
        input_schema: type[TIn],
        output_schema: type[TOut],
        rate_limit_key: str | None = None,
    ) -> Callable[
        [Callable[[TIn, ToolCtx], Awaitable[TOut]]], Callable[[TIn, ToolCtx], Awaitable[TOut]]
    ]:
        """Decorator registering `handler` as a tool with the given metadata."""
    
        def wrap(
            handler: Callable[[TIn, ToolCtx], Awaitable[TOut]],
        ) -> Callable[[TIn, ToolCtx], Awaitable[TOut]]:
            if name in _REGISTRY:
                raise RuntimeError(f"Duplicate tool name: {name}")
            _REGISTRY[name] = ToolDef(
                name=name,
                description=description,
                input_schema=input_schema,
                output_schema=output_schema,
                handler=handler,
                rate_limit_key=rate_limit_key,
            )
            return handler
    
        return wrap
    
    
    def all_tools() -> list[ToolDef[Any, Any]]:
        """Return a stable-ordered copy of every registered tool."""
        return sorted(_REGISTRY.values(), key=lambda t: t.name)
    
    
    def clear_registry() -> None:
        """Test helper."""
        _REGISTRY.clear()
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 full burden. It discloses that the instruction applies to future tasks but omits important behavioral details like permissions, side effects (e.g., project deletion), rate limits, or naming constraints.

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?

A single sentence without extraneous words. Could be slightly improved by front-loading the core action more clearly, but overall it is concise and to the point.

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, the description should explain return values or confirmations. It does not mention what happens on success (e.g., returns project object), error handling, or idempotency, leaving gaps for a creation tool.

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 coverage is 0%, so the description should compensate. It explains the 'instruction' parameter's optional role but does not add format or constraints for 'name' parameters. Baseline of 3 is appropriate given partial compensation.

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 clearly states the verb 'create', the resource 'project', and mentions an optional feature (default instruction applied to tasks). It distinguishes from sibling tools like 'manus_project_list' or 'manus_task_create'.

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 alternatives, such as existing project selection or prerequisites. It lacks explicit context for deciding to create versus listing or updating projects.

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/aruxojuyu665/Manus-MCP'

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