Skip to main content

​
Set up in the browser

  1. Open app.factorize.sh/auth/signup. Sign up with email and password (12–200 characters), verify the email, then sign in. Use resend verification if needed.
  2. Open Settings → Integrations. Add an exe.dev account token, test credentials, select the execution agent and VM tags, then save. Saving validates the agent/models on a temporary VM. Alternatively connect an Amp project and its access token.
  3. Ensure the execution account can access your repository and the required model/integrations. For exe.dev, the account token must permit VM listing, creation, SSH and deletion (ls, new, ssh, rm). VM tags attach your execution integrations. Current exe.dev targets do not store a repository URL or checkout ref: put the repository URL and checkout instructions in the job prompt.
  4. Connect your MCP client, approve the four workflow scopes, and ask “List my Factorize jobs.”
These account, credential and consent steps happen in the browser. MCP can discover saved targets, manage jobs and invoke/inspect runs; it cannot sign you up, verify email, connect execution credentials or select provider resources.

​
Ask your agent

Copy this request and replace the repository URL:
Show me my available execution integrations. Create a manual job called ‘Review recent changes’ using my repository’s target. Have it clone https://github.com/YOUR_ORG/YOUR_REPO.git, review the latest commit and summarize any problems. Run it once and report the result.
If several targets are available, choose one by its agent/account metadata. Target discovery does not imply a repository binding. Expected tools:
  1. list_execution_configs({}): choose a returned id; never invent one. Empty results mean browser execution setup is incomplete.
  2. list_jobs({}): check whether this job already exists before creating it.
  3. create_job with the input below. Save its returned id as JOB_ID.
  4. invoke_job with JOB_ID and a stable key. Save runId.
  5. get_run({runId: RUN_ID}): check periodically until terminal; inspect prompt, context and activity. Current MCP does not expose execution output: open the returned run in the browser trace view to read the review, or use authorized REST trace pagination. The agent should report the observed state and result link rather than invent findings.
Invoke input:
Example invocation result (identifiers are illustrative):
Success means target discovery returned a usable target, the created job returned an id and manual trigger with a stable slug, invocation returned runId, and get_run reports succeeded with the rendered repository prompt. Open its browser trace and confirm the review output; state alone does not prove the review findings. Submission alone is not completion. You can also open https://app.factorize.sh/job-runs/RUN_ID to inspect it. If the request times out, repeat the invocation with the same key, not job creation; it returns the original run with duplicate: true. A failed run is still the original run for that key. Follow failed-run troubleshooting before requesting a new run with a new key. After a successful manual review, add a schedule.