Use Spade from an AI Assistant
Spade runs an MCP server, so an AI assistant can work with your Spade account directly. Describe what you want in plain language ("clip this DEM to my study area and map its slope") and the assistant finds the right blocks, drafts the pipeline, checks it with the same validator spade check uses, and, once you agree, runs it in the cloud and reports back.
The assistant works from what actually exists. It reads real block definitions before using them, and no pipeline is submitted until it validates, so a guessed block name or a miswired input is caught before anything runs.
Connect🔗
The server address is:
https://app.psae.us/mcpIt works with any MCP client that supports remote servers over Streamable HTTP with OAuth, and the client registers itself; there is nothing to set up in Spade first.
Claude (claude.ai or Claude Desktop): add a custom connector and give it the address above.
Claude Code:
claude mcp add --transport http spade https://app.psae.us/mcpOther clients: add a remote MCP server with the same address.
The first time the assistant uses Spade, your browser opens Spade's sign-in page. Sign in with your usual Spade account and approve the connection. The assistant then acts as you: it sees your blocks, pipelines and runs, plus anything shared with you or made public, and nothing else.
What the assistant can do🔗
| Tool | What it does |
|---|---|
list_collections | Lists the block collections you can use |
search_blocks | Finds blocks by keyword |
get_block | Reads one block's exact inputs, outputs and settings |
validate_pipeline | Checks a drafted pipeline and explains any problems |
submit_pipeline | Runs a pipeline in the cloud, after validating it again |
get_pipeline_status | Reports a run's progress, block by block |
get_invocation_logs | Reads a block's logs, which is where the reason for a failure lives |
Clients that support them also get each block's definition as a resource (spade://block/<id>), and an author_pipeline prompt that walks the assistant through the whole loop for a goal you describe.
How a session goes🔗
- You describe the goal, or start the
author_pipelineprompt with it. - The assistant looks up blocks with
search_blocksand reads each one withget_blockbefore using it. - It drafts the pipeline in short-code form, the same readable YAML you would write by hand.
- It validates. Each problem comes back tied to a specific block, with a hint for fixing it, and the assistant repeats until the pipeline is valid.
- You approve, and it submits. The run appears in the web UI like any other.
- It follows the run and, if a block fails, reads that block's logs to tell you why.
Everything the assistant does is visible in the web UI: submitted runs are listed under Results, with their outputs, logs and sharing controls.
What it cannot do🔗
Some actions stay with you, on purpose:
- Publish collections. Publishing is part of how Spade establishes trust in blocks, so it is always a human action with
spade publish. - See secret values. The assistant can name which of your stored secrets a block should use, but it never reads, writes or transmits a secret's value. Store secrets in the web UI or with
spade secret. - Cancel runs. Cancel from the run's page in the web UI.
- Download result files. The assistant reads status and logs; download outputs from the web UI.
- Develop blocks. Writing and testing blocks is done with the CLI.
One more thing to know: each submission is a new pipeline in the cloud, so resubmitting the same pipeline does not reuse the cached results of an earlier submission.