Skip to main content
Glama

dreamagent_create_project

WRITE ACTION — creates a new DreamAgent project (website, Telegram bot, Discord bot, or scheduler). Use ONLY when the user clearly asks to create/build a new project; not for questions about what to build.

CONFIRM BEFORE CALLING — never create on the first mention. In ONE message, present and get the user's explicit go-ahead for:

  1. The credential: run dreamagent_list_global_integrations first. If several telegram/discord credentials are saved, list them (id + title) and ask which to use. If exactly one is saved, state which one you will use. Never pick silently.

  2. The plan: name, type, and the final description exactly as you will submit it (this is the Prompt Assistant's recommendation summary). Call this tool only after the user confirms.

CREATION IS ASYNCHRONOUS: after calling, check dreamagent_get_project_status repeatedly until the project is 'ready' or 'failed' (bots ~2-5 min, websites longer).

CREDENTIALS: raw bot tokens are never accepted in chat or as inputs. For Telegram/Discord bots you MUST pass bot_token_integration_id — the ID of a saved credential from dreamagent_list_global_integrations. If none is saved, direct the user to dreamagent.cloud → Settings → Global Integrations. Other saved keys can be imported via global_integration_ids. Credentials are stored as project secrets and are never exposed back.

DESCRIPTION = the refined creation brief. Act as a Creative Director / Product Manager, not an architect.

Create a concise but complete description of WHAT should be built:

  • product vision and target audience

  • user experience and core functionality

  • design/tone direction

  • important features and behavior

  • final expected result

Do not include implementation details such as:

  • technology stack

  • architecture

  • database/API implementation

  • authentication implementation

  • deployment

  • CI/CD

  • testing commands

Infer reasonable defaults when missing details are non-critical. Ask for clarification only when missing information materially affects the requested functionality, scope, credentials, or expected result.

Prefer the following structure and constraints for each project type, but do not override explicit user requirements:

Website:

  • Project Vision

  • Design Style

  • Pages

  • Hero Experience

  • Core Features

  • UI Components

  • Mobile Experience

  • Final Expectation

  • Prefer up to 4 pages unless the user clearly requires more.

Telegram bot:

  • Bot Purpose

  • Commands

  • User Flow

  • Optional AI Features

  • Integrations when required

  • Final Expectations

  • Prefer a compact command set; always include /start and /help unless the user's explicit requirements conflict.

Discord bot:

  • Bot Purpose

  • Slash Commands

  • Events

  • Permissions

  • Optional AI Features

  • Final Expectations

  • Prefer a compact command set; include /help where appropriate.

Scheduler:

  • Job Purpose

  • Data Sources

  • Schedule

  • Delivery Channels

  • Message Format

  • Final Expectations

  • Use concrete schedules and specify failure/timeout behavior.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesproject name (max 30 chars; a public subdomain is auto-generated).
env_varsNooptional non-secret environment variables.
descriptionNothe build request (what + for whom + features/tone).
project_typeYeswebsite / telegrambot / discordbot / scheduler.
global_integration_idsNooptional saved-key IDs to import as env vars.
bot_token_integration_idNoREQUIRED for telegrambot & discordbot — saved-credential ID (see dreamagent_list_global_integrations).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

TDQS

A5/5.0
Behavior5/5

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

Annotations only indicate the tool is not read-only, but the description adds critical behavioral context: creation is asynchronous and requires status polling, credentials are stored as secrets and never exposed back, bot tokens must come from a saved integration ID, and the tool must not be called until explicit user confirmation. Nothing contradicts the annotations.

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 lengthy but highly structured with bold headers and front-loaded constraints. Every section—WRITE ACTION, CONFIRM BEFORE CALLING, ASYNCHRONOUS, CREDENTIALS, DESCRIPTION—earns its place by providing actionable guidance. The per-project-type templates are necessary for correctly constructing the description parameter. Excellent use of formatting for skimmability.

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

Completeness5/5

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

Given the tool's complexity (6 parameters, 4 project types, async behavior, credential requirements, and user confirmation), the description is exceptionally complete. It covers preconditions, post-call behavior, secret handling, parameter selection, and project-type-specific output structure, while referencing the relevant sibling tools. No notable gap remains.

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

Parameters5/5

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

Despite the input schema's 100% parameter description coverage, the description adds significant semantic value. It explains the 'description' parameter as a creative brief (not an architecture spec), mandates bot_token_integration_id for bot types, clarifies global_integration_ids for importing saved keys, and lists accepted project_type values. This far exceeds the schema's basic definitions.

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 opens with 'WRITE ACTION — creates a new DreamAgent project (website, Telegram bot, Discord bot, or scheduler)' and explicitly limits usage to 'when the user clearly asks to create/build a new project; not for questions about what to build.' This distinguishes it from sibling tools like dreamagent_get_project_status and dreamagent_list_projects.

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

Usage Guidelines5/5

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

Provides explicit when-to-use ('Use ONLY when the user clearly asks to create/build a new project') and when-not-to-use ('not for questions about what to build'). It also details a mandatory confirmation protocol, names prerequisite tools (dreamagent_list_global_integrations) and follow-up steps (poll dreamagent_get_project_status), making the usage context unambiguous.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0
Disambiguation5/5

Every tool has a clearly distinct purpose: create vs. list vs. status, session vs. edit vs. project, and cancel vs. release lock. The three status tools are explicitly differentiated by what they monitor (session, latest edit, deployment).

Naming Consistency5/5

All tools follow the `dreamagent_verb_noun` pattern, with verbs like create, list, get, cancel, release. Retrieval is consistently split: `get_*` for single statuses and `list_*` for collections.

Tool Count5/5

12 tools is well-scoped for a cloud AI project management platform. Each tool addresses a distinct operation, covering creation, monitoring, editing, sessions, and integrations without unnecessary redundancy.

Completeness4/5

Core workflows are covered: create/list/status for projects, sessions management, edit/cancel/progress, and credential listing. Minor gaps exist—no project deletion, no env var updates—but these are not critical for the primary AI edit and deployment flow.

Resources