mcpField
C
Campus Copilot MCP

Campus Copilot MCP

Local
github.com/xiaojiou176-openProductivity2Updated 22w ago
Repository

About Campus Copilot MCP

Campus Copilot MCP is a read-only MCP server for the local Campus Copilot BFF and imported workspace snapshots, intended for local Codex- or Claude Code-style workflows. It uses stdio and offers snapshot viewing and export, without controlling live websites or modifying campus services.

Key features

  1. 01Connects to local BFF and workspace snapshots
  2. 02Views Canvas, Gradescope, and other snapshots
  3. 03Checks health and provider status
  4. 04Exports snapshot artifacts
  5. 05Local read-only stdio access

Use cases

  1. 01Query campus information in a local MCP workflow
  2. 02Review imported learning-platform snapshots
  3. 03Check local service and provider status
  4. 04Export workspace snapshot files

MCP support

This local stdio MCP server exposes campus health, provider status, campus Q&A, platform snapshot viewing, and snapshot export tools. It works with local data and is neither a hosted MCP service nor a live-browser control interface.

Configuration

Local server config is the same for every client. Copy it into your client’s MCP config file.

No install method listed yet

We haven’t collected a package or remote endpoint for this server. Follow the instructions in the project README.

Repository
Packages
mcpbcampus-copilot-mcp-0.1.1.mcpb0.1.1

Tools

No tool list yet

Local servers expose tools only once running on your machine, and the maintainer has not provided a tool list.

Details

From the project README

@campus-copilot/mcp-server

Read-only MCP server for the local CampusCopilot BFF and imported workspace snapshots.

This is the generic MCP entry point used by the integration examples under examples/integrations/.

Use this package when you want the smallest single-server entry point for Codex / Claude Code-style local MCP workflows.

If you are still choosing between the generic MCP server, site sidecars, CLI, or SDK surfaces, start with ../../examples/toolbox-chooser.md first.

Install

Current install status: repo-local public surface with a bundled JS server artifact. The official MCP Registry lane now uses a GitHub release-hosted .mcpb bundle for this server; discovery-page read-back is still a separate proof step.

From the repo root:

pnpm install
pnpm --filter @campus-copilot/mcp-server build
pnpm start:mcp

Shared public-preview proof loop from the repo root:

pnpm proof:public

First command to try:

pnpm --filter @campus-copilot/mcp-server start

Registry-unblock progress in this repo:

  • the published bin now targets a bundled dist/bin.mjs artifact instead of a raw TypeScript entrypoint
  • the registry path now ships a release-hosted .mcpb bundle instead of relying on a public npm scope that does not exist
  • preregistry metadata now lives beside the package in server.json and the package-level mcpName
  • the bundle manifest now lives in mcpb.manifest.json
  • repo-side submit-ready fields now also live in registry-submission.packet.json
  • the public distribution router lives in ../../DISTRIBUTION.md
  • registry discovery-page read-back is still a separate upstream step; this README does not imply the listing UI has already been re-read

Registry preflight proof from the repo root:

pnpm check:mcp-registry-preflight

That preflight checks the late-stage alignment work that tends to drift:

  • package.json#mcpName
  • server.json release asset URL / SHA / transport alignment
  • mcpb.manifest.json version and entry-point alignment
  • the monorepo subfolder path
  • example config plus truthful install wording
  • the repo-owned submission packet that the owner can reuse later

Related public distribution doc:

Pair It With The Container Path

The current Docker surface is intentionally the thin local BFF, not this stdio server itself.

That split is on purpose:

  • the stdio MCP server stays the local read-only MCP entrypoint
  • the Docker path gives the repo one truthful HTTP and health-check surface
  • together they keep the product local-first instead of pretending CampusCopilot is a hosted MCP service

Build the containerized BFF from the repo root:

docker build -t campus-copilot-api:local .
docker compose up -d campus-copilot-api

Use the container path when you need a local HTTP surface or container-friendly healthcheck. Keep using this package when you need the local stdio MCP server. If you want the shortest rule in one sentence: pair it with the local stdio MCP server, and treat the Docker route as a local HTTP helper, not a hosted API.

You can also launch the local container directly without Compose:

docker run --rm -p 8787:8787 campus-copilot-api:local

Current tools

  • campus_health
  • providers_status
  • ask_campus-copilot
  • canvas_snapshot_view
  • gradescope_snapshot_view
  • edstem_snapshot_view
  • myuw_snapshot_view
  • export_snapshot_artifact

Boundary

  • local-first
  • read-only
  • stdio
  • snapshot-first or thin-BFF-first
  • not a hosted MCP service
  • not a hosted API
  • not a live-browser control plane
  • not a campus-site mutation surface
  • not a registration-automation surface
  • not a raw course-file AI upload surface

Use the same academic safety contract here as everywhere else:

See also

Comments

Markdown supported

New to MCP?

From what the protocol is to installing your first server, these answers cover most first questions.

An open protocol that defines how AI applications connect to external tools and data in a uniform way. Clients talk to the model; MCP servers provide tools, resources and prompt templates. They exchange standard messages, so one server can be reused by many clients.