Skip to main content
Glama

Server Details

Build and deploy websites, Telegram and Discord bots from chat via the DreamAgent platform.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
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

A4.2/5.0

Scored across 20 tools

Disambiguation4/5

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.

Naming Consistency4/5

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.

Tool Count3/5

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.

Completeness4/5

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 tools
dreamagent_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'.

ParametersJSON Schema
NameRequiredDescriptionDefault
confirmNo
project_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes
dreamagent_cancel_chatCancel the running chat
Destructive
Inspect

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'.

ParametersJSON Schema
NameRequiredDescriptionDefault
session_keyYesthe session key of the running edit.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes
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.

ParametersJSON Schema
NameRequiredDescriptionDefault
messageYesthe desired change (what + any behavioral constraints).
project_idYesthe project to modify.
new_sessionNooptional — start a fresh session for a new topic.
session_keyNooptional — continue a specific development session.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes
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.

ParametersJSON Schema
NameRequiredDescriptionDefault
confirmNomust be true to execute
messageNoshort commit message, e.g. "Add pricing page hero section" (default "MCP edit: project <id>")
project_idYesproject to commit

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.8/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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:

  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.

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesproject name (max 30 chars; a public subdomain is auto-generated).
confirmNomust 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_varsNooptional non-secret environment variables.
descriptionNothe build request (what + for whom + features/tone).
project_typeYeswebsite / telegrambot / discordbot / agent.
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

ParametersJSON Schema
NameRequiredDescription
resultYes
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.

ParametersJSON Schema
NameRequiredDescriptionDefault
labelNooptional name for the session.ChatGPT
project_idYesthe project.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes
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.

ParametersJSON Schema
NameRequiredDescriptionDefault
confirmNo
file_pathYes
project_idYes
auto_commitNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes
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:

  1. The project being redesigned

  2. The design instructions Then call only with confirm=true after they agree.

ParametersJSON Schema
NameRequiredDescriptionDefault
confirmNomust be true to execute.
project_idYesthe website project to redesign.
image_base64Yesbase64-encoded design reference image (PNG/JPG/WEBP). Send the actual image bytes verbatim — the image IS the spec.
instructionsYeskeep 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

ParametersJSON Schema
NameRequiredDescription
resultYes
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.

ParametersJSON Schema
NameRequiredDescriptionDefault
editsYeslist of edit objects: {"find": "<exact existing text>", "replace": "<new text>", "all": false} # optional: replace every occurrence
confirmNomust be true to execute.
file_pathYesproject-relative path of the EXISTING file to edit.
project_idYesproject containing the file.
auto_commitNocommit+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

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.9/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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 status
Read-only
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
afterNocursor from the previous check (0 on the first check).
session_keyYesthe session key returned by dreamagent_chat.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes
dreamagent_get_edit_progressGet edit progress
Read-only
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
project_idYesthe project being edited.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes
dreamagent_get_file_diffShow file changes vs last commit
Read-only
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYes
project_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes
dreamagent_get_project_statusGet project status
Read-only
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
project_idYesthe project to check.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes
dreamagent_list_commitsList project version historyA
Read-only
Inspect

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).

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
project_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters2/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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 files
Read-only
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
project_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes
dreamagent_list_global_integrationsList connected integrations
Read-only
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes
dreamagent_list_project_envList project environment variables
Read-only
Inspect

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).

ParametersJSON Schema
NameRequiredDescriptionDefault
project_idYesthe project to inspect.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes
dreamagent_list_projectsList DreamAgent projects
Read-only
Inspect

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).

ParametersJSON Schema
NameRequiredDescriptionDefault
statusNooptional 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

ParametersJSON Schema
NameRequiredDescription
resultYes
dreamagent_list_sessionsList project chat sessions
Read-only
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
project_idYesthe project.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes
dreamagent_list_superpowersList available superpowers
Read-only
Inspect

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).

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes
dreamagent_read_fileRead a project file
Read-only
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYes
project_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes
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.

ParametersJSON Schema
NameRequiredDescriptionDefault
project_idYesthe project to unlock.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes
dreamagent_screenshot_websiteScreenshot a website pageA
Read-only
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesabsolute http(s) URL of the page to capture
widthNoviewport width 320-1920 (default 1280)
heightNoviewport height 240-2160 (default 800)

TDQS

A4.4/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/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 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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
confirmNo
contentYes
file_pathYes
project_idYes
auto_commitNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool update
    • Changeddreamagent_create_project1 field changed
      • changedInput schema / properties / confirm / description
        Previous 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."
  2. 3 tool updates
    • Changeddreamagent_create_project1 field changed
      • addedInput schema / properties / confirm
        Added value: +{
        +  "default": false,
        +  "description": "must be true to execute — the call is REJECTED without it.",
        +  "type": "boolean"
        +}
    • Changeddreamagent_design_mode2 fields changed
      • changedInput schema / properties / image_base64 / description
        Previous 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."
      • changedInput schema / properties / instructions / description
        Previous 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\")."
    • Addeddreamagent_edit_file
  3. 5 tool updates
    • Addeddreamagent_commit_push
    • Changeddreamagent_delete_file1 field changed
      • addedInput schema / properties / auto_commit
        Added value: +{
        +  "default": true,
        +  "type": "boolean"
        +}
    • Addeddreamagent_list_commits
    • Addeddreamagent_screenshot_website
    • Changeddreamagent_write_file1 field changed
      • addedInput schema / properties / auto_commit
        Added value: +{
        +  "default": true,
        +  "type": "boolean"
        +}
  4. 1 tool update
    • Addeddreamagent_design_mode
  5. 1 tool update
    • Addeddreamagent_build_publish
  6. 2 tool updates
    • Addeddreamagent_delete_file
    • Addeddreamagent_get_file_diff
  7. 3 tool updates
    • Addeddreamagent_list_files
    • Addeddreamagent_read_file
    • Addeddreamagent_write_file
  8. 2 tool updates
    • Changeddreamagent_create_project1 field changed
      • changedInput schema / properties / project_type / description
        Previous value: -"website / telegrambot / discordbot / scheduler."New value: +"website / telegrambot / discordbot / agent."
    • Addeddreamagent_list_superpowers
  9. 12 tool updates
    • First observeddreamagent_cancel_chat
    • First observeddreamagent_chat
    • First observeddreamagent_create_project
    • First observeddreamagent_create_session
    • First observeddreamagent_get_chat_status
    • First observeddreamagent_get_edit_progress
    • First observeddreamagent_get_project_status
    • First observeddreamagent_list_global_integrations
    • First observeddreamagent_list_project_env
    • First observeddreamagent_list_projects
    • First observeddreamagent_list_sessions
    • First observeddreamagent_release_project_lock

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    A
    maintenance
    Enables 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 npm
    1
    MIT
  • A
    license
    A
    quality
    D
    maintenance
    Enables 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.
    6
    MIT
  • A
    license
    B
    quality
    D
    maintenance
    Enables non-coders to build software by describing ideas in natural language, orchestrating AI agents and CLI workers via chat without needing a terminal.
    30
    6 npm
    4
    Apache 2.0
Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.