Working with AI agents

How AI coding agents work in Quasar 2026.10.15: - connecting an agent over MCP or the REST API with a personal or service-account key, including Claude Code and Codex setup; - what agents can do through about 120 workflow-oriented tools; - how Quasar keeps agents safe and accountable: same permissions as their person, read-only keys enforced by the database, safe retries, explanatory refusals, an "agent" mark on everything they do; - how a person stays in control: agents record their plan before coding, their time is measured but confirmed by a person, and the agent contract reserves acceptance of documents to a person's word; - the separate, unauthenticated MCP server of public guides, and how to connect this guide to Claude Code, Codex, VS Code, Cursor, Claude and ChatGPT (or read it with no setup from llms-full.txt). Read this to evaluate Quasar for agent-driven development, or to give your assistant this guide.

Quasar is designed for coding agents to work a project alongside people. This chapter describes version 2026.10.15.

Two ways in, one set of rules

  • MCP. Coding agents such as Claude Code, Codex and opencode connect to Quasar's MCP server at /api/mcp (Streamable HTTP).
  • REST. Scripts and integrations use the REST API under /api/v1.

Both call the same services as the web app. An agent's change goes through exactly the same checks as a person's: the workflow, the permissions and the validation.

Connecting an agent

  1. In Profile → API keys, create a key. It starts with qsk_ and is shown once.
  2. Give it to the agent as a bearer token: Authorization: Bearer qsk_…. Each client has its own configuration format. The in-app Help Center shows the exact lines for Claude Code, Codex, opencode and pi.
  3. The agent now acts as you, with your permissions, no more.

Key options:

  • Expiry. Keys expire after 90 days by default and can be revoked at any time; a revoked key stops working immediately.
  • Read-only keys. A key can be created read-only. A read-only key is only offered the read tools, and the database itself refuses any write made with it.
  • Service accounts. For CI and integrations, a service account holds its own keys and its own permissions. It can never be an organization administrator.

What an agent can do

The MCP server offers about 120 tools. They are workflow-oriented: one call does what a person does in one step, rather than exposing raw tables. They cover:

  • Work: issues and all their content (sections, comments, relations, checklists, attachments), projects, sprints and boards, work logs and the project inbox.
  • Documents: documents and their review, documentation releases (composing, accepting, publishing), the asset library and artifacts.
  • Commercial: client quotes.
  • Delivery: versions, git status, pipeline results and changelogs, and deadlines.

Built to be used by a model:

  • Onboarding. A new agent calls get_started first and receives the project's rules and the workflow it must follow.
  • Long-form help. Each tool's detailed help is available on demand (describe_tool), so the tool list stays small.
  • Small models. The tool surface can be narrowed for them.
  • Every refusal is actionable. It names the argument or the rule that failed, lists the accepted values, and reports every problem at once.
  • Bounded reads. Read tools never return unbounded payloads unasked: long texts are withheld until explicitly requested.

Safe by construction

  • Retries never duplicate.
    • Every write accepts an idempotency key, and a repeated create replays the first answer.
    • Every entity carries a version, and a write against an outdated version is refused rather than overwriting someone's change.
  • Same permissions as the person. An agent cannot see a project its person cannot see. A project it has no access to does not appear to exist.
  • Everything is attributed.
    • Each change is recorded under the person whose key made it.
    • Quasar separately notes that an agent produced it, and the web app shows an Agent badge.
    • Nobody has to declare this: it comes from the key.
  • Rate limits. Each key has generous limits, so a runaway loop slows down instead of degrading the service.

A person stays in control

Quasar's own workflow, which an organization can adopt and adapt, encodes how an agent should work:

  • Plan before coding. Before an issue can move to In progress, the agent records a pre-analysis: the plan, and the files it examined with their checksums. If those files change before the work starts, the plan shows as stale.
  • Status tells the truth. The issue moves to In progress before the first edit, so whoever supervises sees where the work is.
  • Time is measured, then confirmed. The agent opens a work session at the start of each turn and closes it at the end. Quasar's own clock stamps both. A session becomes a work log only when a person confirms it.
  • Acceptance is a person's. The agent contract tells an agent to accept a document or a release revision only on a person's explicit word. Every acceptance records whose key made it and whether an agent acted. To keep an agent from accepting at all, give it a key whose owner is not a project lead.
  • The code is followed, not trusted. Quasar reads where each issue's code actually is in the repository, from the issue key in commit subjects, instead of taking the agent's word for it.

The agent contract

The rules Quasar gives an agent are versioned. When something an agent may have written down becomes wrong, the version changes, and Quasar tells a connecting agent what changed since its version. A repository can keep a copy of the contract, which agents read at the start of every session.

Public guides for any agent

Documentation an organization publishes, including this guide, can be read by agents without any key:

  • {guide}/llms.txt lists every chapter with its summary.
  • {guide}/llms-full.txt is the whole publication in one plain-text file.
  • {guide}/api/v1 is a read-only REST API, with an OpenAPI description at {guide}/openapi.json that can be imported as a ChatGPT Action.
  • {guide}/mcp is a separate, read-only MCP server with the tools index, read, search and fetch. search and fetch follow the shape ChatGPT connectors and deep research expect.

The public MCP server shares nothing with the operational one: it has no access to any project, only to what was published. The intended use: read the chapter summaries, choose what is relevant, read those chapters whole, and cite their pages.

Connecting this guide to your assistant

Nothing to set up. A chat assistant that can browse, such as ChatGPT or Claude, reads this guide from https://guide.quasar.nuzzodevstudio.com/llms-full.txt when you give it that address. Connecting the MCP server adds no content. It lets the assistant search and read chapter by chapter instead of loading everything at once.

The server's address is https://guide.quasar.nuzzodevstudio.com/mcp. It is a remote Streamable HTTP server that needs no sign-in. Each client below names it quasar-guide; any name works.

The steps were checked against each client's own documentation on 23 October 2026. Menus and plan limits change, so if a step no longer matches, your client's documentation is the authority.

Claude Code

claude mcp add --transport http quasar-guide https://guide.quasar.nuzzodevstudio.com/mcp

Add --scope user to have it in every project. claude mcp get quasar-guide should then show Connected.

Codex CLI

codex mcp add quasar-guide --url https://guide.quasar.nuzzodevstudio.com/mcp

Or, in ~/.codex/config.toml:

[mcp_servers.quasar-guide]
url = "https://guide.quasar.nuzzodevstudio.com/mcp"

VS Code

Run:

code --add-mcp '{"name":"quasar-guide","type":"http","url":"https://guide.quasar.nuzzodevstudio.com/mcp"}'

Or open this install link in a browser, and VS Code opens with the server filled in:

vscode:mcp/install?%7B%22name%22%3A%22quasar-guide%22%2C%22type%22%3A%22http%22%2C%22url%22%3A%22https%3A%2F%2Fguide.quasar.nuzzodevstudio.com%2Fmcp%22%7D

Cursor

Open this install link in a browser:

cursor://anysphere.cursor-deeplink/mcp/install?name=quasar-guide&config=eyJ1cmwiOiJodHRwczovL2d1aWRlLnF1YXNhci5udXp6b2RldnN0dWRpby5jb20vbWNwIn0=

Or add it to ~/.cursor/mcp.json:

{ "mcpServers": { "quasar-guide": { "url": "https://guide.quasar.nuzzodevstudio.com/mcp" } } }

Claude (claude.ai and Claude Desktop)

  1. Open Customize → Connectors, choose + Add, then Add custom connector.
  2. Enter a name and the server address, and choose No sign in under authentication.
  3. Turn the connector on in a conversation.

Every plan can add custom connectors; the Free plan allows one. On Team and Enterprise, an owner adds the connector first in Organization settings → Connectors, and members then connect it.

ChatGPT

In Plugins, choose +, then Add custom MCP server. Enter a name, a description and the server address, and choose No authentication.

Adding a custom MCP server depends on the plan and the workspace's permissions, and OpenAI changes it often. On Business, Enterprise and Edu, an administrator decides who can create one. Where your plan does not allow it, give ChatGPT the llms-full.txt address above instead: it reads the same content.

For deep research, the server's search and fetch tools answer in the shape ChatGPT expects, and every result carries the address of its page.