MCP overview
WeHarness provides a remote server for the Model Context Protocol (MCP). MCP is how coding tools call outside services. Once connected, your coding tool uses WeHarness on its own whenever the work touches your agent: it asks for guidance, lets WeHarness decide open choices, proposes plans, builds them, reads your traces and evaluations, and has WeHarness verify the result.
| Address | https://mcp.weharness.io/mcp |
| Transport | Streamable HTTP |
| Sign-in | OAuth 2.1 with PKCE, in your browser (details) |
| Server Card | https://mcp.weharness.io/.well-known/mcp/server-card.json |
Connect your coding tool
Section titled “Connect your coding tool”Open Connect MCP in the sidebar of the WeHarness app. It shows the address, the steps for your tool, and the tools you have connected. The same steps are here:
- Claude Code
- Codex
- Cursor
- VS Code
- Devin (Devin Desktop, the Devin CLI and the Devin web app)
- Other MCP clients: OpenCode, Hermes, OpenClaw and any client that supports remote servers with OAuth
- Claude on the web and ChatGPT: not enabled yet
After you sign in, ask your tool: “List my WeHarness workspaces.” It appears in Connect MCP as soon as it connects.
The rules your tool works under
Section titled “The rules your tool works under”- Your role, nothing more. Your tool sees only the workspaces you belong to, and your role decides what it can do: a viewer’s tool reads, a member’s tool also writes what a member may (for example an alert rule or a test set). A workspace you are not a member of is reported as not found.
- The model never approves. Plans, environments, scenario cases and file transfers are decided by you inside your coding tool: in WeHarness’s own views (buttons the model cannot press) or your tool’s own confirmation prompt, with the web app as the fallback. Pushes, repository creation, lessons, memory held for review and budget increases are decided in the signed-in web app. No tool lets the model approve.
approvals_getlists what waits for you, with exactly what would be decided and the page to decide it at (decide_in). Deleting anything also stays in the web app. - A session for what you approve. When your tool starts a plan or proposes commands, WeHarness opens a session for it in the app. That is where you can follow what your tool asked for, and decide when your tool cannot show WeHarness’s views. Tools return the session’s link as
approve_in. - Repository text is data. Results that carry repository, document, trace or catalog text are labelled untrusted. Text that asks an AI to approve or change something is treated as ordinary content.
- Nothing runs on your machine. WeHarness never runs code on your machine. Its checks run in isolated cloud sandboxes.
- Credits as in the app. Tools that start billable work (plans, decisions, evaluation runs) use the workspace’s credits and are refused at zero (
OUT_OF_CREDITS). No tool raises a budget. See Credits and usage. - Any language. Describe the task in your own words. WeHarness’s tool descriptions are in English; replies follow your language.
What your coding tool can do
Section titled “What your coding tool can do”Everything a page of the app shows is available to your tool, within your role.
| Area | Tools |
|---|---|
| Guidance and decisions | guidance, decide, decision_get, catalog_areas, catalog_search, catalog_get |
| Projects, context and plans | project_connect_local, project_review_get, project_inspect, project_create, context_transfer_request, context_upload, context_search, context_read, code_refs, plan_propose, plan_get, plan_answer, plan_choose_option, plan_validate |
| Tasks | task_get, task_next, task_claim, task_heartbeat, task_report, task_report_get, task_release, environment_propose |
| Applications | applications_list, application_get, application_create, application_link_session |
| Tracing | tracing_setup, traces_search, trace_get, trace_code, releases_get, online_evaluators_get, automations_get, automation_propose |
| Monitoring | monitoring_get, alert_create, alert_update |
| Evaluations | evals_get, eval_case_propose, eval_runner_propose, eval_run_start, eval_run_get, eval_runs_list, evaluators_get, evaluator_create, eval_set_create, eval_review_get, agent_optimization_get |
| Lessons and memory | lessons_get, lessons_list, lesson_propose, memory_recall, memory_list |
| Workspace | sessions_list, session_get, session_pr_get, files_list, github_get, connected_hosts_get, usage_get, approvals_get, run_start, run_status |
Every tool, with its parameters, and the prompts (WeHarness’s slash commands) are in the Tools and prompts reference.
Your local project
Section titled “Your local project”When you ask your coding tool to use WeHarness on the folder it has open (“review this with WeHarness”, in any language), it calls project_connect_local:
- WeHarness finds your project for that folder, by its git remote or by the folder’s name and a hash of its path (the path itself is never stored), or makes one.
- Your tool requests an exact file scope with
context_transfer_request. You review the paths, purpose, host and size limit in Connect MCP → Local file sharing. It then uses the approvedtransfer_idwithcontext_upload. The same scope can be reused until its 24-hour expiry; no repeated approval is needed within it. At most 600 files and 4 MB, including kept files. - It tells you in one line what it sent, and reviews the code with
project_review_get.
Connecting a project is not authorization to send its files. Without a file grant, the tool can use guidance with a non-sensitive brief or plan a new project. Sharing never authorizes cloud execution. Your tool never sends .env files, private keys, credential and secret files, generated or vendored folders (.git/, node_modules/, dist/ and the like), binaries, or files over 1 MB, and WeHarness’s intake leaves out secrets and generated files by name and content whatever a tool sends. For a large repository, connect GitHub in the app instead. See Project context.
Two ways to start
Section titled “Two ways to start”You know what you want. Name the package or framework. Your tool calls guidance with it, follows the entries within your choice, and calls guidance again for each new part, such as tracing or evaluations. If an entry warns against your choice, your tool says so.
You describe the problem. Say what your agent should do, in your own words. For one open choice, your tool calls decide. For a whole feature, it connects the project, proposes how the repository is checked (environment_propose) and calls plan_propose. WeHarness’s decision engine, Elephant-1, chooses among the options inside the plan. You approve the plan in the project’s session, and your tool builds it as a task. See Working on an approved plan.
Views in your coding tool
Section titled “Views in your coding tool”Coding tools that support MCP Apps show some results as WeHarness views inside the conversation: a plan, a task, a pull request, a trace, recent traces, Monitoring, an evaluation run, an application, a catalog entry and more. Tools that do not support them get the same results as text. A view never approves anything. See Views.
Compatibility
Section titled “Compatibility”| Coding tool | Status |
|---|---|
| Claude Code, Codex, Cursor, VS Code, Devin, OpenCode, Hermes, OpenClaw | Setup steps from each tool’s own documentation. WeHarness has tested the protocol path (discovery, registration, PKCE sign-in, a token for MCP only, refresh and disconnect) with a scripted MCP client, not yet with each tool end to end. Each is listed as verified only after a clean connect, use and disconnect. |
| Claude on the web and ChatGPT | Not enabled yet. See Claude web and ChatGPT. |
| Views (MCP Apps) | Shown by tools that support the extension; not verified per tool yet. |
If a step differs for you, write to info@weharness.io.
Errors
Section titled “Errors”A refused call says why, with a code first and the request’s id last, for example NOT_FOUND: Project not found. (request req_…). Quote the id when you write to us; the web app and the REST API name the same id (request_id in the error, and the X-Request-Id header). See MCP troubleshooting.
Server Card
Section titled “Server Card”https://mcp.weharness.io/.well-known/mcp/server-card.json describes the server for tools and agents that look for it: the address, the transport, how sign-in works and the current tools. It is generated from the server itself, so it lists exactly the tools the server offers. It claims no host compatibility.