Dreamlit
Server Details
Create, test, publish, and manage Dreamlit notification workflows from AI clients.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- dreamlit-ai/dreamlit-mcp
- GitHub Stars
- 0
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.
Tool Definition Quality
Average 4.5/5 across 9 of 9 tools scored.
Each tool targets a distinct action in the workflow lifecycle: status, listing, inspection, creation, validation, publishing, testing, and unpublishing. Descriptions are highly specific with clear instructions on when to use each, leaving no ambiguity.
All tool names follow a consistent verb_noun pattern with lowercase and underscores, e.g., get_status, list_projects, create_or_update_workflow, confirm_publish. No mixing of conventions.
9 tools cover the essential workflow operations without redundancy. Each tool serves a clear purpose in the lifecycle, from status and listing to creation, validation, publishing, testing, and unpublishing.
Covers most lifecycle stages: status, listing, inspection, creation/update, validation, publishing, testing, and unpublishing. However, there is no tool for deleting a draft workflow, which is a minor gap in the CRUD coverage.
Available Tools
11 toolsconfirm_publishConfirm publishADestructiveInspect
Use only after explicit user confirmation and a prior prepare_publish result to publish or schedule a Dreamlit workflow. Side effect: installs live database/repeating/auth triggers, schedules or sends broadcasts, and may enable notification delivery; sandbox mode can hold notifications for inspection. Returns the published workflow status and app URLs. Do not call speculatively or without carrying forward the prepare_publish safety fields.
| Name | Required | Description | Default |
|---|---|---|---|
| workflowId | Yes | Workflow id to publish. | |
| isSandboxed | No | Whether to publish in sandbox mode so notifications are held for inspection. | |
| expectedUpdatedAtIso | No | Workflow updatedAt timestamp returned by prepare_publish, used as a safety check. | |
| expectedEditableVersionId | No | Editable version id returned by prepare_publish, used as a safety check. | |
| expectedPublishedVersionId | No | Published version id returned by prepare_publish, used as a safety check. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes | Dreamlit MCP result. success responses contain data and appUrls when relevant; auth_required, clarification_required, confirmation_required, handoff_required, and error responses explain the next action. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses important side effects: installs live database, repeating/auth triggers, schedules/sends broadcasts, and may enable notifications. Sandbox mode behavior is noted. Annotations already mark destructiveHint=true, but description adds specific behavioral context.
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: purpose and prerequisite, side effects and return, and a warning. No unnecessary words. Front-loaded with key usage constraints.
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 output schema (present but not shown), annotations, and parameter descriptions, this description covers the purpose, prerequisites, side effects, and safety requirements comprehensively for a publish tool.
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 covers all 5 parameters with descriptions. The description adds context by mentioning 'carrying forward the prepare_publish safety fields,' linking the expected* parameters to a prior step. This goes beyond basic schema info.
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 is for publishing or scheduling a Dreamlit workflow after explicit user confirmation and a prior prepare_publish result. It distinguishes from siblings by referencing the prepare_publish prerequisite and listing specific side effects like installing triggers.
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 use: 'only after explicit user confirmation and a prior prepare_publish result.' Provides a strong warning not to call speculatively or without safety fields from prepare_publish.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_or_update_workflowCreate or update workflowAInspect
Creates a new Dreamlit workflow draft or updates an existing draft from an outcome-oriented natural-language prompt. Use after get_status; use get_workflow_and_preview_url first when editing an existing workflow. Existing Supabase Auth workflows can be edited except for the immutable trigger step; creating Supabase Auth workflows must happen through Supabase Auth email setup in the Dreamlit web app. Side effect: may create or modify a draft, but does not publish or install live triggers. Returns the workflow/draft result, action-required or handoff details when more input is needed, and relevant app URLs. Do not use for publishing, direct database changes, or low-level graph edits.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Outcome-oriented workflow authoring request. Describe the event or schedule, audience, recipient, message goal, data needed, timing, business rules, and unsubscribe intent. Let Dreamlit choose email styling unless the user gives specific style direction. For broadcasts, request a future send time instead of an immediate send. | |
| projectId | No | Target project id for creating a new workflow draft. | |
| brandKitId | No | Optional Dreamlit brand kit id to use for generated email drafts. | |
| workflowId | No | Existing workflow id to continue editing. Use get_workflow_and_preview_url first when changing an existing workflow. | |
| userCurrentTimeIso | No | User's current time as an ISO timestamp with offset, useful for relative schedule requests. | |
| userCurrentTimeZoneId | No | IANA timezone id for the user, useful for repeating workflows and scheduled broadcasts. | |
| userEmailStepComments | No | Optional inline comments for revising email step content. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes | Dreamlit MCP result. success responses contain data and appUrls when relevant; auth_required, clarification_required, confirmation_required, handoff_required, and error responses explain the next action. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate mutation and non-destructive behavior. The description adds that it creates/modifies a draft without publishing or installing live triggers, and describes return values (result, action-required, handoff details, URLs). This supplements annotations well, though some behavioral traits (e.g., idempotency) are already covered.
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?
Four sentences, each serving a distinct purpose: core action, usage order, side effects/returns, and negative constraints. No superfluous information, front-loaded with the most important details.
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 (7 params, output schema, annotations), the description covers purpose, usage constraints, side effects, return types, and exclusions. The presence of an output schema and thorough annotations reduces the burden, 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?
Schema coverage is 100% with detailed parameter descriptions. The description adds context for the prompt parameter (outcome-oriented) and workflowId (use get_workflow_and_preview_url first), adding marginal value beyond the schema. Baseline 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 tool creates or updates a Dreamlit workflow draft from a natural-language prompt. It uses specific verbs and resource, and distinguishes it from sibling tools like get_workflow_and_preview_url and confirm_publish.
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 advises to use after get_status, to call get_workflow_and_preview_url first when editing, and lists what not to use it for (publishing, database changes, graph edits). This provides clear when-to-use, prerequisites, and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_analyticsGet analyticsARead-onlyIdempotentInspect
Read-only. Use to query Dreamlit analytics for overview metrics, notification rows, recipient engagement, or workflow run rows with filters, sorting, and cursor pagination. Returns bounded structured analytics data, effective query metadata, pagination details when rows are included, and relevant app URLs. Do not use for CSV exports, bulk dumps, workflow edits, publishing, or low-level database access.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Optional row sort. Overview ignores sorting. | |
| view | Yes | Analytics surface to query: overview cards, notification rows, recipient rows, or workflow run rows. | |
| limit | No | Maximum rows to return. Defaults to 25 and is capped at 100. | |
| range | No | Optional explicit timestamp range. Overrides window and is applied to the view's primary timestamp. | |
| cursor | No | Opaque pagination cursor from a previous get_analytics response. | |
| window | No | Relative analytics window. Defaults to 30d. Ignored when range is provided. | |
| channel | No | Notification channel for overview and notification analytics. Defaults to email. Recipient analytics are email-only. | |
| filters | No | Optional analytics filters. Unsupported combinations return a clear error. | |
| include | No | Optional response sections to include. Defaults depend on the requested view. | |
| timeZone | No | IANA timezone for daily series bucketing. Defaults to UTC. | |
| projectId | No | Project id to query analytics from. Required when access is ambiguous. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes | Dreamlit MCP result. success responses contain data and appUrls when relevant; auth_required, clarification_required, confirmation_required, handoff_required, and error responses explain the next action. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds behavioral context beyond these: it discloses that the tool returns 'bounded structured analytics data, effective query metadata, pagination details when rows are included, and relevant app URLs.' It also warns that 'unsupported combinations return a clear error.' No contradictions exist between the description and annotations. The description enriches the safety profile without repeating annotation information.
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 three sentences, each serving a distinct purpose: stating read-only nature, defining the tool's scope and return types, and listing exclusions. It is front-loaded with the most critical information ('Read-only') and avoids unnecessary elaboration. Every word contributes to clarity, and the negative list is efficient. This is an exemplary model of concise, structured documentation.
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 (11 parameters, nested objects, multiple views, filters, pagination), the description covers all essential aspects: what it queries, what it returns, how pagination and filters work, and explicit exclusions. An output schema exists, so return-value documentation is handled elsewhere. The description also mentions that unsupported filter combinations yield clear errors, aiding debuggability. No gaps are apparent for an AI agent to use this tool 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 input schema has 100% description coverage, with all 11 parameters thoroughly documented. The description adds no per-parameter details beyond the schema, but it does provide overarching context about filtering limitations and sorting behavior (e.g., 'Overview ignores sorting'). This extra context is useful but not extensive. Given the high schema coverage, a baseline of 3 is appropriate, with no significant added value that would raise the score.
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 the tool as a read-only analytics query for Dreamlit, specifying four distinct data surfaces (overview metrics, notification rows, recipient engagement, workflow run rows). It distinguishes itself from sibling tools that are write-oriented (e.g., create_or_update_workflow, send_workflow_test, unpublish_workflow) by explicitly stating it is not for CSV exports, bulk dumps, workflow edits, publishing, or database access. The verb 'query' and resource 'Dreamlit analytics' are precise and unambiguous.
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 guidance on when to use the tool ('Use to query Dreamlit analytics...') and when not to use it ('Do not use for CSV exports, bulk dumps, workflow edits, publishing, or low-level database access.'). This clear separation from sibling tools and common misuse cases helps an AI agent select the correct tool. The read-only annotation further reinforces safe usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_statusGet statusARead-onlyIdempotentInspect
Read-only. Use first when the agent needs Dreamlit product guidance, prompting guidance, approved workspace context, project setup, schema hints, workflow state, or relevant app URLs. Returns a compact context pack with concepts, recommended tool flow, actor/workspace/project data, optional authoring context, optional workflow context, and appUrls. Do not use this to create, update, publish, or unpublish workflows.
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | No | Optional project id. Include it to return project setup, schema hints, and authoring context. | |
| workflowId | No | Optional workflow id. Include it to return concise workflow state and preview URL. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes | Dreamlit MCP result. success responses contain data and appUrls when relevant; auth_required, clarification_required, confirmation_required, handoff_required, and error responses explain the next action. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. Description adds context about the response contents and conditional returns, enhancing transparency 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?
Description is well-structured with key information front-loaded ('Read-only. Use first.') and each sentence adds value, though could be slightly more concise.
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 existence of an output schema and fully described parameters, the description provides complete contextual information about when to use and what to expect, without gaps.
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?
Input schema has 100% description coverage, so the description does not need to add parameter details. It mentions optional parameters but adds no new semantics beyond the schema.
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 'Read-only' and lists specific use cases (Dreamlit product guidance, prompting guidance, etc.), distinguishing it from sibling tools that create, update, publish, or unpublish workflows.
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 says 'Use first when the agent needs...' and 'Do not use this to create, update, publish, or unpublish workflows', providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_workflow_and_preview_urlGet workflow and preview URLARead-onlyIdempotentInspect
Read-only. Use before editing, verifying, or preparing publish for an existing workflow. Returns normalized draft and published workflow structure plus the Dreamlit preview/builder URL and status URLs. Do not use to create, update, publish, or unpublish workflows.
| Name | Required | Description | Default |
|---|---|---|---|
| workflowId | Yes | Workflow id to inspect before editing, verifying, or publishing. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes | Dreamlit MCP result. success responses contain data and appUrls when relevant; auth_required, clarification_required, confirmation_required, handoff_required, and error responses explain the next action. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds detail about returning structures and URLs, which is useful but not beyond what annotations imply for safety.
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 concise sentences, front-loaded with 'Read-only', effectively conveying all necessary information without 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 output schema exists, the description adequately covers purpose, usage, return values, and behavioral context, leaving no significant gaps.
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% and the parameter description already clarifies its purpose. The description does not add new semantic meaning beyond what is in the schema, so baseline score 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 it is read-only and returns normalized workflow structures plus URLs, distinguishing it from sibling tools like create_or_update_workflow and unpublish_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 specifies when to use ('before editing, verifying, or preparing publish') and when not to use ('do not use to create, update, publish, or unpublish workflows'), providing clear context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_brand_kitsList brand kitsARead-onlyIdempotentInspect
Read-only. Use when the user wants a specific saved brand kit applied to generated email drafts. Returns paginated project brand kit summaries, ids for create_or_update_workflow brandKitId, default status, style metadata, and app URLs. Do not use to create, update, delete, or expose raw brand kit templates.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of brand kits to return for this page. | |
| offset | No | Zero-based brand kit offset for pagination. Use nextOffset from the previous response to fetch the next page. | |
| projectId | No | Project id to list brand kits from. Required when access is ambiguous. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes | Dreamlit MCP result. success responses contain data and appUrls when relevant; auth_required, clarification_required, confirmation_required, handoff_required, and error responses explain the next action. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description reinforces these and adds specific return content (summaries, ids, default status, style metadata, app URLs), providing behavioral context beyond 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?
Description is composed of four clear, front-loaded sentences with no redundant information. It efficiently covers purpose, usage, and exclusions.
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 presence of a detailed input schema and output schema, the description covers the key aspects: read-only nature, pagination (summary), use case, and exclusions. It does not mention error conditions or authorization, but these are less critical for a simple list tool.
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?
Input schema has 100% coverage with detailed descriptions. The description mentions that returned ids are used in create_or_update_workflow's brandKitId, which adds cross-tool context, but does not add parameter-level semantics beyond what schema provides.
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 is read-only, returns paginated brand kit summaries with specific fields (ids, default status, style metadata, app URLs), and explicitly distinguishes from creating/updating/deleting/exposing raw templates, which differentiates it from sibling tools.
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 specifies when to use: when a user wants a specific saved brand kit applied to email drafts. It also states what not to do (create, update, delete, expose raw templates). However, it does not explicitly mention alternative tools for other use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_projectsList projectsARead-onlyIdempotentInspect
Read-only. Use when the target project is unknown or the user names a project instead of providing an id. Returns accessible Dreamlit projects in the approved workspace with project and workflow-list URLs. Do not use to inspect workflow structure or author changes.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of projects to return. | |
| search | No | Optional project name search string. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes | Dreamlit MCP result. success responses contain data and appUrls when relevant; auth_required, clarification_required, confirmation_required, handoff_required, and error responses explain the next action. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds context by stating 'Read-only' and specifying what is returned (URLs) and scope (approved workspace). It does not mention rate limits or pagination but these are covered by the input schema (limit parameter) 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 very concise, consisting of three short sentences that convey purpose, usage, and exclusions. There is no fluff, but the structure could be slightly improved by separating the usage guideline from the output description more clearly.
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 has two simple parameters, full schema coverage, and an output schema, the description provides sufficient context: it explains what the tool returns, when to use it, and what not to use it for. It is complete for its complexity.
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% and the input schema clearly documents the two parameters with descriptions, default, and constraints. The description adds some context (e.g., 'search' implies finding by name) but does not substantially enhance beyond the schema. 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 lists projects, specifies the scope ('accessible Dreamlit projects in the approved workspace'), and what is returned ('project and workflow-list URLs'). It distinguishes from sibling tools by stating it is not for inspecting workflow structure, which separates it from workflow-related tools.
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 says 'Use when the target project is unknown or the user names a project instead of providing an id.' It also warns against using it to inspect workflow structure or author changes, providing clear context. It lacks explicit naming of alternative tools but is still strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_workflowsList workflowsARead-onlyIdempotentInspect
Read-only. Use to find workflows in a project by name, description, or trigger type before inspection or editing. Trigger filters include database, auth email, repeating, broadcast, and no-trigger workflows. Returns paginated workflow summaries, published/sandbox state, trigger type, workflow URLs, totalCount, hasMore, and nextOffset. Do not use as the final source of truth before editing; call get_workflow_and_preview_url for full structure.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of workflows to return for this page. | |
| offset | No | Zero-based workflow offset for pagination. Use nextOffset from the previous response to fetch the next page. | |
| search | No | Optional workflow name or description search string. | |
| projectId | No | Project id to list workflows from. Required when access is ambiguous. | |
| triggerFilters | No | Optional trigger type filters. Use broadcast only for one-time audience emails. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes | Dreamlit MCP result. success responses contain data and appUrls when relevant; auth_required, clarification_required, confirmation_required, handoff_required, and error responses explain the next action. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive; description adds details on returned fields (paginated summaries, states, trigger types, etc.) and trigger filter constraints.
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?
Five sentences, each adding value. Front-loaded with 'Read-only.' Could be slightly more concise but efficient overall.
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 output schema exists, description covers purpose, usage, parameters, and behavior completely for a list tool.
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%, but description adds context beyond schema (e.g., broadcast trigger only for one-time audience emails, projectId required when access ambiguous).
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 is read-only and used to find workflows by name, description, or trigger type before inspection or editing. It distinguishes from sibling tools like get_workflow_and_preview_url.
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 says when to use (before inspection/editing) and when not to use (not as final source of truth before editing), providing an alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
prepare_publishPrepare publishARead-onlyIdempotentInspect
Read-only validation step before publishing. Use after the user asks to publish and after inspecting the workflow if needed. Returns validation status, publish mode, preview URL, and a confirmation payload with version/timestamp safety checks for confirm_publish. Does not publish or schedule anything by itself.
| Name | Required | Description | Default |
|---|---|---|---|
| workflowId | Yes | Workflow id to validate and prepare for explicit publish approval. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes | Dreamlit MCP result. success responses contain data and appUrls when relevant; auth_required, clarification_required, confirmation_required, handoff_required, and error responses explain the next action. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'Does not publish or schedule anything by itself', which aligns with the readOnlyHint annotation but adds behavioral clarity. It also mentions that the tool returns a confirmation payload with safety checks, hinting at its read-only nature beyond what annotations alone 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 a single paragraph of three sentences. The first sentence captures the core purpose. The second sentence gives usage guidance. The third details returns. Every sentence adds value without redundancy. It is optimally concise.
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 simple tool with one parameter and existing output schema plus annotations, the description covers purpose, usage, non-side-effect nature, and return contents. It is sufficiently complete for an agent to select and invoke the tool correctly without additional context.
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 has 100% coverage with a description for workflowId that is present in the schema itself. The tool description does not add additional parameter semantics beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Read-only validation step before publishing', clearly stating the verb (validate) and resource (publish workflow). It distinguishes itself from sibling 'confirm_publish' by noting that it does not publish or schedule anything. The return values are listed, making the purpose highly specific.
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 says 'Use after the user asks to publish and after inspecting the workflow if needed', providing clear context on when to invoke this tool. It implies that this is a precursor to confirm_publish. However, it does not explicitly state when not to use it or mention alternatives beyond the implied next step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
send_workflow_testSend workflow testAInspect
Side effect when confirmSend is true: sends one current draft email or Slack message for review, but does not publish, schedule, or edit the workflow. Use after authoring or inspection when the user wants to verify an important message before publishing. Returns sent-test details, app URLs, a confirmation request, or a clarification request with user-facing message choices. Do not expose test target ids as copy; ask users to choose by message label and confirm before sending.
| Name | Required | Description | Default |
|---|---|---|---|
| rowData | No | Optional sample data for rendering draft message variables during the test. If omitted, Dreamlit uses the same default preview data as the web builder when available. | |
| workflowId | Yes | Workflow id whose editable draft message should be tested. | |
| confirmSend | No | Set to true only after the user explicitly confirms sending this selected test message. If omitted or false, Dreamlit returns confirmation_required and does not send. | |
| messageType | No | Optional message type filter when selecting a draft message to test. | |
| testTargetId | No | Structured test target id from testableMessages. Do not show this id to users; ask them to choose by message label. | |
| testRecipientEmail | No | Optional recipient for email tests. If omitted, Dreamlit sends to the authenticated user's email address. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes | Dreamlit MCP result. success responses contain data and appUrls when relevant; auth_required, clarification_required, confirmation_required, handoff_required, and error responses explain the next action. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are basic (readOnlyHint=false, destructiveHint=false), so the description carries the burden. It discloses the side effect when confirmSend is true, the return types (sent-test details, app URLs, confirmation requests, clarification requests), and warns about not exposing test target IDs. This adds value beyond 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 four sentences, front-loaded with the key side effect. Every sentence adds essential information: side effect, when to use, return types, and a usage warning. No redundancy or unnecessary text.
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 complexity (6 parameters, 100% schema coverage, output schema exists), the description is complete. It covers behavior, return types, and parameter guidance. The schema descriptions fill in remaining details.
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 baseline is 3. The description adds guidance for testTargetId ('do not expose... ask users to choose by message label') and explains the logic of confirmSend. This enhances understanding beyond the schema.
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 sends a draft email or Slack message for review, using specific verbs and resource. It distinguishes itself from sibling tools like confirm_publish and create_or_update_workflow by explicitly noting it does not publish, schedule, or edit.
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 says 'Use after authoring or inspection when the user wants to verify an important message before publishing,' providing clear context. While it doesn't explicitly list alternatives, the context and sibling names imply when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
unpublish_workflowUnpublish workflowADestructiveInspect
Use after explicit user intent to unpublish a Dreamlit workflow. Side effect: disables live triggers or schedules for that workflow and stops future automated sends. Returns updated workflow status and app URLs. Do not use for deleting drafts, canceling one broadcast run, or editing workflow content.
| Name | Required | Description | Default |
|---|---|---|---|
| workflowId | Yes | Workflow id to unpublish and disable live triggers or schedules. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes | Dreamlit MCP result. success responses contain data and appUrls when relevant; auth_required, clarification_required, confirmation_required, handoff_required, and error responses explain the next action. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavioral traits beyond annotations: it mentions side effects such as disabling live triggers/schedules and stopping future automated sends. Since annotations already indicate destructiveHint=true, the description adds specific context without contradiction.
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 three sentences long, front-loaded with the primary action, and every sentence provides valuable information. No redundant or irrelevant content.
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 has a single parameter, full schema coverage, an output schema (not shown but indicated), and annotations, the description sufficiently covers purpose, usage guidelines, and behavioral effects. No gaps for this complexity level.
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%, and the parameter 'workflowId' is already documented in the schema with description. The description adds no additional semantics about the parameter, such as validation or examples. 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 starts with 'Use after explicit user intent to unpublish a Dreamlit workflow,' which clearly specifies the verb (unpublish) and the resource (workflow). This distinguishes it from siblings like confirm_publish or prepare_publish, which have different intents.
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 not to use the tool: 'Do not use for deleting drafts, canceling one broadcast run, or editing workflow content.' This provides clear exclusions. However, it could additionally mention when alternatives like prepare_publish or get_status might be more appropriate.
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.
Discussions
No comments yet. Be the first to start the discussion!