# Basecamp in Claude for overdue to-dos and status

> Basecamp in Claude for a project team: each person on their own Basecamp sign-in, trash and project delete off the role, to-dos and comments kept.

**TL;DR** Elaichi's basecamp connector carries 104 tools, and 58 of them read, so putting Basecamp in Claude for a project team is mostly a reading job. Have each person connect their own Basecamp account, so Basecamp's project access decides what each call can see. Then block basecamp_recordings_trash, delete_a_basecamp_project_by_id and the create and update tools for webhooks and chatbots on the team's role, and keep the to-do, comment and card writes the weekly status work needs.

## The Friday status that eats a project lead's afternoon

A project lead at a company that runs on Basecamp spends Friday afternoon in six projects. Which to-dos slipped past their due date? What did the team say in this week's check-ins? Which message threads still have open questions? The answers are all in Basecamp, spread across tools and projects. Basecamp in Claude turns that afternoon into one prompt, with the to-do and comment writes that follow from it.

[Elaichi's `basecamp` connector](/connectors/basecamp/) carries 104 tools. By operation, 58 read, 18 create, 19 update and 9 delete. The reads cover projects, to-do lists, to-dos, card tables, messages, comments, schedule entries, events, people, check-in answers and uploads. The status work lives almost entirely in those 58.

Elaichi serves 600+ connectors through one organization-wide endpoint. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. For a project team, two decisions matter more than the menu paths. First, whose Basecamp account each call runs on. Second, which of the 104 tools the team's role may reach. Make both before anyone connects.

## Which reads Basecamp in Claude needs for a weekly status

Five read paths cover a weekly status. The model walks Basecamp the way the API is shaped: projects, then each project's dock (the list of tools a project has turned on), then the records inside.

| Question | Basecamp tools | What the model reads |
|---|---|---|
| Which projects am I on? | `list_all_basecamp_projects` | Each project the person can see, with its dock |
| What is overdue? | `list_all_basecamp_recordings` with type `Todo`, or `list_all_basecamp_todo_lists` then `list_all_basecamp_todos` | Active to-dos and their due dates |
| What did the team report? | `list_all_basecamp_questions`, `list_all_basecamp_question_answers` | Automatic check-in answers |
| What did threads decide? | `list_all_basecamp_messages`, `list_all_basecamp_comments` | Message board posts and replies |
| Where do cards stand? | `get_single_basecamp_card_table_by_id`, `list_all_basecamp_card_table_cards` | Cards in each column |

The cross-project path is the useful one. `list_all_basecamp_recordings` lists recordings of one type across projects, and it defaults to every active project the connected person can see. Basecamp's API documents a `due_on` date on each to-do, the date by which it should be completed ([Basecamp API, to-dos](https://github.com/basecamp/bc-api/blob/master/sections/todos.md), checked October 2026). So "list every overdue to-do by assignee" is a read and a date comparison, not a crawl through each list by hand.

## Why each person should connect their own Basecamp account

Each person connects their own Basecamp account, and nobody shares one. Elaichi's basecamp connector signs in as a person. Every call through a connection uses the account it was connected with, whoever makes the call. A shared Basecamp connection reaches Basecamp as the person who connected it, for everyone it is shared with.

That matters because Basecamp's own access is per project. Basecamp's API authenticates every request with an OAuth 2 token that a person grants so an app can use Basecamp on their behalf ([Basecamp's authentication guide](https://github.com/basecamp/bc-api/blob/master/sections/authentication.md), checked October 2026). OAuth here is the browser sign-in that issues an app a revocable permission to act for one person. If the ops lead shares their connection, a junior teammate's Claude can read every project the ops lead is on.

With per-person connections, the boundary is clean. Basecamp decides which projects each call can read, because the call runs as that person. Elaichi decides which tools the call may use, because the restriction sits on their role. Each person connects Basecamp in Elaichi and leaves the connection unshared. Their calls then reach their own connection, and the role's rules still apply on every call.

## Keeping trash and project delete off the team's role

Block the two tools that remove work, plus the four that can point Basecamp at an outside address. A restriction in Elaichi is a rule naming which connectors and which individual tools a target may reach. Write a block rule on the project team's role naming these six:

| Tool | What it does |
|---|---|
| `basecamp_recordings_trash` | Trashes any recording: a to-do, message, document, upload, comment, card or to-do list |
| `delete_a_basecamp_project_by_id` | Trashes a whole project, which Basecamp deletes after 30 days |
| `create_a_basecamp_webhook` | Registers an HTTPS `payload_url` that Basecamp calls when the webhook fires |
| `update_a_basecamp_webhook_by_id` | Takes a `payload_url` on every call, so it can repoint an existing webhook to a new HTTPS address |
| `create_a_basecamp_chatbot` | Adds a chatbot to a Campfire, with an optional `command_url` Basecamp calls |
| `update_a_basecamp_chatbot_by_id` | Takes an optional `command_url`, so it can repoint an existing chatbot |

The trash tool is the subtle one. It is a single tool that reaches every recording type, so one wrong call can remove a to-do list or a whole message. Trashed records sit in Basecamp's trash and can be recovered there. Recoverable is still a cleanup job for whoever notices first.

A block-only rule leaves everything it does not name reachable. That is the right shape here, because the team needs most writes. Blocks also combine with other blocks, and within a layer a block always beats an allow, so adding one never widens anything. A block matches a tool's name or the operation Elaichi stored when the rule was saved. The reasoning behind that split is in [why blocks and allows match differently](/blog/block-matches-name-allow-matches-operation/).

Two mechanical details matter. A restricted tool is withheld from the tool list and cannot be called; search names it, flagged restricted, with no schema. A restriction change takes effect within about two minutes, so test a new rule a few minutes after saving it.

The other seven delete-operation tools are judgment calls. `basecamp_messages_unpin` only removes a pin. `delete_a_basecamp_chatbot_by_id` removes a chatbot across the whole account, which is an admin's decision. Block what your team has no reason to run.

## The writes the team keeps, and one that clears assignees

The team keeps to-do, comment and card writes, because those are the follow-through on a status run. `create_a_basecamp_todo` takes the to-do's content plus an optional due date, assignees and a notify flag. With notify set to true, Basecamp notifies the assignees. `create_a_basecamp_comment` posts under any recording, such as a message, to-do, document or card. `update_a_basecamp_card_table_card_by_id` changes a card's title, content, due date and assignees.

One update tool needs a warning in the team's prompt guide. `update_a_basecamp_todo_by_id` needs the to-do's content on every call. Its catalog description also says omitting `assignee_ids` clears the to-do's existing assignees. A model asked to "push the due date to Friday" that sends only the date and content will unassign the to-do. Tell the team to ask Claude to read the to-do first and send its assignees back unchanged.

`create_a_basecamp_message` has its own trap. Without status `active`, the message is a draft that notifies no one. With it, and without a subscriber list, everyone on the project is notified. For a weekly update that is usually right. For a draft the lead wants to review first, ask for a draft.

## Adding Elaichi to Claude, and what the consent screen covers

On Claude Team and Enterprise, an Owner or Primary Owner adds Elaichi once, at Organization settings, Connectors, Add, Custom, Web ([Anthropic's documentation](https://claude.com/docs/connectors/custom/add-unlisted), checked October 2026). The address is `https://api.elaichi.ai/mcp` for every organization. Members then connect it under Customize, Connectors, each with their own OAuth grant.

The consent screen is not where the trash block comes from. For a connected app's tools, the "Run your connected tools" checkbox enables reads and writes alike. Only a tool Elaichi tiers as destructive also needs "Delete data and remove access", which is never pre-ticked. That box is each person's choice at sign-in. The block rule is the organization's decision, and it holds whatever each person ticks.

Claude's own per-tool permission settings do not single out Basecamp either. In Elaichi, connected tools are never listed one by one, however few there are. The model finds Basecamp tools with `search_tools` and runs them through `execute_tool`, so a permission set on that one tool covers every connected app at once. The full walkthrough is in [connecting Elaichi to Claude](/blog/connect-elaichi-to-claude/).

## Basecamp's own MCP server, and when it is the better choice

Basecamp hosts its own MCP server, and for a team that only needs Basecamp, it is the simpler choice. The address is `https://mcp.basecamp.com/mcp`. Basecamp's AI page says it is included with every Basecamp account at no extra cost ([basecamp.com/ai](https://basecamp.com/ai), checked October 2026). The same page says the assistant acts as the signed-in person and cannot see projects they are not on. On approval, each person picks Read-only access or Full access. On Claude Team or Enterprise, an owner adds it once and everyone connects their own Basecamp account.

Basecamp also ships a local option. Its official CLI includes `basecamp mcp`, which runs an MCP server on stdin and stdout backed by the signed-in account. Its `--read-only` and `--domains` flags narrow what it serves ([basecamp-cli on GitHub](https://github.com/basecamp/basecamp-cli), checked October 2026). Community servers take the same self-installed shape. [CData's Basecamp server](https://github.com/CDataSoftware/basecamp-mcp-server-by-cdata) builds a read-only server over its JDBC driver, run on the same machine as the client. [A community Python server](https://github.com/georgeantonopoulos/Basecamp-MCP-Server) runs over stdio with its own Launchpad OAuth app (both checked October 2026).

Elaichi earns its place on a narrower case:

- **One address across apps.** Basecamp sits beside the team's other apps behind `https://api.elaichi.ai/mcp`, in Claude, ChatGPT and Cursor alike.
- **Per-tool rules per role.** The team keeps to-do and comment writes while trash and project delete stay restricted. The same role's rules cover every other connected app.
- **One sign-in per client.** Each member signs in to Elaichi once from Claude, and that one grant reaches every app they connected.
- **One audit trail.** Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none), whichever app the call went to.

If Basecamp is the only app the team asks about, and read-only or full access per person is the control you want, use Basecamp's server. Sometimes [you do not need a gateway at all](/blog/when-you-dont-need-an-mcp-gateway/).

## What the audit trail shows after a status run

Each Basecamp call that reached execution leaves one entry. Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none). The entry names the person, the Basecamp connection reached, the tool and the outcome. It also logs the one path argument that names the object, as the target id, and nothing else about the arguments, so an update shows which to-do it acted on, not what was written.

Each entry records the calling surface and the OAuth client too. A call from Claude is logged with surface `mcp`, with Claude named as the client and marked verified. When the same person uses Claude and ChatGPT against one Basecamp connection, the trail shows which client asked for what. A reviewer can read it on the free Auditor seat. The field-by-field schema is in [what an AI agent audit log must capture](/blog/what-an-ai-audit-log-must-capture/).

When someone needs a restricted tool, they file an access request. An admin approves it in the console, under Governance, Access requests. The grant lifts exactly the one tool for that one person, and every other rule on their role keeps applying. Agencies with clients inside Basecamp have a sharper version of this problem, covered in [Basecamp in ChatGPT for agency client status](/blog/agency-chatgpt-basecamp-client-status/). The same per-person shape on another task tracker is in [ClickUp in ChatGPT for customer success](/blog/customer-success-chatgpt-clickup-tasks/), and the rest of the stack is in the [connector catalog](/connectors/).

## FAQ

### Does Basecamp have its own MCP server for Claude?

Yes. Basecamp hosts an MCP server at https://mcp.basecamp.com/mcp, and its AI page, checked October 2026, says it is included with every Basecamp account and works as the signed-in person. On approval, each person picks read-only access or full access. Basecamp's CLI also runs a local MCP server with basecamp mcp. A team that only needs Basecamp in Claude can use either with no second vendor.

### Should a project team share one Basecamp connection in Elaichi?

No. Elaichi's basecamp connector signs in as a person, and every call through a connection uses the account it was connected with. A shared Basecamp connection would let every teammate read the projects its owner is on, including ones they are not on themselves. Have each person connect their own Basecamp account instead, so Basecamp's project access applies to each caller.

### Which Basecamp tools should a project team role not reach?

Start with basecamp_recordings_trash, which trashes any to-do, message, document, upload, comment, card or to-do list, and delete_a_basecamp_project_by_id, which trashes a whole project. Add create_a_basecamp_webhook and create_a_basecamp_chatbot, because both register an outside HTTPS address that Basecamp then calls, and update_a_basecamp_webhook_by_id and update_a_basecamp_chatbot_by_id, because both can repoint an existing one. Write them as a block rule on the team's role in Elaichi.

### Can Claude find overdue Basecamp to-dos across every project?

Yes, through reads. list_all_basecamp_recordings lists recordings of one type, such as Todo, across every active project the connected person can see. Basecamp's API documents a due_on date on each to-do, so the model can compare those dates with today and list what is late, grouped by project or assignee.

### How fast does a Basecamp block take effect in Elaichi?

Within about two minutes. Role and restriction changes in Elaichi resolve through a short cache, so a new block binds every surface shortly after you save it. Revoking an OAuth grant, removing or suspending a member, revoking a share and disconnecting an account all take effect on the caller's next request.

## Read next

- [Basecamp in ChatGPT for agency client status](/blog/agency-chatgpt-basecamp-client-status/) — Basecamp in ChatGPT for an agency: approvals and card tables stay readable, account staff get reads only, and the writes a client can see go to leads.
- [ClickUp in ChatGPT for a customer success team](/blog/customer-success-chatgpt-clickup-tasks/) — Two decisions put ClickUp in ChatGPT for a customer success team: whose account each call runs on, and which ClickUp tools are restricted.
- [How to roll out Cursor to an engineering team](/blog/engineering-team-cursor-jira/) — To roll out Cursor to an engineering team, connect Jira and Slack once, block deletes per role, pin the project and channel, then have engineers sign in.