DreamAgent
Server Details
Build and deploy websites, Telegram and Discord bots from chat via the DreamAgent platform.
- Status
- Healthy
- Uptime
- 100.0% over 59 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- nivethaug/dreamagent-mcp-server
- GitHub Stars
- 0
- Server Listing
- DreamAgent MCP Server
TDQS
Scored across 20 tools
Most tools target distinct resource/action pairs and descriptions explicitly cross-reference related operations, but the three status-checking tools (project status, edit progress, chat status) overlap in purpose and could still be misselected. Chat, design mode, and build/publish also have some workflow overlap that an agent must navigate carefully.
All tools use the same dreamagent_ prefix and snake_case, with predictable verb_noun forms for most entries. Minor deviations like chat (verb-only), build_publish (verb_verb), and design_mode (not strictly verb_noun) keep it from perfect consistency.
At 20 tools, the set is on the heavy side for a single MCP server, even though most tools map to distinct operations. The count is borderline: it covers many workflows but feels broad and could overwhelm selection.
Core development workflows are well covered: project creation/status/build, file CRUD/diff, chat edit lifecycle, sessions, and credential lookup. Gaps exist in peripheral admin lifecycle operations such as project deletion, session deletion, and integration/environment management, but agents can route users to the DreamAgent UI for those.
Available Tools
24 toolsdreamagent_build_publishBuild and publish projectInspect
WRITE ACTION — build & publish a DreamAgent project: rebuilds the app from the current source files and pushes the new version live. Use after finishing file edits (dreamagent_write_file) so the user's changes go live. Pro/paid accounts only.
CONFIRM BEFORE CALLING — tell the user the project will be rebuilt and redeployed, and call only with confirm=true after they agree.
ASYNCHRONOUS: kick-off returns immediately; check dreamagent_get_project_status until the project reports 'ready'.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | ||
| project_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
dreamagent_cancel_chatCancel the running chatDestructiveInspect
DESTRUCTIVE — stops an AI edit that is currently running. Use ONLY when the user explicitly asks to stop/cancel the active edit. After cancellation, do NOT claim the requested change was completed — report that it was stopped.
Returns 'Cancellation requested: ' — e.g. 'Query cancelled', 'Cancellation requested' (durable run), or 'No active query found'. Afterwards poll dreamagent_get_chat_status / dreamagent_get_edit_progress until run_status reports 'cancelled'.
| Name | Required | Description | Default |
|---|---|---|---|
| session_key | Yes | the session key of the running edit. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
dreamagent_chatChat with the project agentInspect
WRITE ACTION — builds, modifies, or fixes an EXISTING project with a natural-language instruction. Use ONLY when the user clearly asks for a change ("add X", "fix Y", "change the theme"). If the user is only asking for advice, analysis, review, or suggestions ("what could be improved?", "review my bot"), do NOT call this — answer from the project's info instead; a review request is not an edit.
Describe ONLY the desired change — DreamAgent's AI automatically handles code, tests, rebuild, and redeployment. Completed changes are saved and committed automatically.
ASYNCHRONOUS: returns immediately with the session_key; monitor with dreamagent_get_edit_progress (or dreamagent_get_chat_status with the returned session key) until a terminal state. Report success only after run_status reaches 'completed'. Edits consume the user's AI credits.
ERRORS (actual returns): failures come back as text starting with 'ERROR:'. If the edit was rejected before starting, the text says 'the edit was NOT started' plus the reason — HTTP 402 insufficient credits, 409 another edit already active, 423 session lock held by another session, 404 wrong project id, 401 no account connected. Treat the edit as failed/cancelled only when a status tool says so.
ONE EDIT AT A TIME: never start another modification on the same project while one is running — check progress first and wait.
SUPERPOWERS: projects can use the account's enabled AI tools (song/video/image generation, voiceover, lip sync, voice clone, transcription, media processing, PDF tools). If the user asks to add or use one ("add song generation", "generate an image feature"), simply include that in the message — DreamAgent's agent knows the enabled tools and wires the integration, UI and job handling automatically. Check the catalog with dreamagent_list_superpowers; if a tool is disabled, direct the user to dreamagent.cloud -> Superpowers to enable it first.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | the desired change (what + any behavioral constraints). | |
| project_id | Yes | the project to modify. | |
| new_session | No | optional — start a fresh session for a new topic. | |
| session_key | No | optional — continue a specific development session. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
dreamagent_commit_pushCommit and push project changesAInspect
WRITE ACTION — commit ALL pending changes in a DreamAgent project and push them to its private GitHub repo. The commit gets its own entry in the project's session history and version history, so the user can restore/revert to it in the DreamAgent dashboard.
Use it to (a) commit several MCP writes/deletes as ONE version — write and delete with auto_commit=false first — or (b) retry a commit after a failure. Chat-driven edits commit automatically; this tool is for direct file changes made through MCP.
CONFIRM BEFORE CALLING — show the user what is pending (one dreamagent_get_file_diff per touched file) and call only with confirm=true after they agree.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | must be true to execute | |
| message | No | short commit message, e.g. "Add pricing page hero section" (default "MCP edit: project <id>") | |
| project_id | Yes | project to commit |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the generic write profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true). The description adds real behavioral context beyond that: the commit becomes a restorable/revertible entry in session and version history, direct MCP edits are the intended source, and execution is gated on confirm=true after user agreement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the WRITE ACTION classification and the core commit/push definition, then tight sections for usage cases and the confirmation gate. Slightly verbose with caps and parentheticals, but every sentence carries operational value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation. Given the mutation semantics and 100% schema coverage, the description supplies everything an agent needs: the write classification, the auto_commit grouping workflow, the retry case, and the mandatory confirmation gate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all three parameters, giving a baseline of 3. The description goes further by explaining the gating semantics of confirm ('call only with confirm=true after they agree') and the grouping intent behind auto_commit=false, which the schema alone does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific compound verb+resource (commit ALL pending changes and push to the private GitHub repo) and frames it as a WRITE ACTION. It is clearly distinguishable from siblings like dreamagent_write_file and dreamagent_edit_file, which mutate files rather than finalize a version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly enumerates when to use it: (a) grouping several MCP writes/deletes into one version via auto_commit=false, or (b) retrying a failed commit. It also states the exclusion — chat-driven edits commit automatically — so the agent knows when NOT to reach for this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dreamagent_create_projectCreate a new projectInspect
WRITE ACTION — creates a new DreamAgent project (website, Telegram bot, Discord bot, or AI agent). 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:
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.
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.
NOTE: this tool's schema includes a confirm parameter. If YOUR
client rejects a confirm field as "not allowed by the schema",
your cached tool list is STALE (the parameter exists server-side) —
tell the user to remove and re-add the DreamAgent connector, then
start a new chat.
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.
Agent (recurring/scheduled automation with OAuth actions):
Purpose (what it monitors or automates)
Data Sources (which connected OAuth services: YouTube, GitHub, Discord, Notion, X, Google Sheets, Slack — or public APIs)
Schedule (e.g., every 5 minutes / hourly / daily at 9am) and/or Event Triggers (incoming webhook)
Conditions (when to act — thresholds, keywords, state changes)
Delivery Channels (Telegram, Discord, Slack, email — optional)
Final Expectation
Use concrete schedules; note that agents keep persistent state between runs and can call any connected OAuth integration.
Agents do NOT need a bot token unless they deliver via Telegram/ Discord (then a saved credential is required as for bots).
SUPERPOWERS: the account may have ready-made AI tools enabled (song/video/image generation, voiceover, lip sync, voice clone, transcription, media processing, PDF tools). If the requested product clearly benefits from one (e.g. an AI song generator website), reflect the FEATURE in the description — DreamAgent wires the tool integration automatically at build time. Check what is enabled with dreamagent_list_superpowers. Do NOT add implementation details about how the tool is called.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | project name (max 30 chars; a public subdomain is auto-generated). | |
| confirm | No | must be true to execute — OR simply call the tool a SECOND time with the exact same arguments within 5 minutes (repeat-call confirmation). Either path confirms. | |
| env_vars | No | optional non-secret environment variables. | |
| description | No | the build request (what + for whom + features/tone). | |
| project_type | Yes | website / telegrambot / discordbot / agent. | |
| global_integration_ids | No | optional saved-key IDs to import as env vars. | |
| bot_token_integration_id | No | REQUIRED for telegrambot & discordbot — saved-credential ID (see dreamagent_list_global_integrations). |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
dreamagent_create_sessionCreate a chat sessionInspect
Create a new development session for a project — a separate conversation with its own context. Use when the user wants to start a distinct development topic. A new session does NOT replace or affect the existing project — earlier sessions remain available.
| Name | Required | Description | Default |
|---|---|---|---|
| label | No | optional name for the session. | ChatGPT |
| project_id | Yes | the project. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
dreamagent_delete_fileDelete a project fileInspect
WRITE ACTION — delete one source file from a DreamAgent project. Hidden/credential files (.env, .git, keys) are rejected. By default the deletion is immediately committed and pushed (so it is recorded in session history & version history) — deleted files stay recoverable via git history / version restore.
CONFIRM BEFORE CALLING — tell the user which file will be deleted and call only with confirm=true after they agree.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | ||
| file_path | Yes | ||
| project_id | Yes | ||
| auto_commit | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
dreamagent_design_modeRedesign UI from an imageInspect
WRITE ACTION — redesign a website project's UI to match a design image. Website projects only.
The user provides an image (screenshot, mockup, AI-generated design) and instructions. You generate the image (e.g. DALL-E), encode it as base64, and send it here. DreamAgent's AI will read the image and redesign the project's frontend to match.
CONFIRM BEFORE CALLING — show the user:
The project being redesigned
The design instructions Then call only with confirm=true after they agree.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | must be true to execute. | |
| project_id | Yes | the website project to redesign. | |
| image_base64 | Yes | base64-encoded design reference image (PNG/JPG/WEBP). Send the actual image bytes verbatim — the image IS the spec. | |
| instructions | Yes | keep this SHORT — e.g. "Match this design image exactly." The image carries the design; do NOT write a long textual design spec duplicating what is visible in the image. Only add brief must-have requirements the image cannot show (e.g. "keep all existing pages and functionality", "Product Hunt view only"). |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
dreamagent_edit_fileEdit a project file (find & replace)AInspect
WRITE ACTION — make SMALL targeted changes to an EXISTING file in a DreamAgent project via exact search/replace. PREFERRED over dreamagent_write_file for editing existing files: you send only the changed fragments (never the whole file) — cheaper, immune to payload size/safety blocks in the calling client, and cannot corrupt unchanged code. Use dreamagent_write_file only to CREATE files or for full rewrites.
Read the file first (dreamagent_read_file) and copy each 'find' text EXACTLY as it appears — whitespace and indentation must match. All edits are validated BEFORE anything is saved; if any 'find' fails to match, the file is left untouched and the error tells you which edit and why.
CONFIRM BEFORE CALLING — show the user the target file and each planned find→replace change, then call only with confirm=true.
| Name | Required | Description | Default |
|---|---|---|---|
| edits | Yes | list of edit objects: {"find": "<exact existing text>", "replace": "<new text>", "all": false} # optional: replace every occurrence | |
| confirm | No | must be true to execute. | |
| file_path | Yes | project-relative path of the EXISTING file to edit. | |
| project_id | Yes | project containing the file. | |
| auto_commit | No | commit+push and record version history after saving (default true; pass false to batch several edit_file calls and finish with one dreamagent_commit_push). |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: it discloses atomic all-or-nothing validation ('if any find fails to match, the file is left untouched'), the exact-match whitespace requirement, the confirm=true gate, and the auto_commit batching guidance. The destructiveHint=false annotation is consistent with the described non-corrupting, validated behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with a capitalized action label, then segmented into clear paragraphs for behavior, prerequisites, and confirmation. Despite its length, every sentence carries operational information (cost/safety rationale, validation semantics, confirm gate); no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write tool with an output schema present, the description covers what it need not (return format) and what it must: atomicity, exact-match requirements, confirmation, and the batching interaction with dreamagent_commit_push. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100%, so baseline is 3, but the description meaningfully augments the critical 'edits' parameter by stressing that 'find' text must be copied EXACTLY including whitespace and indentation, and explains the confirm/auto_commit workflow implications. This adds real operational meaning beyond the schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (exact search/replace edits), resource (existing file in a DreamAgent project) and scope (small, targeted changes). It explicitly distinguishes itself from dreamagent_write_file, so an agent can route correctly without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit preference rule (PREFERRED over dreamagent_write_file for editing), names the exclusion (use write_file only to CREATE or fully rewrite), and prescribes a prerequisite (read the file first) plus a confirmation workflow. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dreamagent_get_chat_statusGet chat statusRead-onlyInspect
Check the progress and final status of a specific AI development session using its session key. Use this to monitor an asynchronous edit until it completes, fails, or is cancelled — keep checking until a terminal state. The session key comes from dreamagent_chat or dreamagent_list_sessions and is an identifier, not a secret.
Returns (actual fields): 'active=', 'run_status=', 'next_after=' (cursor for the next check), optional 'new_output:' (text produced since the last check), then either "Still working — poll again" or a terminal 'done=true' line: finished (with the final output tail), 'the edit was NOT started: ' (rejected early, e.g. HTTP 402 insufficient credits), or 'stream error' (the connection to the run broke — the server-side run may still have finished; verify with dreamagent_get_edit_progress). run_status values: queued | running | cancel_requested | completed | failed | cancelled | interrupted | unknown.
| Name | Required | Description | Default |
|---|---|---|---|
| after | No | cursor from the previous check (0 on the first check). | |
| session_key | Yes | the session key returned by dreamagent_chat. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
dreamagent_get_edit_progressGet edit progressRead-onlyInspect
Check the latest AI edit progress for a project using its project identifier — no session key needed: the project id retrieves the session holding the latest edit. Use when the user asks whether their edit is finished, when the session key isn't available (e.g. a new conversation), and BEFORE starting any new edit.
Returns (actual fields): 'session_key=' (the identifier of the session this progress comes from), 'edit_active=', 'run_status=', 'chunks=' (output size so far), optional 'recent_output (tail):', and a terminal 'result:' line: finished (with the final output tail), 'the edit was NOT started: ' (rejected early, e.g. HTTP 402 insufficient credits), 'stream error', or 'no run is currently active'. run_status values: queued | running | cancel_requested | completed | failed | cancelled | interrupted | unknown.
Distinct from dreamagent_get_project_status: project status = creation/deployment state (creating/ready/failed); edit progress = current AI modification state; chat status (dreamagent_get_chat_status) monitors one specific session by its session key. If edit_active is true, do NOT launch another edit for the same project.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | the project being edited. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
dreamagent_get_file_diffShow file changes vs last commitRead-onlyInspect
Git diff of one project file against the last commit — shows the pending (not yet live) changes. Free, read-only. Use after edits to review exactly what changed before rebuilding.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | ||
| project_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
dreamagent_get_project_statusGet project statusRead-onlyInspect
Check a project's creation/deployment state. Terminal states are 'ready' (built and live) and 'failed'; while a project is being created it reports progressive phases such as 'creating', 'building', 'deploying', or 'ai_provisioning' — treat any non-terminal status as still building. Use after dreamagent_create_project (poll until ready or failed) and whenever the user asks whether a project is ready or live.
NOTE: this reports the PROJECT's build/deploy state — NOT AI edit progress. For edits use dreamagent_get_edit_progress.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | the project to check. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
dreamagent_list_commitsList project version historyARead-onlyInspect
Version history of a DreamAgent project — recent commits (hash, message, status, timestamp) from its persistent commit log, newest first. Use it to review what changed and when; the user can restore any version from the DreamAgent dashboard version-history UI (mention the short hash so they can find it).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| project_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), and the description adds real value beyond them: it discloses ordering (newest first), the source ('persistent commit log'), and the contents of each entry. It stops short of describing pagination or what happens when limit exceeds available commits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the identity of the resource and its returned fields, with the usage/UX hint placed second. The parenthetical field list and dashboard instruction both earn their space, though the second sentence is slightly long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be spelled out, and the description is still self-sufficient for a read-only list tool. The only real omission is any guidance on the limit parameter, which neither the description nor the schema covers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and there are 2 parameters. The description implies a bounded list ('recent commits') but never explains the limit parameter, its default of 10, or whether project_id is required/its format — so the schema-side gap is not compensated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (list) and resource (commits/version history) and enumerates the returned fields (hash, message, status, timestamp) plus ordering (newest first). It is clearly distinguishable from siblings like dreamagent_commit_push or dreamagent_get_file_diff without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit purpose ('use it to review what changed and when') and a concrete downstream workflow (tell the user the short hash so they can restore from the dashboard UI). It does not state when not to use it or name an alternative listing tool, but no close alternative exists among the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dreamagent_list_filesList project filesRead-onlyInspect
List the file tree of a DreamAgent project (source files only — hidden files like .env are excluded). Use before reading or editing a file to find the correct path.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
dreamagent_list_global_integrationsList connected integrationsRead-onlyInspect
List the user's saved credentials (Global Integrations).
ALWAYS call this before creating any bot project or asking the user for a token/API key. Saved credentials are referenced BY ID when creating projects: bot_token_integration_id for bot tokens, global_integration_ids for other keys. Secret values are never returned — only IDs and metadata (type, key name, verified, title).
If nothing suitable is saved: direct the user to dreamagent.cloud → Settings → Global Integrations to add it (one-time, verified, reusable). Never ask the user to paste tokens in chat.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
dreamagent_list_project_envList project environment variablesRead-onlyInspect
List a project's environment variables with their details.
Shows each key's name, title, description, docs URL, and category — values are masked (secrets are never returned). Use to see which integrations a project already has before adding more, or to answer "what keys does my project have?".
These are PROJECT-SPECIFIC variables — distinct from the user's Global Integrations — API-key credentials and connected OAuth services (dreamagent_list_global_integrations).
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | the project to inspect. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
dreamagent_list_projectsList DreamAgent projectsRead-onlyInspect
List the user's DreamAgent projects.
Returns each project's name, ID, type, status, and live domain (when available). Use when the user asks to see, find, select, or check their projects — and ALWAYS before modifying a project when its ID is not already known (resolve names to IDs here first).
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | optional exact-match filter (e.g. 'ready', 'failed'). During creation, projects report intermediate phases (creating/building/deploying/…), so filtering by 'creating' does not match every in-progress project. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
dreamagent_list_sessionsList project chat sessionsRead-onlyInspect
List a project's development sessions (conversation threads). Returns each session's identifier (session key) and context so you can select, continue, or monitor a specific development session — pass the session key to dreamagent_chat to continue that thread or to dreamagent_get_chat_status to monitor it. The session key is a reference used to address a session; it is not an authentication credential or a secret.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | the project. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
dreamagent_list_superpowersList available superpowersRead-onlyInspect
List DreamAgent Superpowers — the account's ready-made AI tools (song/video/image generation, voiceover, lip sync, voice clone, transcription, media processing, PDF tools) with their enabled state and beta pricing. Read-only; no credits consumed.
Use when the user asks what AI tools/superpowers are available, whether a specific tool is enabled, or what they can add to a project. Tools shown as enabled can be used from ANY of the user's projects through dreamagent_chat (just ask in the message).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
dreamagent_read_fileRead a project fileRead-onlyInspect
Read a source file from a DreamAgent project. file_path is the project-relative path (from dreamagent_list_files), e.g. "src/pages/Home.tsx" or "telegram/main.py". Hidden files (.env) and binaries are not readable.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | ||
| project_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
dreamagent_release_project_lockRelease the project lockInspect
RECOVERY-ONLY — releases a project's editing lock when a stale or abandoned session blocks new modifications. NOT a normal editing step, and NEVER a way to bypass an actively running edit.
The lock state is not machine-readable from here: to judge staleness, check dreamagent_get_edit_progress — if no edit is active but dreamagent_chat still fails with a lock error, the lock is stale. Confirm with the user before releasing if they may have the project open elsewhere.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | the project to unlock. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
dreamagent_screenshot_websiteScreenshot a website pageARead-onlyInspect
WEBSITE PROJECTS ONLY — capture a screenshot of a DreamAgent-hosted page by URL: a deployed project's domain (e.g. my-app.dreamagent.cloud or a connected custom domain) or dreamagent.cloud itself. Best for checking a project's live pages after edits or deploys and reviewing layouts — returns the PNG as an MCP image content block PLUS a public URL. Non-DreamAgent URLs are rejected (this is enforced both here and by the host firewall).
No project id needed — just the URL. Only public http(s) pages; private/internal hosts are rejected.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | absolute http(s) URL of the page to capture | |
| width | No | viewport width 320-1920 (default 1280) | |
| height | No | viewport height 240-2160 (default 800) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare the safety profile (readOnly, non-destructive, closed-world), and the description adds substantive behavior beyond them: the return is a PNG image content block plus a public URL, the URL allow-list is enforced both locally and by a host firewall, and private/internal hosts are rejected. That is exactly the extra context annotations cannot carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the scope constraint and organized into short, purposeful blocks with no filler. There is mild redundancy between the 'Non-DreamAgent URLs are rejected' line and the closing 'private/internal hosts are rejected' sentence, which keeps it from a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by explaining what is returned (PNG image block plus public URL). Scope, required input, and rejection behavior are all covered, so an agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters (url, width, height) are already documented with types, defaults and ranges. The description only reinforces the url requirement ('No project id needed — just the URL'), adding no new meaning for width/height, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a precise verb (capture a screenshot) and a tightly scoped resource (a DreamAgent-hosted page by URL), opening with 'WEBSITE PROJECTS ONLY' so the agent can immediately distinguish it from sibling tools that touch source files or project metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context for use ('Best for checking a project's live pages after edits or deploys and reviewing layouts') and clear exclusion rules ('Non-DreamAgent URLs are rejected'). It never names an alternative sibling (e.g. read_file for source inspection), so it stops short of full when/when-not/alternative coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dreamagent_write_fileWrite a project fileInspect
WRITE ACTION — overwrite or create one source file in a DreamAgent project with the exact content given. For CHANGING an existing file, prefer dreamagent_edit_file (small targeted find→replace edits — no need to send the whole file). By default the write is immediately committed and pushed to the project's GitHub repo and recorded in its session history & version history (so the user can restore/revert). Changes go live after the project is rebuilt (dreamagent_build_publish).
CONFIRM BEFORE CALLING — in ONE message show the user: the target path and a summary of the change, then call only after they agree. Never write on the first mention.
MULTI-FILE EDITS: pass auto_commit=false on each write, then call dreamagent_commit_push once at the end — one commit and one history entry for the whole batch.
GUARDS (enforced server-side, the same as the in-app code editor): path stays inside the project, hidden/credential files (.env, .git, keys) are rejected, content is scanned for malware/shell signatures and blocked, 2MB size cap. Failed scans return the reason.
The user can undo damage by editing in the DreamAgent editor or restoring a previous version from version history — still, prefer precise minimal diffs.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | ||
| content | Yes | ||
| file_path | Yes | ||
| project_id | Yes | ||
| auto_commit | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- Changed
dreamagent_create_project1 field changed- changed
Input schema / properties / confirm / descriptionPrevious value: -"must be true to execute — the call is REJECTED without it."New value: +"must be true to execute — OR simply call the tool a\nSECOND time with the exact same arguments within 5 minutes\n(repeat-call confirmation). Either path confirms."
3 tool updates
- Changed
dreamagent_create_project1 field changed- added
Input schema / properties / confirmAdded value: +{ + "default": false, + "description": "must be true to execute — the call is REJECTED without it.", + "type": "boolean" +}
- Changed
dreamagent_design_mode2 fields changed- changed
Input schema / properties / image_base64 / descriptionPrevious value: -"base64-encoded design reference image (PNG/JPG)."New value: +"base64-encoded design reference image (PNG/JPG/WEBP).\nSend the actual image bytes verbatim — the image IS the spec." - changed
Input schema / properties / instructions / descriptionPrevious value: -"what to change (e.g. \"match this dark theme with purple accents\",\n \"make the hero section look like this\", \"use this layout\")."New value: +"keep this SHORT — e.g. \"Match this design image exactly.\"\nThe image carries the design; do NOT write a long textual design\nspec duplicating what is visible in the image. Only add brief\nmust-have requirements the image cannot show (e.g. \"keep all\nexisting pages and functionality\", \"Product Hunt view only\")."
- Added
dreamagent_edit_file
5 tool updates
- Added
dreamagent_commit_push - Changed
dreamagent_delete_file1 field changed- added
Input schema / properties / auto_commitAdded value: +{ + "default": true, + "type": "boolean" +}
- Added
dreamagent_list_commits - Added
dreamagent_screenshot_website - Changed
dreamagent_write_file1 field changed- added
Input schema / properties / auto_commitAdded value: +{ + "default": true, + "type": "boolean" +}
1 tool update
- Added
dreamagent_design_mode
1 tool update
- Added
dreamagent_build_publish
2 tool updates
- Added
dreamagent_delete_file - Added
dreamagent_get_file_diff
3 tool updates
- Added
dreamagent_list_files - Added
dreamagent_read_file - Added
dreamagent_write_file
2 tool updates
- Changed
dreamagent_create_project1 field changed- changed
Input schema / properties / project_type / descriptionPrevious value: -"website / telegrambot / discordbot / scheduler."New value: +"website / telegrambot / discordbot / agent."
- Added
dreamagent_list_superpowers
12 tool updates
- First observed
dreamagent_cancel_chat - First observed
dreamagent_chat - First observed
dreamagent_create_project - First observed
dreamagent_create_session - First observed
dreamagent_get_chat_status - First observed
dreamagent_get_edit_progress - First observed
dreamagent_get_project_status - First observed
dreamagent_list_global_integrations - First observed
dreamagent_list_project_env - First observed
dreamagent_list_projects - First observed
dreamagent_list_sessions - First observed
dreamagent_release_project_lock
Related MCP Connectors
Deploy and manage your apps, databases, storage, and scheduled jobs from your AI agent
Let your AI agent build, preview and update web apps, download source and publish when you allow it.
- DilohostOAuthes.dilohost
Hosting run by your AI agent: publish websites, apps, databases, domains and email from chat.
- WebTwizzOAuthcom.webtwizz
Build websites and web apps with AI, see them in the chat, and publish them.
1
Related MCP Servers
- AlicenseNot gradedqualityAmaintenanceEnables AI agents to deploy code to any hosting provider by creating PRs, building, and verifying health checks, all from a single natural language command.41 npm1MIT
- AlicenseAqualityDmaintenanceEnables AI agents to deploy applications and manage servers over SSH using natural language commands, with built-in tools for Python bots, Docker Compose, and SSL setup.6MIT
- FlicenseNot gradedqualityDmaintenanceDeploy, manage, and scale applications directly from your AI assistant.5-
- AlicenseBqualityDmaintenanceEnables non-coders to build software by describing ideas in natural language, orchestrating AI agents and CLI workers via chat without needing a terminal.306 npm4Apache 2.0
Glama MCP Gateway
Add one secure layer between your agents and this server.