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 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, 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, 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.
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, 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.
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, 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, checked October 2026). Community servers take the same self-installed shape. CData's Basecamp server builds a read-only server over its JDBC driver, run on the same machine as the client. A community Python 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.
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.
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. The same per-person shape on another task tracker is in ClickUp in ChatGPT for customer success, and the rest of the stack is in the connector catalog.
