Sign Up Sign In

MCP server reference

One hosted, multi-tenant MCP server exposes all four primitives to your agent. This page is the map — how to connect, how a session picks its Team, and which tools exist. Each tool's arguments live in the tool's own schema, which your agent reads on connect; they are not restated here.

Connect

The server is a single streamable HTTP endpoint, mounted at /mcp on the main host — for example https://aigears.example.com/mcp. Every buyer's agent connects to the same URL; there is no per-Team subdomain.

Unlike the HTTP API, MCP does not take a Bearer API key. The server authenticates the human operator over OAuth, with Dynamic Client Registration, so an OAuth-capable host registers itself and runs the login flow on first connect — nothing to paste. Point a client at the URL:

{
  "mcpServers": {
    "aigears": {
      "url": "https://aigears.example.com/mcp"
    }
  }
}

On first use the host opens the browser for you to sign in and consent; after that the session is authenticated. Sessions are stateful — the Team you select (below) is remembered for the life of the connection.

Session bootstrap

A REST API key is bound to exactly one Team, so REST never has to ask which Team you mean. An OAuth token is not: one operator can belong to several Teams, and the token is not pre-bound to any of them. So every session starts by choosing a Team:

  1. Call teams_list to see the Teams the signed-in operator belongs to.
  2. Call set_current_team with the one you want. That Team is now the session's working Team, and every following tool call reads and writes its state.

Until a Team is selected, the primitive tools have no Team to act on and fail with a no_team_selected error. A well-behaved agent runs this bootstrap once at the start of a session — the agent skill below packages that habit.

Tool inventory

Every tool the server exposes, grouped by primitive, one line each. Each tool's arguments and return shape are in the tool's own schema — read them there, not here. The names mirror the HTTP API operations one-to-one.

Session

  • teams_list — list the Teams the signed-in operator belongs to.
  • set_current_team — choose the session's working Team.

Schedules

  • schedule_create — register a one-off or recurring schedule.
  • schedule_list — list schedules.
  • schedule_get — fetch one schedule.
  • schedule_cancel — cancel a pending schedule.

Deadlines

  • deadline_remember — record a deadline with its escalation policy.
  • deadline_query — the cross-session recall: ask what is due.
  • deadline_list — list deadlines.
  • deadline_get — fetch one deadline.
  • deadline_complete — mark a deadline done, stopping escalation.
  • deadline_snooze — push a deadline out to a new time.
  • deadline_cancel — cancel a deadline.

Approvals

  • approval_request — open an approval gate and notify the approver.
  • approval_status — check whether a request is still pending or decided.
  • approval_list — list approval requests.
  • approval_cancel — withdraw a pending request.

Watches

  • watch_create — start watching a source for changes.
  • watch_list — list watches (optionally by status).
  • watch_history — read a watch's per-change event log.
  • watch_pause — pause polling (keeps config, stops billing).
  • watch_resume — resume a paused watch.
  • watch_delete — delete a watch.

Guiding your agent

The tool descriptions above are per-tool; they can't teach the cross-tool habits that make an agent effective — running the set_current_team bootstrap first, reaching for a deadline rather than a schedule when a task has a due date, passing an idempotency key on every retry. That knowledge lives in the agent skill, which you can add to a skill-aware host so your agent picks it up automatically.