Build, edit, and deploy websites, bots, and applications with AI. DreamAgent lets AI assistants create projects, modify code, build applications, and manage deployments through natural language.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.6/5 across 12 of 12 tools scored.
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).
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.
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.
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.
dreamagent_cancel_chatADESTRUCTIVE — 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. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral context beyond the destructiveHint annotation, including the expected return messages, the instruction to report the edit as stopped, and the need to poll status. There is no contradiction with 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet comprehensive, front-loaded with 'DESTRUCTIVE' to immediately signal caution. It follows a logical flow covering action, usage condition, post-action guidance, return value, and follow-up steps, with every sentence earning its place.
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?
Given the tool's complexity, the description covers all necessary aspects: purpose, usage constraints, expected outcomes, and subsequent actions. It is complete enough for an agent to use the tool correctly without ambiguity.
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?
The input schema provides a complete description of the single parameter (session_key) at 100% coverage, so the description itself adds no additional parameter meaning. Baseline 3 is appropriate as the schema already handles the parameter semantics.
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 clearly states that the tool stops a currently running AI edit, using the specific verb 'stops' and a specific resource. It distinguishes itself from sibling tools by focusing solely on cancellation, making its purpose unmistakable.
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?
Provides explicit usage conditions: 'Use ONLY when the user explicitly asks to stop/cancel the active edit.' It also instructs not to claim completion and directs polling status tools afterward, offering clear guidance on when and how to use the tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dreamagent_chatAInspectWRITE 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.
| 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. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false), the description discloses asynchronicity (returns immediately with session_key), the need to monitor to a terminal state, credit consumption, error formats with specific HTTP codes, and a one-edit-at-a-time concurrency constraint. This adds substantial behavioral context well beyond what annotations provide.
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?
The description is long but well-structured with clear section headers (WRITE ACTION, ASYNCHRONOUS, ERRORS, ONE EDIT AT A TIME). Every paragraph carries essential information about invocation, monitoring, error handling, and concurrency, with no unnecessary 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?
Given the tool's complexity (async, write action, error handling, concurrency), the description is complete. It covers what to do before calling, what happens on return, how to determine success, how to interpret errors, and what not to do. The existence of an output schema also reduces the need to explain return values in the description.
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 the baseline is 3. The description adds guidance for the message parameter ('Describe ONLY the desired change') and mentions session_key in the async return context, but does not add new semantics for new_session or session_key beyond the schema's existing descriptions.
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 opens with 'WRITE ACTION — builds, modifies, or fixes an EXISTING project with a natural-language instruction,' using a specific verb and resource scope. It clearly distinguishes this tool from sibling tools by positioning it as the edit/change action, and explicitly excludes review/advice requests.
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?
The description provides explicit when-to-use guidance ('Use ONLY when the user clearly asks for a change') and when-not-to-use guidance ('If the user is only asking for advice, analysis, review, or suggestions... do NOT call this'). It also names the monitoring sibling tools (dreamagent_get_edit_progress, dreamagent_get_chat_status) as alternatives to use after invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dreamagent_create_projectAInspectWRITE 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:
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | project name (max 30 chars; a public subdomain is auto-generated). | |
| env_vars | No | optional non-secret environment variables. | |
| description | No | the build request (what + for whom + features/tone). | |
| project_type | Yes | website / telegrambot / discordbot / scheduler. | |
| 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). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
dreamagent_create_sessionAInspectCreate 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. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only, non-destructive. The description adds useful behavioral context: the session is separate, has its own context, and does not replace the project. This goes beyond the annotations by clarifying the relationship between the session and the existing project.
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?
Three sentences, front-loaded with the main action, followed by a clear use case and a clarifying note. No wasted words; every sentence contributes meaning.
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 create tool with two simple parameters, an output schema, and annotations, the description covers the essential purpose, use case, and side-effect clarification. It is complete enough without needing to explain return values because an output schema exists.
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?
The schema provides 100% coverage for both parameters (project_id, label). The description adds no additional parameter-level meaning beyond restating that it's 'for a project,' which aligns with project_id. Baseline 3 is appropriate since the schema does the heavy lifting.
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 clearly states the action ('Create a new development session for a project'), the resource ('development session'), and the scope ('for a project'), while distinguishing it as a 'separate conversation with its own context.' This differentiates it from sibling tools like create_project or list_sessions.
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 provides an explicit use case ('Use when the user wants to start a distinct development topic') and clarifies a key non-effect ('does NOT replace or affect the existing project'). However, it does not name alternate tools explicitly, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dreamagent_get_chat_statusACheck 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. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true and destructiveHint=false, but the description goes well beyond that by detailing polling behavior, return fields, run_status values, and terminal states. It even discloses edge cases like stream error and the possibility that the server-side run may have finished.
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?
The description is dense but every sentence contributes useful information: purpose, usage, session key origin, return fields, status values, and error handling. While slightly run-on in structure, it is not wasteful and stays relevant for a polling tool of this complexity.
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?
Given the tool's complexity (polling, multiple terminal states, error cases), the description is complete. It covers all return scenarios, run_status enumerations, and how to act on stream errors. The presence of an output schema also reduces the need to describe return format further, and the description fills remaining gaps effectively.
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?
The input schema already covers both parameters with clear descriptions, giving a baseline of 3. The description adds useful context beyond the schema, such as 'is an identifier, not a secret' for session_key and the cursor's role in 'the next check' for after, which enriches the parameter semantics.
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 clearly states the tool's purpose: 'Check the progress and final status of a specific AI development session using its session key.' It uses a specific verb ('check') and resource ('progress and final status'), and distinguishes it from siblings like dreamagent_get_edit_progress and dreamagent_get_project_status.
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 explicitly says when to use the tool: 'Use this to monitor an asynchronous edit until it completes, fails, or is cancelled.' It also provides alternative guidance for error cases: 'verify with dreamagent_get_edit_progress' on stream error, and mentions session key provenance from dreamagent_chat or dreamagent_list_sessions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dreamagent_get_edit_progressACheck 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. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, but the description goes beyond by detailing return fields (session_key, edit_active, run_status, etc.), enumerating possible run_status values, and warning against concurrent edits. This provides a rich behavioral picture that annotations alone do not offer.
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?
The description is information-dense but every sentence serves a purpose: purpose, usage, return format, status values, and sibling differentiation. It is structurally front-loaded with the main verb and resource, and the logical flow makes it easy to scan. No wasted words.
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?
Given the tool's complexity (multiple statuses, return fields, and sibling tools), the description covers all necessary contexts: when to use, what returns, status meanings, and how it differs from related tools. Even though an output schema exists, the description independently explains the return shape and critical caveats, making it fully complete for an agent.
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?
The schema already provides 100% coverage for the single param project_id ('the project being edited'), so baseline is 3. The description adds value by explaining that the project id retrieves the session holding the latest edit, clarifying why no session key is needed. This enhances understanding beyond the schema's minimal definition.
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 clearly identifies a specific action ('Check the latest AI edit progress for a project') and resource ('edit progress'). It also distinguishes from sibling tools by explicitly noting 'no session key needed' and contrasting with project/chat status tools. This makes the tool's unique purpose immediately clear.
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?
Provides explicit when-to-use guidance: 'when the user asks whether their edit is finished', 'when the session key isn't available', and 'BEFORE starting any new edit'. It also specifies exclusions by comparing to sibling tools and instructs not to launch another edit if edit_active is true. This is textbook usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dreamagent_get_project_statusACheck 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. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description aligns without contradiction. It adds valuable behavioral context about terminal vs. non-terminal states and advises treating any non-terminal status as still building, which goes beyond the schema and annotations.
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?
The description is efficiently structured, with the main purpose front-loaded and a clear second paragraph for the critical distinction from sibling tools. Every sentence contributes essential information; no wasted words.
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?
The description fully covers the tool's context: state semantics, polling workflow, and exclusions. Given the simple schema and presence of an output schema, it provides enough information for an agent to select and use this tool correctly without ambiguity.
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 the schema already documents the project_id parameter. The description only restates 'the project to check' without adding new semantic detail, so baseline 3 is appropriate.
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 clearly states the tool checks a project's creation/deployment state with specific verbs and resources. It explicitly distinguishes from sibling tools like dreamagent_get_edit_progress by clarifying what it does NOT report (AI edit progress).
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?
Provides explicit guidance: use after dreamagent_create_project for polling until ready/failed, and whenever the user asks if a project is ready/live. It also names the alternative tool for edit progress, satisfying when-not-to-use criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dreamagent_list_global_integrationsAList 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 | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds critical behavioral context: 'Secret values are never returned — only IDs and metadata (type, key name, verified, title).' It also explains that credentials are referenced by ID when creating projects, which is beyond what annotations provide. No contradiction with annotations.
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?
The description is concise but information-dense. It front-loads the primary purpose, then adds usage guidance and behavioral caveats in a well-structured format. Every sentence serves a purpose, and there is no redundant 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?
Given the tool's simplicity (no parameters) and the presence of an output schema, the description covers all essential aspects: what the tool returns, how to use the results (IDs for project creation), and what to do when no credentials are available. It is complete for the tool's scope.
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?
The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific semantics (none exist), but it does explain how the result should be used (referencing IDs for project creation). Since there are no params to document, the description adequately compensates by clarifying the output's role.
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 opens with a specific verb and resource: 'List the user's saved credentials (Global Integrations).' It clearly distinguishes this from sibling list tools (list_projects, list_sessions) by specifying the resource as credentials and tying it to the project creation workflow.
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 states when to call: 'ALWAYS call this before creating any bot project or asking the user for a token/API key.' It also gives fallback instructions if nothing suitable is saved, directing the user to add credentials via settings. This provides clear context and excludes alternative approaches like asking for tokens in chat.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dreamagent_list_project_envAList 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 (dreamagent_list_global_integrations).
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | the project to inspect. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds valuable behavioral detail: values are masked and secrets are never returned, plus enumerates returned fields (name, title, description, docs URL, category). This goes beyond the annotations, though it doesn't describe any edge cases like empty projects or error 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?
Description is compact and well-structured: opens with the primary action, then lists output fields and the masking caveat, then provides usage guidance and sibling distinction. Every sentence contributes value without redundancy.
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?
Given the tool's simplicity (1 param, output schema present), the description is fully self-contained. It explains what the tool returns (fields, masked values), when to use it, and how it differs from the related global integrations tool. No important context 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 has 100% coverage for the single parameter project_id with description 'the project to inspect.' The description does not add any substantive new meaning to the parameter beyond what's in the schema; it merely ties the parameter to the project. Baseline 3 is appropriate when schema fully documents the param.
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?
Description clearly states it lists a project's environment variables with details, naming the specific resource (project env vars). It explicitly distinguishes from sibling tool dreamagent_list_global_integrations by noting project-specific vs global integrations.
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?
Provides explicit use cases: 'to see which integrations a project already has before adding more' and answering 'what keys does my project have?'. Also explicitly contrasts with the global integrations alternative, telling the agent when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dreamagent_list_projectsAList 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. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds value by disclosing the exact return fields and the 'when available' caveat for live domain, plus the scoping to 'the user's' projects—useful context beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, and every sentence adds value. The structure is ideal: statement, return-value summary, and usage guidance in a compact form.
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?
Given the tool's simplicity (1 optional param, no nested objects, output schema present), the description fully covers what an agent needs: what the tool lists, returned fields, and when to invoke it. There are no significant gaps that would impair correct selection or invocation.
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 fully documents the single optional 'status' parameter. The description does not mention the parameter or add any extra semantic meaning beyond the schema, hence the baseline 3.
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 opens with a specific verb+resource ('List the user's DreamAgent projects') and clearly distinguishes the tool's role from siblings like create_project or get_project_status. It also adds the specific returns (name, ID, type, status, live domain), grounding the purpose in concrete output.
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?
The description explicitly states when to use it ('when the user asks to see, find, select, or check their projects') and even provides a prerequisite usage ('ALWAYS before modifying a project when its ID is not already known'). It does not name alternative tools, so it stops short of a fully explicit alternatives wnen/wnen-not breakdown.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dreamagent_list_sessionsAList 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. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds useful context: it returns session key and context, and clarifies that the session key is not an authentication credential or secret. It doesn't mention pagination or limits, but for a read-only list this is acceptable.
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?
The description is concise: three sentences with front-loaded purpose, output explanation, and a security clarification. Every sentence earns its place without redundancy or irrelevant detail.
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?
Given the tool's simplicity (one required parameter, full schema coverage, output schema present, and clear annotations), the description is complete. It covers what the tool returns and how to use the result, and does not need to explain return values because the output schema exists.
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% with project_id described as 'the project.' The description reinforces the per-project scope but adds no format or lookup guidance beyond the schema. With the schema handling parameter semantics, a baseline score of 3 is appropriate.
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 clearly states the action ('List'), the resource ('a project's development sessions'), and the scope ('conversation threads'). It distinguishes itself from sibling tools by focusing on listing sessions and mentions that the returned session key is for use with dreamagent_chat and dreamagent_get_chat_status.
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?
The description explicitly explains when to use the tool ('select, continue, or monitor a specific development session') and references sibling tools for follow-up actions. It clearly positions this tool as the starting point for session operations, 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.
dreamagent_release_project_lockAInspectRECOVERY-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. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already indicate non-read-only and non-destructive, the description adds crucial behavioral context: it is a recovery-only action, not for bypassing active edits, and lock state is not directly readable, requiring cross-referencing with another tool. The user confirmation requirement further clarifies the operational implications.
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?
The description is concise yet complete, with front-loaded 'RECOVERY-ONLY' and a clear verb phrase. Each sentence serves a purpose: warning, verification procedure, and user-safety note. The line breaks improve readability without padding.
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?
Given the tool's niche recovery purpose and the availability of an output schema, the description fully covers the decision-making context: when to use, how to verify staleness, and what precautions to take. No critical information is missing for an AI agent to invoke 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?
The schema fully documents the single parameter project_id as 'the project to unlock' with 100% coverage. The description adds contextual meaning by linking project_id to lock stale/abandoned state, but this doesn't significantly enhance the parameter's semantic clarity beyond the schema baseline.
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 clearly states the tool's function: 'releases a project's editing lock when a stale or abandoned session blocks new modifications.' The verb 'releases' and resource 'project's editing lock' are specific, and the recovery-only framing distinguishes it from normal editing tools like dreamagent_chat or dreamagent_cancel_chat.
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?
Explicit usage guidance is provided: 'RECOVERY-ONLY', 'NOT a normal editing step', and 'NEVER a way to bypass an actively running edit.' It also gives a concrete procedure for determining staleness by checking dreamagent_get_edit_progress and advises user confirmation, leaving no ambiguity about when or how to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
