crewlog
Provides tools for managing Linear issues, including retrieving tasks, searching, updating issue state, assigning priorities, adding comments, and creating new issues, as well as viewing team status.
Enables searching Slack messages and retrieving recent channel history, allowing agents to access team communication.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@crewlog what should I work on next?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
crewlog
Give every teammate's coding agent shared company context — and one append-only log of everything your crew (humans and agents) is doing.
crewlog is an MCP server for teams running agentic coding tools (Claude Code, OpenCode, Codex, or anything MCP-compatible). Each person's agent can see Linear tasks, Slack discussion, and a shared company activity log that merges Slack messages, Linear changes, call summaries (Granola webhooks), and coding sessions into one timeline. A daily coordinator — Claude on a cron — reads the log and writes a briefing that every agent surfaces before planning the day. Ask your agent "what should I do next?" or "what did I miss?" and it knows.
Modeled on Fleet AI's Code with Claude 2026 talk "Claude & the self-driving company": "Making company operations fully legible to Claude. Single append-only log of all unstructured activity (coding sessions, Slack, calls)" — and Claude guiding coordination on top of it.
Slack Events API ───┐ (signed webhooks)
Linear webhooks ────┤
Granola webhooks ───┼─► Convex HTTP actions ─► events table (append-only) ─┐
POST /ingest ───────┤ ▲ │
agents (log_work) ──┤ daily cron │ │
SessionEnd hook ────┘ Claude coordinator ─┘ (briefing → log, │
optional Slack) ▼
your team's agents ◄── crewlog MCP (stdio, per-user) ◄── whats_next / activity_log / search_log
│
└── live: Linear API (your key), Slack API (your token)The live tools answer "what's next / who's doing what" from the source-of-truth
APIs. The log answers "what happened across the company." Coding sessions land
in it two ways: automatically via the Claude Code SessionEnd hook
(scripts/log-session.ts), and explicitly via log_work (1-3 sentence
summaries agents append mid-flight, from any MCP client). Calls land via
Granola's webhooks. Anything else lands via the generic /ingest endpoint.
Open core
Everything in this repo is MIT. There are two ways to run the log backend, and the same code serves both:
Self-host — deploy your own Convex project (free tier covers a small team; Convex is open-source/self-hostable). Zero extra setup: one team per deployment, authenticated by the
CREWLOG_KEYenv var. See Self-hosting the backend.Use a hosted backend, free of charge — point
CREWLOG_CONVEX_URLat a shared multi-tenant deployment (e.g. the maintainer's — open an issue to get a team) and use the team key you're given. Your webhook URLs get a/t/<team>/prefix; everything else is identical. Note the trust tradeoff: the operator of a hosted backend can read your team's log and the integration secrets you configure — self-host when that's not acceptable.
Anyone can operate a shared backend for others — see Operating a shared backend.
Related MCP server: Malon
Tools
Tool | Source | What it does |
| Log + Linear | Latest coordinator briefing, then your in-progress issues, queue by priority, urgent unassigned work |
| Linear | Who is working on what right now, plus unassigned urgent/high |
| Linear | Full issue detail by identifier (ENG-123) incl. comments |
| Linear | Text search over issues |
| Linear (write) | Change state / assignee / priority |
| Linear (write) | Add a markdown comment |
| Linear (write) | Create an issue in a team |
| Slack | Search messages with your visibility ( |
| Slack | Recent messages from one channel |
| Log | Company-wide feed: Slack + Linear + calls + agent work, one timeline |
| Log | Full-text search over the log (incl. agent work summaries) |
| Log (write) | Append a 1-3 sentence work summary so other agents see it |
Slack is read-only by design. The log is append-only: nothing updates or deletes.
Auth model
Per-user Linear API key — "my tasks" resolves to the individual, and writes are attributed to the person whose agent made them.
Per-user Slack user token (xoxp) — enables real Slack search and respects each person's channel visibility. One shared Slack app; each teammate authorizes once via
pnpm run slack-auth.Team-shared log credentials — a Convex deployment URL and a shared secret (the
CREWLOG_KEYenv var when self-hosting; a per-team key, stored hashed, on a hosted backend).Server-side secrets (bot token, webhook secrets) live only in the Convex deployment — in its environment when self-hosting, in the team's row on a hosted backend — never in the repo or on laptops.
Two consequences worth knowing: all four client env vars are required even if
you only use the log tools (the log resolves your name via Linear so entries
are attributed consistently), and anyone holding the team key can append any
event to the log — including briefing-kind events that whats_next
surfaces — so treat the key like the shared secret it is. Nothing can ever
modify or delete a logged event. Vulnerability reports: see
SECURITY.md.
Self-hosting the backend (admin, ~20 minutes)
Clone and install:
git clone <your crewlog repo> && cd crewlog pnpm installDeploy the log backend (Convex; free tier covers a small team, and Convex is open-source/self-hostable):
npx convex deployIn the Convex dashboard, set env vars on the deployment:
SLACK_SIGNING_SECRET,SLACK_BOT_TOKEN(from step 3),LINEAR_WEBHOOK_SECRET(invent a strong random string), andCREWLOG_KEY(invent another). Note the deployment's two URLs:*.convex.cloud(client) and*.convex.site(HTTP actions).Slack app: create at api.slack.com/apps → "From a manifest" → paste
slack-app-manifest.yamlwith the request URL set tohttps://<deployment>.convex.site/slack/events. Install to workspace. Invite the bot to every channel that should be logged:/invite @crewlog. Bot membership is the logging opt-in.Linear webhook: Linear → Settings → API → Webhooks → new webhook with URL
https://<deployment>.convex.site/linear/webhook, secret =LINEAR_WEBHOOK_SECRET, event types: Issues + Comments.Calls via Granola (optional; needs a Granola Business/Enterprise plan for API access): in the Granola desktop app, Settings → Connectors → API keys → create a key (
grn_...). Register a webhook for new meeting notes:curl -X POST https://api.granola.ai/v1/webhook-endpoints \ -H "Authorization: Bearer grn_YOUR_KEY" -H "Content-Type: application/json" \ -d '{"url": "https://<deployment>.convex.site/granola/webhook", "scopes": ["public"], "events": ["note.generated"]}'The response contains a
signing_secret(whsec_...), shown only once. SetGRANOLA_WEBHOOK_SECRET(that secret) andGRANOLA_API_KEY(thegrn_key) on the Convex deployment. Each new meeting summary now lands in the log as acallevent. Other transcription tools can post to/ingestinstead (below).Daily coordinator (optional): set
ANTHROPIC_API_KEYon the Convex deployment. Every day at 13:00 UTC (editconvex/crons.tsto change), Claude reads the last 24h of the log and appends a briefing that every teammate'swhats_nextthen surfaces first. Optional extras:CREWLOG_BRIEFING_CHANNEL(a Slack channel id or#namethe bot is in — posts the briefing there; needs the manifest'schat:writescope) andCREWLOG_COORDINATOR_MODEL(defaults toclaude-opus-5; the request ships with a server-side fallback toclaude-opus-4-8in case the primary model declines — set the env var to a current model when these are eventually deprecated). To run without the coordinator, don't setANTHROPIC_API_KEYand delete the registration inconvex/crons.ts.Distribute via your secret manager:
CREWLOG_CONVEX_URL(the*.convex.cloudURL),CREWLOG_KEY, and the Slack app's Client ID + Secret.
Operating a shared backend (multi-tenant)
One deployment can host the log for many teams free of charge — this is how
the hosted option works. Teams are rows in the teams table, created and
configured by the operator with npx convex run (never over HTTP):
# Create a team: mints /t/acme/* webhook routes; the key is what the team's
# MCP clients authenticate with (only its sha256 hash is stored).
npx convex run teams:create '{"slug":"acme","name":"Acme","key":"'"$(openssl rand -hex 32)"'"}'
# Set the team's integration secrets (the team creates its own Slack app /
# Linear webhook / Granola key, using /t/acme/-prefixed request URLs, and
# hands the secrets to the operator):
npx convex run teams:configure '{"slug":"acme","slackSigningSecret":"...","slackBotToken":"xoxb-..."}'
npx convex run teams:configure '{"slug":"acme","linearWebhookSecret":"..."}'
npx convex run teams:configure '{"slug":"acme","granolaApiKey":"grn_...","granolaWebhookSecret":"whsec_..."}'
# Opt the team into the daily coordinator briefing (uses the deployment's
# ANTHROPIC_API_KEY) and optionally post it to their Slack:
npx convex run teams:configure '{"slug":"acme","coordinatorEnabled":true,"briefingChannel":"#standup"}'
# Rotate a team's key:
npx convex run teams:configure '{"slug":"acme","key":"'"$(openssl rand -hex 32)"'"}'The team then uses CREWLOG_CONVEX_URL = the shared deployment's
*.convex.cloud URL and CREWLOG_KEY = their team key. Webhook URLs are the
self-host ones with a /t/<slug> prefix, e.g.
https://<deployment>.convex.site/t/acme/slack/events. Events are scoped per
team everywhere (indexes and search included). Webhook ingestion is
idempotent — Slack and Granola deliveries dedupe on their event ids, Linear
on a hash of the delivery body — so retries never double-log. One operator
caveat: the log is append-only and never pruned, so storage grows with tenant
activity; a retention lever is deliberately out of scope for now.
Anything else → POST /ingest
Any other activity source (Zapier zaps, other call-transcription tools, cron scripts) can append to the log directly:
curl -X POST https://<deployment>.convex.site/ingest \
-H "Authorization: Bearer $CREWLOG_KEY" -H "Content-Type: application/json" \
-d '{"source": "call", "actor": "Fireflies", "kind": "meeting",
"ref": "Weekly sync", "text": "Discussed the Q3 roadmap...", "url": "https://..."}'source must be one of slack | linear | agent | call; ts (epoch ms) is
optional and defaults to now. Pass an optional external_id (any stable
string) to make retries idempotent — a second request with the same
external_id is a no-op.
Per-teammate setup (~5 minutes)
Clone crewlog (by convention, next to the repos you work in) and install:
git clone <your crewlog repo> && pnpm install --dir crewlogLinear key: linear.app → Settings → Security & access → API keys.
Slack token:
SLACK_CLIENT_ID=... SLACK_CLIENT_SECRET=... pnpm --dir crewlog run slack-authExport all four vars in
~/.zshrc(MCP clients expand${VAR}from the shell — they do not read.envfiles):export LINEAR_API_KEY=lin_api_... export SLACK_USER_TOKEN=xoxp-... export CREWLOG_CONVEX_URL=https://<deployment>.convex.cloud export CREWLOG_KEY=...Register the server in your client (below), restart it, and ask: "what should I do next?"
Automatic session logging (Claude Code): add a
SessionEndhook to the project repos you work in (commit.claude/settings.jsononce and the whole team gets it). When a session ends,scripts/log-session.tsdigests the transcript — first ask, follow-up/tool-call counts, outcome — and appends it to the log so every teammate's agent sees what was worked on:{ "hooks": { "SessionEnd": [ { "hooks": [ { "type": "command", "command": "pnpm --dir ../crewlog exec tsx scripts/log-session.ts" } ] } ] } }Adjust
../crewlogto where crewlog is cloned relative to the project. The hook inherits your shell env, so the same four exported vars cover it.
Client configuration
All examples assume crewlog is cloned at ../crewlog relative to your project
root — adjust the path to your layout. Commit these to your project repo once
and the whole team gets them.
Claude Code — .mcp.json at your project root:
{
"mcpServers": {
"crewlog": {
"command": "pnpm",
"args": ["--dir", "../crewlog", "exec", "tsx", "src/index.ts"],
"env": {
"LINEAR_API_KEY": "${LINEAR_API_KEY:-}",
"SLACK_USER_TOKEN": "${SLACK_USER_TOKEN:-}",
"CREWLOG_CONVEX_URL": "${CREWLOG_CONVEX_URL:-}",
"CREWLOG_KEY": "${CREWLOG_KEY:-}"
}
}
}
}OpenCode — opencode.json at your project root (local servers inherit your
shell env):
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"crewlog": {
"type": "local",
"command": ["pnpm", "--dir", "../crewlog", "exec", "tsx", "src/index.ts"],
"enabled": true
}
}
}Codex — ~/.codex/config.toml (Codex's config is global by default;
trusted projects may also use a project-scoped .codex/config.toml). Codex
does not expand ${VAR} in this file, so either rely on it inheriting your
shell env, or set the values explicitly in the server's env table:
[mcp_servers.crewlog]
command = "pnpm"
args = ["--dir", "/path/to/crewlog", "exec", "tsx", "src/index.ts"]
[mcp_servers.crewlog.env]
LINEAR_API_KEY = "lin_api_..."
SLACK_USER_TOKEN = "xoxp-..."
CREWLOG_CONVEX_URL = "https://<deployment>.convex.cloud"
CREWLOG_KEY = "..."Development
pnpm run typecheck # tsc over src/scripts/tests and convex/
pnpm test # vitest: format helpers, webhook mappers, crypto vectors
pnpm run inspect # MCP inspector UI
pnpm exec convex dev # local Convex backend (anonymous, no login needed)Webhook payload → log event mapping is pure (convex/mappers.ts) and covered
by fixture tests; signature verification lives in convex/lib.ts with
known-answer vectors. CI runs typecheck + tests on every PR and push to main.
This repo's own .mcp.json points at itself, so opening it in Claude Code
dogfoods the server. convex/_generated/ is committed so the package
typechecks without a Convex login; convex dev/codegen refreshes it after
schema changes.
License
MIT
Available Tools
12 toolsactivity_logA
The company-wide activity feed: Slack messages, Linear changes, call summaries, and teammates' agent work logs merged into one timeline. Call this when the user asks "what happened", "what did I miss", "what has the team been doing", or to catch up after time away. When both source and actor are set, fewer than limit rows may come back.
Inputs: actor, limit, since, source.
comment_on_issueA
Add a markdown comment to a Linear issue. Call this to record findings, decisions, or progress on an issue so the team sees it.
Inputs: body (required), identifier (required).
create_issueA
Create a new Linear issue. Call this when work is discovered that isn't tracked yet — a bug found while coding, a follow-up task, or something the user asks to capture.
Inputs: title (required), team_key (required), assignee, priority, +1 more.
get_issueA
Full detail for one Linear issue by identifier (e.g. REF-123): description, state, assignee, priority, and all comments. Call this before starting work on an issue or when the user references an issue id.
Inputs: identifier (required).
log_workA
Append a short work summary to the shared company activity log so every teammate's agent can see it. Call this after completing significant work, making a decision, or starting a task others should know about. Keep it to 1-3 sentences.
Inputs: text (required), ref.
search_linearA
Search Linear issues by text. Call this to find issues about a topic, feature, or bug when you don't have an identifier.
Inputs: query (required), limit.
search_logA
Full-text search over the company activity log — the one place that also contains teammates' agent work summaries. Call this to find who touched a topic, past decisions, or work that never made it into an issue.
Inputs: query (required), limit.
search_slackA
Search Slack messages with your visibility. Supports Slack query syntax: "in:#channel", "from:@name", quoted phrases. Call this to find past discussion, decisions, or context about a topic.
Inputs: query (required), limit.
slack_channel_historyA
Recent messages from one Slack channel, oldest first. Call this to catch up on a channel (e.g. #eng, #standup) or check the latest discussion before starting work.
Inputs: channel (required), limit.
team_statusA
Who on the team is working on what right now, from Linear. Call this when the user asks what the team is doing, whether someone is already on a task, or before picking up work that might overlap with a teammate.
Inputs: team_key.
update_issueA
Update a Linear issue's state, assignee, and/or priority. Call this when the user starts work (state → In Progress), finishes (state → Done/In Review), or asks to reassign or reprioritize. State is matched by name against the issue's team workflow.
Inputs: identifier (required), state, assignee, priority.
whats_nextA
What the current user should work on next. Call this when the user asks what to do, what's next, what their priorities are, or at the start of a work session. Shows the coordinator's daily briefing (company-wide priorities), then their in-progress issues, their queue by priority, and urgent unassigned work from Linear.
Inputs: no named parameters.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 12 tools
Each tool targets a distinct purpose: Linear issue operations, Slack queries, activity log actions, and coordination tools. No two tools overlap in functionality.
All tool names follow a consistent verb_noun snake_case pattern (e.g., get_issue, search_slack, log_work). Minor abbreviation in 'whats_next' is acceptable.
12 tools is well within the ideal range and covers all necessary actions for team coordination without being excessive.
The tool set covers core workflows: issue lifecycle, Slack context, activity logging, and status queries. Minor omissions like issue deletion or Slack messaging are acceptable given the domain scope.
Related MCP Connectors
Team memory for AI coding agents and code reviews, reviewed by humans and served over MCP.
shared AI-context layer for teams — persistent memory your agents search and update over MCP
One shared context your team's AI tools read & write over MCP. No re-explaining. Free.
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
Related MCP Servers
- AlicenseAqualityDmaintenanceMCP server that provides a shared semantic memory layer for AI coding agents, enabling teams to store, search, and sync context, decisions, and knowledge across projects with project-based isolation and multi-backend support.141MIT
- AlicenseNot gradedqualityDmaintenanceLocal-first MCP server for AI coding agents that provides isolated code search, memory ledger, context rot detection, and cost governance.13 npm2MIT
- AlicenseNot gradedqualityCmaintenanceA local-first MCP server for AI coding agents that shares structured execution state, routes context deltas, and provides preflight nudges to prevent conflicts and stale decisions.MIT
- FlicenseNot gradedqualityDmaintenanceA local-first MCP server that manages developer memory for coding agents, enabling shared project context, permissions, and audit trails across different agents.1-