# Model Context Protocol (MCP)

**MCP** is an **open standard** for connecting AI agents to **tools and data**. Instead of every assistant shipping a bespoke plugin format, MCP describes how a client (your IDE agent or CLI agent) talks to a **server** that advertises **tools** (things the model can invoke) and **resources** (things the model can read). Responses are structured—often **JSON**—so both humans and automation can rely on them.

At a high level: the model proposes an action, the runtime calls the server, the server returns grounded facts or side effects you allow, and the model continues with real context. That is the same architectural instinct behind good internal APIs, but framed for agent runtimes.

## How Dailybot fits as an MCP-oriented integration

Dailybot is **team orchestration and visibility**: check-ins, standups, agent reporting, and the **agent inbox** where people queue instructions for coding agents. In MCP terms, the valuable picture is that Dailybot acts as a **controlled surface** for **organizational context**—who is blocked, what was reported, what humans asked agents to do next—not as a replacement for your source control or CI system.

When Dailybot is reachable from an **MCP-compatible client**, agents can:

- **Report progress** after meaningful work (aligned with your reporting rules), so timelines stay human-readable.
- **Pull signals** about **team status** and **check-in-derived context** where your workspace configuration allows it—so an agent can ask operational questions before rewriting a large area of code.
- **Participate in two-way flows**: outbound updates from the agent, inbound instructions from people through the same orchestration layer you already use in chat.

## Prerequisites

Before you integrate:

1. **MCP-capable client** — A runtime that can attach MCP servers (for example **Cursor**, **Claude Code**, or another supported environment).
2. **Dailybot workspace access** — Your org’s Dailybot account, with permissions appropriate for reading team context and sending agent updates.
3. **Authentication** — Typically **`dailybot login`** for interactive setups or **`DAILYBOT_API_KEY`** for automation; follow your security team’s policy for secrets in agent environments.
4. **Agent identity** — Where your setup uses named agents, align **CLI `--name`**, API identities, and MCP configuration so reports and inbox items route to the correct actor.

If something fails silently, check auth first, then project or org scoping—most issues are identity mismatch, not MCP syntax.

## Step-by-step setup (conceptual)

Every client labels steps differently, but the sequence is usually:

1. **Install the Dailybot CLI** (or ensure your environment already has it) and complete **login** or **API key** configuration.
2. **Register or select the MCP server entry** for Dailybot in your client’s MCP settings—often a JSON block or a marketplace entry when Dailybot is **listed in MCP registries** for discoverability.
3. **Confirm permissions** in Dailybot so the connected identity may read the resources you expect and send agent updates where needed.
4. **Smoke-test**: ask the agent to perform a **read-only** operation (for example summarizing recent team status) before enabling any write-style tools in automated workflows.
5. **Encode guardrails** in your repo—rules, skills, or prompts—that tell agents **when** to call Dailybot (after substantial work, on schedule, or when explicitly asked), so the feed stays high-signal.

Keep secrets out of prompts; use environment variables and your client’s secret store.

## Tools and resources you should expect

Implementation details change by release, but categories usually include:

- **Reporting tools** — Submit standup-style updates with optional structured fields (completed items, blockers, metadata like model and branch).
- **Read resources** — Curated views of **team status**, **check-in summaries**, or **inbox-style context** so the agent can align with what humans already see in Dailybot.
- **Discovery** — MCP’s list-tools / list-resources pattern so the model only invokes capabilities that exist for your workspace.

Always review **what a tool can write** versus **read** before enabling it in unattended automation.

## Example use cases

**Before starting a large refactor**, an agent queries **team status** via MCP-backed resources: open blockers, yesterday’s priorities, and inbox notes from a tech lead. The agent’s plan references real constraints instead of inventing them.

**After completing a milestone**, the same agent sends a **progress report** through the reporting path your org standardized (CLI wrapper or direct call), with **`--milestone`** and structured **JSON** for deliverables—so leadership sees outcome-oriented text, not file paths.

**When the codebase context looks stuck**, the agent checks for **human instructions** queued in Dailybot (inbox flows) and adjusts its next steps, reducing thrash between terminal and chat.

## Security and governance

MCP does not remove policy—it **concentrates** it. Limit which servers agents may attach in production repos, rotate **API keys**, and audit which identities can post to shared timelines. Prefer **least privilege**: read-only MCP resources for exploratory agents, reporting tools only where the agent is a trusted actor.

Used deliberately, **Dailybot plus MCP** makes agent work **legible** to the same people who already run standups and escalations— **one orchestration story** instead of a separate AI shadow channel.

## FAQ

**What is MCP in one sentence?**  MCP (Model Context Protocol) is an open standard that lets AI clients discover and call tools and resources on a server—so agents can use real data and actions instead of guessing.

**What does Dailybot offer through MCP-style integration?**  Dailybot surfaces team-oriented capabilities such as agent progress reporting, access to check-in and status context, and hooks that let an agent reason about blockers and team state before or after coding work—always within your org’s permissions.

**What do I need before connecting an MCP client to Dailybot?**  An MCP-compatible agent runtime (for example Cursor or Claude Code), a Dailybot workspace with agent identities enabled where applicable, and authentication (CLI login or API key) so the client can call Dailybot on behalf of the right project or agent label.