flow-agent-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| FLOWCTL_PATH | No | Path to a specific flowctl binary. | |
| ESTUARY_DRY_RUN | No | Set to 'true' to echo flowctl commands without executing them. | |
| WEATHER_INGEST_URL | No | Ingest URL for the weather demo to push data to Estuary. | |
| WEATHER_INGEST_TOKEN | No | Token for the weather demo ingest URL. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_tasksB | List catalog entities (captures, materializations, collections). Wraps |
| task_statusB | Control-plane status for one task. Wraps |
| task_statsB | Throughput and document counts for a task. Wraps |
| task_logsB | Recent task logs, optionally filtered by level. Wraps |
| task_healthA | End-to-end health check: combines status, throughput, and error-level logs in one call. |
| discover_bindingsA | Discover available bindings for a source connector. Writes a temporary flow.yaml and runs |
| create_captureA | Publish a capture. Writes the spec to a temporary flow.yaml and runs |
| create_materializationA | Publish a materialization. Writes the spec to a temporary flow.yaml and runs |
| pull_specsA | Pull a task's live spec for local inspection. Wraps |
| set_task_enabledA | Enable or disable a task by toggling |
| restart_taskA | Force a connector restart: disable the task, then re-enable it. Resumes from the last checkpoint, so no data is lost. Use to clear transient errors or load updated config. |
| read_collectionA | Read documents from a collection to verify data is landing. Wraps |
| generate_synthetic_dataA | Generate synthetic records for demo pipelines. Returns a sample plus the full payload size. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 13 tools
Most tools have clearly distinct purposes: stats, logs, health, status, create, discover, etc. The health tool intentionally combines status and stats, but its description clearly delineates its role. Minor confusion is possible between task_status and task_health, but each serves a distinct need.
Names mix noun-first patterns (task_stats, task_logs, task_health, task_status) with verb-first patterns (discover_bindings, create_capture, list_tasks). While all names use snake_case and are readable, the inconsistent prefix style makes the naming less predictable.
13 tools is a well-scoped count for a Flow management server. It covers monitoring, lifecycle operations, discovery, and data verification without excessive overlap or unnecessary bloat.
The toolset covers monitoring, creation, enable/disable, restart, and inspection well. However, there is no explicit delete or general update operation beyond toggling enabled state, which is a notable gap for full task lifecycle management.