seyal
Seyal doesn't replace Claude Code or Codex. It gives them tasks with clear criteria, and holds their work to the same check as anyone's.
Use your installation’s HTTPS address with /mcp. The transport is Streamable HTTP. In Settings → Connections, use Connect a device to create a separate token for each connection, limited to the projects you choose. It is shown once and expires after 90 days unless you pick another term. Owners can also create agent tokens and tokens for every project in Settings → MCP & access, and give each one only the tools it needs.
Set SEYAL_URL to your endpoint and SEYAL_TOKEN to the token in your local shell. The URL below is an example: replace it with your own installation.
export SEYAL_URL=https://seyal.example.com/mcp
# Set SEYAL_TOKEN privately in your shell.
claude mcp add --transport http seyal "$SEYAL_URL" \
--header "Authorization: Bearer $SEYAL_TOKEN"Build your checkout with pnpm build. Add this to your local Codex TOML configuration, replacing the bridge path. The OpenAI Codex MCP guide documents this configuration. Start Codex with SEYAL_URL and SEYAL_TOKEN set in its environment; the bridge reads them directly.
[mcp_servers.seyal]
command = "node"
args = ["/absolute/path/to/seyal/apps/server/dist/seyal-mcp.js"]
env_vars = ["SEYAL_URL", "SEYAL_TOKEN"]For HTTP, use your endpoint and a bearer token. For a client that supports stdio, run the same bridge with Node and pass both environment variables. The bridge requires an explicit endpoint; it chooses no server for you.
Transport: Streamable HTTP
Endpoint: https://seyal.example.com/mcp
Header: Authorization: Bearer <your-client-token>
# Alternative: stdio bridge, with SEYAL_URL and SEYAL_TOKEN set
node /absolute/path/to/seyal/apps/server/dist/seyal-mcp.jsThese tool names and arguments come from Seyal’s server. The calls below illustrate a task workflow; replace the task and PR URL with your own.
get_context({ project: "APP" })
get_task({ task: "APP-12" })
claim_task({ task: "APP-12" })
log_progress({ task: "APP-12", message: "Implementation ready for review" })
link_pr({ task: "APP-12", url: "https://github.com/example/app/pull/48" })
complete_task({ task: "APP-12" })Open the PR with your repository tools first. link_pr attaches it as evidence; it does not create or merge it. complete_task asks the completion check and reports missing requirements. See how approval works.
get_area_map, get_context, get_standards, list_projects, get_board, get_task, get_task_events, get_plan, search_tasks, my_focus, list_inbox, list_proposals, get_sensitive_rules, list_routines, recommend_skills, get_skill, get_feature_flags, get_project_settings, get_risk_report, repo_drift, list_cycles, get_burnup, list_releases, list_members, list_suggestions, get_analytics, list_reminders.
create_project, create_task, update_task, set_risk, move_task, claim_task, release_task, log_progress, link_tasks, link_pr, add_comment, add_criterion, tick_criterion, add_subtask, tick_subtask, attach_evidence, sync_from_repo, log_time, create_reminder, cancel_reminder, complete_task.
post_plan, report_step, move_stage, report_session. Plans, steps and stages show live on the task. They never change its status.
set_feature_flag, submit_audit, dispatch_claim, dispatch_update, dispatch_handoff, delete_task, delete_project. The two delete tools always refuse.
Access is scoped per client token. Revoke one connection without switching off the others.
Enabled tools let clients read context, search tasks, claim work, post a plan, report progress and link PR evidence. A claim is renewed by progress reports. A token limited to some projects sees and changes only those projects.
Seyal supplies no PR merge tool. Task and project deletion calls are refused, including when their tool flags are enabled. People review and merge in their repository.
Agents use the same completion check as the web app. Required evidence, ticked criteria and approval of the exact version still apply. External agents also have whatever repository permissions you separately grant.
A pull request that touches CI definitions, agent control files or other protected paths needs approval from a person with the owner role and checks Seyal can trust. Sensitive changes, such as migrations or permissions, always wait for a person.
Server-run helpers are separate from your coding client. Configure provider access, budgets and autonomy in your installation. The Routines screen lists each scheduled job and agent, with a pause switch and a daily cap.
Suggest a project, priority and labels for incoming work, or draft subtasks, criteria and an estimate. Suggestions can wait for review or apply under the configured autonomy.
Seyal picks reviewers from a task's risk and areas. Each reviewer checks the pull request against the criteria and files a verdict on the current task version. The repo auditor proposes task changes from the code; they wait for approval. Decision memos and release notes are drafts for people to review.
The daily brief gathers priorities and decisions waiting for you. Follow-up and risk watchers surface work that needs attention. Ask Seyal answers questions about the board. Once it has read board text, each change it proposes waits for you to confirm it.
Create reminders and let scheduled jobs notify you when they are due. Delivery depends on the channels you have configured. Review the data sent to providers.