StewAI
Discover, preview, estimate, run, and retrieve reusable AI workflows.
Community: Submitted by a user or imported; check the owner before granting accessOnlineNo sign-inGlobalFreeRead-only
What it can do
What data it sees
Do you need an account
No: the server works without sign-in
Discover, preview, estimate, run, and retrieve reusable AI workflows.
Server tool list (14)
Raw names from tools/list. Only developers need these.
| check_recipe_build | Run free deterministic lint, render, policy, and compiler checks. Omit fixtures for the normal structural check; a supplied fixture probe must also provide every referenced upstream dependency value. |
| commit_recipe_build | Preflight and privately publish only the exact fully qualified recipe revision. |
| discover_stewai | Learn how any MCP agent can authenticate, discover, preview, run, author, qualify, commit, inspect, and recover StewAI recipes. Call this first. |
| get_recipe_build | List or inspect only the authenticated creator's private recipe builds. To list builds omit both build_ref and view; limit/cursor paginate that list. With or without build_ref, use view='authoring_schema' and schema_name='update_recipe_build', 'acceptance_suite', or 'start_recipe_build' to read the complete executable JSON Schema when a client hides nested operation or assertion fields. Large acceptance_plan reads return data.suite_page JSON fragments: append content in offset order, pass data.next_cursor as cursor until null, then parse the complete suite and verify its sha256. Small plans retain data.suite. Use view='capabilities' to discover the complete 24-handler authoring and automatic-acceptance capability catalog. |
| get_recipe_build_activity | Poll a review or acceptance batch through a bounded, disclosure-safe view. |
| get_recipe_preview | Inspect a safe summary with bounded method and limitations excerpts, output-contract state, and evidence context. For complete authorized published details and executable contracts, use view=details. Concatenate content fragments in offset order per section; decode JSON sections after completion. Use next_cursor with the same recipe_ref until null. Opaque internals remain withheld. |
| get_results | Read declared outputs or a sanitized per-step trace from an owned run, including signed chunks for oversized steps. view=steps returns compact summaries, 10 per page by default and at most 20 (limit 1-20); follow next_cursor until it is null, pass detail=full for whole steps, or use view=step with step_id for one full step. Step reads are provisional until get_run reports a finished status. If outputs is empty, read view=steps; for a failed run, read the failed step and let the user decide. |
| get_run | Read an owned run, view=history to resume normal runs (recipe_ref/status/cursor/limit), or view=diagnostics for its settled UI receipt. Default status requires run_id and includes live progress: updated_at is the run record time, progress.last_step_activity_at is the latest step activity. A blocked run paused for credits reports credit_pause. |
| review_recipe_build | Quote or run a bounded semantic quality review of the exact private draft revision. |
| run_recipe | Estimate or run a previewed public or account-authorized published recipe. dry_run returns history (credits charged by past runs of this recipe), fees, your balance, and estimated_credits, a theoretical worst case. If credits run out during a run, it pauses and can be resumed after adding credits. On recipe_ref_expired, search or preview again and retry. |
| run_recipe_acceptance | Quote or run selected or complete behavioral acceptance cases for an exact private draft revision. Quotes explain enforced input bounds, output caps and retry allowances in acceptance_cost. Preserve representative fixtures and assertions; remove unnecessary model stages rather than weakening tests to lower a quote. Paid work requires an approved budget. A full run that needs user approval returns supervised_required before any case, reservation, or external effect; first bind every returned required resource with update_recipe_build bind_resource, then open action_url for user approval, and finally resume the same activity with update_recipe_build resume_activity. |
| search_recipes | Find safe public recipes and published recipes available to the current account. results are direct fits (exact or strong); related_results are adjacent recipes, not direct fits. Each row states its output contract, past-run cost history and, for reviewed public recipes, that safety review is not output-quality validation. required_inputs and required_outputs match exact handles or normalized labels, never meanings. When paging.has_more is true, repeat the identical call with cursor=next_cursor. |
| start_recipe_build | Create a private recipe build from a bounded intent and declared contract. Recipe inputs are strings: use type:string, positive maxLength, and only minLength:1 on required inputs. Richer input constraints must be handled in recipe logic and tested, not claimed as enforced by the input node. The response returns the stored contracts when they fit the bounded result; the archetype bundle is optional guidance, not the build contract. Optionally provide source_recipe_ref to adapt an owned recipe or a fully viewable public-open recipe into a new private draft. |
| update_recipe_build | Apply bounded optimistic changes to an owned private recipe build. If ops appear as unknown, first read get_recipe_build view='authoring_schema', schema_name='update_recipe_build'; read schema_name='acceptance_suite' for all behavioral assertion operators and fields. Do not guess them. Use set_contracts to replace the declared executable input and output contracts; this changes the revision and invalidates qualification. For a supervised acceptance handoff, use bind_resource only to approve an exact selector already frozen in the draft, then resume_activity or cancel_activity with the returned opaque handoff and activity references. Each handoff control operation must be the only op in its request. Use only the exact op names and payload keys in inputSchema: set_metadata takes metadata, upsert_schema takes schema_id and schema, and acceptance uses set_acceptance_cases with suite. Never invent set_schema or set_acceptance_suite. An acceptance suite is {version:1,cases:[{case_id,label,kind,fixtures,assertions}]}. Each fixture is {target,content_type,value}. A minimal assertion is {assertion_id:'result_exists',type:'scalar',operator:'exists',path:'/result'}. JSON Pointer paths start with '/'. A metamorphic case also requires pair_with naming another case. Use a paired assertion such as {assertion_id:'stable',type:'paired',operator:'fields_unchanged',path:'',pair_case_id:'base',fields:['/summary']}; pair_case_id is not valid on a scalar assertion. Client transport recommendation, not a server limit: keep serialized tool arguments below 32 KiB including JSON escaping and the request envelope. For larger spec, suite, or research content use begin_chunk, ordered append_chunk (seq starts at 0), then commit_chunk. Keep each complete append request below 12 KiB; split text further after measuring escaped JSON bytes. Hash the exact assembled UTF-8 text with SHA-256. Begin/append do not change the revision; commit changes it once. After an uncertain response, inspect the build |