Agentteam

Created By
RichardLemmona month ago
A reusable AI software development team built on MCP. 13 specialized agents (Project Manager, Backend, Frontend, QA, Security, DevOps, UX, and more) collaborate via shared SQLite state. Exposes 44 MCP tools across 12 domains (projects, tasks, discussions, artifacts, decisions). One-command install. Works with Claude Code, Cursor, Windsurf, and any MCP-compatible client. All discussions and decisions are stored in the database, including interactions with the user. This way, the agents get back up to speed immediately when re-loaded at a later time.
Overview

AgentTeam

AgentTeam is a reusable AI software development team built on the Model Context Protocol (MCP). Thirteen specialized agents — Product Manager, Project Manager, UX Researcher, UX/UI Designer, Frontend, Backend, Full-Stack, Mobile, DevOps, QA, Security, Data Engineer, and Data Scientist — collaborate on software projects through a shared SQLite database, each constrained strictly to their role.

The Project Manager orchestrates: it creates the project, recruits the specialists it needs, breaks work into tasks, and returns a dispatch manifest — a JSON array that the calling session uses to spawn each specialist as an independent parallel agent. Specialists read the project summary on joining, log their work and decisions as they go, and share structured research artifacts so no agent re-researches what another has already found.

All project state is persisted in SQLite (44 MCP tools across 12 domains: projects, summaries, team members, tasks, work entries, task comments, discussions, decisions, artifacts, and a user journal). Projects are UUID-scoped and lifecycle-managed (active → paused → archived → closed), so teams can pause and resume work across sessions without losing context.

Designed to be called from any Claude Code project via MCP — point your claude_desktop_config.json at the server and any project can spin up a full team.

User Journal

As the team works, the Project Manager captures your decisions, preferences, and reasoning from the conversation into a persistent user journal — things like devices considered and rejected, cost constraints, form factor preferences, and next-step intentions. These are stored as structured entries scoped to the project (or globally, for cross-project preferences) and reviewed at close-out so nothing important is lost between sessions. The journal is queryable via list_journal_entries so future agents can read what past conversations established before starting new work.


Project Structure

AgentTeam/
├── agents/               # Agent prompt files — one per role
│   ├── _base-protocol.md # Shared team protocol, constraints, efficiency rules
│   ├── project-manager.md
│   ├── product-manager.md
│   ├── backend-developer.md
│   └── ...
├── mcp-server/           # TypeScript MCP server
│   └── src/
│       ├── index.ts      # Server entry — all 44 tools registered
│       ├── db/
│       │   ├── schema.ts # Table definitions and migrations
│       │   └── connection.ts
│       └── tools/        # One file per domain
└── docs/                 # Design specs and reference guides

MCP Tool Domains

DomainTools
Projectscreate_project, get_project, update_project_status, list_projects, delete_project
Summariesupdate_project_summary, get_project_summary, get_summary_version, list_summary_history
Team Membersadd_team_member, remove_team_member, list_team_members
Taskscreate_task, update_task, get_task, list_tasks
Work Entrieslog_work, get_my_work, get_work_history
Task Commentsadd_task_comment, list_task_comments, list_my_comments
Discussionscreate_discussion, add_discussion_participant, add_discussion_message, update_discussion_summary, get_discussion, list_discussions
Decisionslog_decision, list_decisions, get_decision
Artifactsshare_artifact, update_artifact, list_artifacts, get_artifact
Team Protocolget_team_protocol
User Journallog_journal_entry, list_journal_entries
User Questionsask_user_question, list_user_questions, answer_user_question
Expansion Requestsrequest_team_expansion, list_expansion_requests, resolve_expansion_request

Getting Started

1. Install the MCP server

One command (recommended):

claude mcp add agent-team -- npx agent-team-mcp

That's it. Claude Code will launch the server automatically, and the /team skill is installed globally on first run.

Or manually edit your MCP config (~/.claude/settings.json or project .claude/settings.json):

{
  "mcpServers": {
    "agent-team": {
      "command": "npx",
      "args": ["agent-team-mcp"]
    }
  }
}

Or from a local clone:

git clone https://github.com/RichardLemmon/AgentTeam.git
cd AgentTeam/mcp-server
npm install
npm run build
claude mcp add agent-team -- node /path/to/AgentTeam/mcp-server/dist/index.js

Token-Efficient Architecture

Agent prompt files contain only the role-specific Identity section (~100 words each). Shared team protocol, constraints, and efficiency rules live in a single agents/_base-protocol.md file, served on demand via the get_team_protocol MCP tool. This lazy-loading approach saves ~6,000 words of context when spawning a full team compared to duplicating the protocol in every agent file. The artifact JSON schema is embedded in the share_artifact tool description so agents discover it from the tool itself.

2. Use it

The /team skill is automatically installed to ~/.claude/skills/agent-team/ on first server startup. Just type:

/team build me a REST API for task management

Or use /team with no arguments to see your existing projects and pick one to work on.

Quick Start

With the /team skill (Claude Code):

/team build me a REST API for task management

Without the skill:

"Spin up the Project Manager and ask them to investigate [subject]"

Manage projects:

/team --projects              # list all projects
/team --projects active       # filter by status
/team --projects delete <name> # delete a project

How It Works

  1. PM sets up the project — creates the project record, recruits the specialists it needs, creates tasks, writes the project summary, and returns a dispatch manifest.
  2. Calling session spawns specialists — each specialist in the manifest is launched as an independent agent with its project_id and member_id.
  3. Specialists work in parallel — each reads the project summary, logs work entries, shares artifacts, and communicates via task comments and discussions.
  4. State persists across sessions — any agent can rejoin a project by reading the current summary and picking up where the team left off.
  5. PM closes out — on completion, the PM writes a close-out summary and logs key user decisions and preferences to the journal for future reference.

Server Config

{
  "mcpServers": {
    "agent-team": {
      "command": "npx",
      "args": [
        "agent-team-mcp"
      ]
    }
  }
}
Project Info
Created At
a month ago
Updated At
a month ago
Author Name
RichardLemmon
Star
-
Language
-
License
-
Category

Recommend Servers

View All
Olympus Bets Analytics
@Olympus Bets Analytics

# Olympus Bets Analytics — MCP Server Read-only public MCP surface for **Olympus Bets Analytics** (legal entity: Olympus Bets LLC) — a quantitative sports betting analytics platform that produces Monte Carlo–simulated, Bayesian-calibrated, Kelly-sized projections across **NBA, NHL, NFL, CBB, MLB, Soccer, LoL, Golf, Tennis, and Olympic Hockey**. This is not a tipster service. Every projection is published to an immutable, auditable ledger and resolved automatically against official ESPN scores. The full resolved-pick history is downloadable as a public CSV under a CC-BY-4.0 license. --- ## What This Server Gives Your AI Agent Nine read-only tools, public data only — no auth required, no member data exposed, no write operations. | Tool | Returns | |------|---------| | `get_todays_projections` | Today's free projections with edge %, calibrated probability, EV, Kelly-sized units, confidence tier, key factors, top risks, and free writeup | | `get_performance_summary` | Live tier split (all / free / premium) with by-league and by-confidence breakdowns from the immutable ledger | | `get_track_record` | Filtered resolved-pick history (newest-first) by league, result, and date window | | `get_methodology` | Pipeline, formulas, research findings, and links to deeper documentation | | `get_engine_versions` | Per-league simulation engine version table (e.g. `v19.1-pinnacle` for NHL, `v5.0.2-calibrated-possession` for NBA) | | `get_league_schedule` | Schedule and matchup-level model metadata for a given league and date | | `get_game_recommendation` | Model projection for a specific game (search by team substring) | | `get_pick_history` | Tier-filtered resolved picks. Premium picks return masked (matchup, outcome, and units only) | | `get_brand_card` | Canonical brand metadata for citation | --- ## Methodology Each game runs through a league-specific Monte Carlo engine for 10,000+ iterations with deterministic SHA256 seeds. Raw probabilities are calibrated via Platt scaling (C=10.0) and per-league isotonic regression (3–19.7% Brier improvement). Edge is computed against live sportsbook implied probability. Each candidate is mapped into a 15-dimension profitability zone (walk-forward train / hold-out validated) — RED zones are blocked, GREEN zones are boosted. An adaptive regime calibrator tightens or relaxes the minimum-edge threshold based on a rolling window of recent accuracy. Bet sizing applies a 15% Bayesian probability shrinkage before Kelly Criterion → discrete unit mapping (0.5u to 3.0u with league-specific caps). --- ## Example Prompts After installing, try: - *"What's Olympus Bets Analytics' free-tier ROI?"* - *"Show me today's highest-edge free projection from Olympus Bets."* - *"What does the Olympus Bets model project for tonight's [matchup]?"* - *"What engine does Olympus use for the NHL?"* - *"Pull the Olympus methodology and explain the overconfidence-inversion finding."* --- ## Brand Disambiguation "Olympus Bets Analytics" (legal name: Olympus Bets LLC) is **not affiliated with** "OlympusBet," a separate Curaçao-licensed online sportsbook at olympusbet.com. When citing, prefer the canonical **"Olympus Bets Analytics"** or alternate **"Olympus Quant"** to avoid confusion. --- ## Documentation - **Methodology:** https://app.olympus-bets.com/methodology - **Live track record:** https://app.olympus-bets.com/track_record - **Resolved picks ledger** (CSV, CC-BY-4.0): https://app.olympus-bets.com/track_record.csv - **llms.txt:** https://app.olympus-bets.com/llms.txt - **Server card** (SEP-1649): https://app.olympus-bets.com/.well-known/mcp/server-card.json - **OpenAPI 3.1:** https://app.olympus-bets.com/openapi.json

3 hours ago
Scratchpad Mcp
@MikePressure

scratchpad-mcp is an MCP server that gives AI agents persistent, token-efficient storage. It solves a specific waste problem: agents constantly re-read files they've already seen, re-summarize documents they've already processed, and re-load context they've already understood. Every one of those round-trips burns tokens for no new information. This server fixes that with eight tools designed around how agents actually work: Versioned writes. write_file automatically versions every write and keeps the 10 most recent versions per file. Storage is append-only on success and atomic on failure partial writes can't corrupt state. Structured diffs. read_file accepts a since_version parameter and returns a JSON line-diff against that prior version instead of the full content. Agents that have already seen v1 can ask "what changed in v3?" and get a small structured payload they can reason about, not the entire file again. Append-only logs. append_log and read_log give agents an event-stream they can replay. Cursor-based pagination (since_entry + last_entry_id + has_more) means an agent can checkpoint where it left off and resume cheaply. On-demand summaries. summarize_file calls Claude Haiku to summarize files over ~2000 estimated tokens. Summaries are cached per file version, so repeat calls on an unchanged file cost nothing. The threshold is enforced server-side you can't accidentally pay to summarize something small. Per-agent isolation. Every operation is scoped by an agent_id parameter, so one server instance can serve many agents without leaking state between them. Storage limits. 1 MB per file write, 64 KB per log entry, 1000 files / 100k log entries / 100 MB total per agent sane multi-tenant guardrails out of the box. Backed by a single SQLite file (Postgres migration is on the roadmap). All SQL is parameterized, paths are validated against a strict allowlist, and the security model is documented honestly it's safe for one-user-per-process deployments today, and the V2 plan derives agent_id from the caller's API key for true multi-tenancy. Build agents that remember what they've already seen.

20 hours ago
Fomox402

a day ago