Connect the Agent you already use to the team's remote MCP service. Give it a task in your normal conversation. The Agent reads shared work, claims an eligible task and keeps the project updated as it develops locally. Inspector is an optional view of the same project; signing in or claiming through a website is not a prerequisite.
This guide applies to the development Team service. It does not describe the published 0.5.0 personal MCP server.
Connect once
Get a project MCP URL and an individual credential from the project administrator, then clone the code repository. Each participant uses their own credential. Repository permissions remain separate from AWR permissions.
In Inspector, an authorized administrator can open Members, add a member, choose their project role and workstreams, then copy the one-time personal Agent connection instruction. The instruction includes the endpoint and that member's credential. Give it only to the intended member through a private channel. The administrator cannot retrieve its plaintext after clearing the issuance panel; a lost credential can be explicitly replaced.
Use any Agent client that supports remote MCP over Streamable HTTP with Bearer authentication. AWR does not select a default Agent or model. Add a remote MCP server using your client's settings:
| Setting | Value |
|---|---|
| Transport | Streamable HTTP |
| Server URL | The project endpoint, such as https://team.example/v1/projects/example/mcp |
| Authentication | Bearer token in the HTTP Authorization header |
| Credential | Your administrator-provided personal credential |
These are connection settings, not a universal configuration-file format or shell command. Each client has its own settings and version requirements. Use the client's supported secret settings or a trusted private Agent input; do not put the credential in a URL, shared conversation or repository. Reconnect after configuration changes and open your local code checkout in the Agent.
If a client supports only local stdio MCP, this URL cannot be used directly; use a version or integration that supports the remote transport and authentication.
Use the remote project as the shared work authority. A local checkout is for code and tests; do not initialize a second local task ledger to replace the remote project. Server database access is unnecessary.
Give the Agent the outcome
For example:
Use the connected AWR Team project to implement the issue API. Refresh the current tasks and resume my existing work, or claim an eligible task matching this request. Read the contract, dependencies and latest checkpoint before editing. Keep progress and evidence in AWR, submit the tested change as a PR, and request independent review.
The Agent handles coordination in the same conversation used for development. It should report an actual permission, dependency or ownership conflict when encountered. The user does not need to copy task IDs from Inspector or manually maintain progress in a browser.
Agent workflow
Use the discovered awr_team_query and awr_team_command tool schemas and the Team protocol reference for exact arguments. Each query/command rechecks the caller's current permissions.
| When | Agent action | Recheck when |
|---|---|---|
| Starting or reconnecting | Query capabilities to confirm identity and permissions, then work.next to resume your own sessions or discover visible unfinished work. Follow the returned next_query. On older servers without work.next, use workstreams.list and scoped work.list / work.search. | Progress, resolved waits, claim conflicts, identity, project, scope or ownership changes. |
| Preparing a selected task | Consume work.prepare: current contract, required specifications, dependencies, recovery state and context hash. Resume only an active session owned by the current actor and client; otherwise use session.start when appropriate. | Contract, dependency or source changes; incomplete context. |
| Claiming execution work | Inspect existing claims with claim.inspect. Acquire or renew a live claim under the session using fresh preconditions. Another person's live claim must not be replaced. | Conflict, stale version, lease expiry or revocation. |
| Beginning effects | Use execution.prepare and a fresh execution.start response with execution_authorized=true for one execution within the declared scope. The Agent's host runs code and tools locally. A claim alone is not execution admission. | Permission, lease, scope or execution state changes. |
| Reporting progress | Use session.checkpoint with consumed context hash, next action, open loops and a short progress summary. Batch updates when a phase/test completes, a blocker changes, user input is needed, or delivery is ready. Declare known client_info at session start or the next checkpoint. | Material work changes; client/model/capability changes. |
| Finishing execution or stopping | Use execution.report only for a terminal outcome, then follow inspection/reconciliation. Attach version-bound evidence. Release claims and end sessions after active work and unknown outcomes are settled. | Interruption, handoff, unknown effects or changed context. |
| Delivering | Submit evidence and request review through delivery.submit_and_request_review or review.open. An authorized independent person reviews; authorized finalization follows acceptance policy. | PR head, contract or artifact changes; returned review. |
work.prepare and work.observe return one short guidance item with its condition (when), factual basis (because), next action and reevaluation trigger (recheck_on). It does not grant execution rights. Recovery and registered deliveries take precedence over old checkpoint instructions. Small context budgets may omit this optional advice while preserving the required context; query work.observe for it when needed.
Use the feedback contract when advertised in capabilities. Batch reports with checkpoints, not every tool call or page refresh. Lease renewal is separate: use host scheduling if available and renew before expiry without creating extra reasoning turns. AWR cannot wake an idle Agent. A blocked/waiting phase describes a report; it does not create a wait item or renew a claim. Submit usage only from host data with known scope/source; an unsupported host leaves it absent. Checkpoint summaries are shared with authorized work readers; keep raw sensitive logs out of them.
Persist a stable request ID and exact command envelope before a write. After a timeout, inspect the original command.inspect result before an exact retry. Replayed receipts are historical facts, not permission to run effects again. Unknown execution effects require inspection and authorized reconciliation; creating a new session does not bypass that requirement.
Reconnecting MCP does not end a durable work session or renew its lease. A second Agent belonging to the same person is not an independent reviewer. Keep implementation, verification, GitHub merge and AWR acceptance as separate facts.
Optional workspace view
Open Inspector to inspect task relationships, ownership, progress and recorded results. Connect Agent provides client-neutral MCP settings and a project instruction; each task also has an optional copyable brief. Copying either text creates no session or claim. Administrator and review permissions are still enforced by the central service, regardless of which client is used.
Administrators can manage members and project-scoped credentials in Members. Activity separates authenticated access records from committed development history. Ordinary members see their own authorized activity; project auditors can filter by member or task. Audit records exclude credential values, conversations and arbitrary tool input/output. Request metadata has bounded retention and is not a permanent compliance archive. The connected Agent still performs task coordination; AWR does not launch or wake arbitrary Agent applications.
