Busabase × MCP
An MCP knowledge base with human approval
Busabase is a shared knowledge base that agents can read and update through MCP. With a changeRequest permission grant, the agent can investigate and propose changes while a reviewer decides whether to merge them. Keep the proposed finding, its source and the accepted record separate, so the next task can tell what is ready to reuse.
Busabase product interface (English).
The permission grant makes the review boundary real
MCP supplies tools; it does not make every tool result a verified fact. On Busabase Cloud, connect an MCP client to https://busabase.com/api/mcp with Streamable HTTP, finish browser OAuth and select the account, permission and expiration. Use read for inspection, changeRequest for proposals, and write only for a trusted workflow that needs review or merge operations. A write grant is broader access, not a guaranteed human-review queue. A prompt saying “ask first” is useful task guidance but does not narrow the credential. If your client cannot complete OAuth, use an API key with the same deliberate permission and expiry choices.
Choose authority for the task
read
Inspect existing records. Reading gives the agent context without granting record changes.
changeRequest
Propose field changes for review. The reviewer checks evidence and scope before an authorized merge.
write
Broader authority for trusted processes, including review and merge capabilities. Set it deliberately when direct action is intended.
From a task result to shared knowledge
- 0101
Read before proposing. Call auth_verify, select the intended Space, and inspect the current record and its head version. Keep the source URL, relevant excerpt and effective date with the claim. Do not silently replace a different workspace’s record.
- 0202
Propose a bounded change. For example, ask the agent to update one supplier’s delivery lead time from a revised contract. Include the old value, proposed value, exact contract reference, affected scope and unresolved questions. The example is a workflow design, not a measured integration result.
- 0303
Review the field diff. The reviewer checks the contract version and scope, accepts supported fields or requests a narrower corrected proposal. If the contract is only a draft, reject the factual update. Do not treat a successful MCP call or an agent’s summary as acceptance.
- 0404
Merge and read back. After authorized review and merge, read the canonical record again and verify the accepted value. If the head changed while the agent worked, inspect the intervening changes and revise the proposal instead of overwriting them. The next task reads the accepted version with its sources.
An acceptance record worth reusing
A reusable supplier record can carry supplier_id, service_region, lead_time_days, source_document, source_version, effective_at and evidence_status. Assign a responsible reviewer and use the ChangeRequest and commit history to trace the decision. Before acceptance, the revised delivery time remains a proposal; a rejected change does not become the current value. MCP makes the record accessible to the next agent, but does not automatically import its chat history, fetch every linked attachment or build a vector index.
Official documentationChangeRequest
A proposed record is not canonical until the authorized review and merge steps complete.
Illustrative workflow — not an agent product screenshot.
Inspect the proposal before it becomes knowledge
Illustrative supplier example — invented values, not a real customer record.
- 01Current accepted record: lead time 10 days; contract v2; region EU.
- 02Proposed update: lead time 7 days; contract v3; effective date must be checked.
- 03Review decision: v3 is unsigned. Reject the update; the accepted lead time stays 10 days.
A real review surface
When the record changes during investigation
Read before proposing
Capture the current record and version alongside the evidence you investigated.
Compare the intervening change
If another task updated the same field, inspect its evidence and revise your proposal against the current value. Avoid replacing it with an older snapshot.
Reread after merge
Retrieve the accepted record, verify the intended fields and give the next task that record reference. A proposal receipt alone does not establish the accepted value.
Practical questions
Does connecting MCP automatically enforce human review?
No. Choose changeRequest permission when an agent should read and propose without deciding the merge. A write-level grant can perform broader operations. Review the actual credential and workspace access rather than relying on the wording of a task prompt.
What should a reviewer check?
Check the changed fields, source document and version, applicable customer or region, effective date and open questions. Confirm the change belongs to this record. Return a correction request when the evidence is incomplete; reject a claim that the source does not support.
What happens if another agent updates the record first?
Read the latest record and compare it with the version used for the proposal. Resolve competing changes explicitly and submit a revised proposal where needed. Do not make the earlier version authoritative merely because the first agent started earlier.
Can any MCP client connect?
The client must support a compatible transport and authentication method. Busabase Cloud offers Streamable HTTP with OAuth, or an API-key alternative. Use the client-specific connection guide; a client that only accepts unauthenticated servers cannot directly use the authenticated Cloud endpoint.
Is this a replacement for RAG or a search engine?
It is a reviewed record layer. It does not promise automatic embeddings, universal document ingestion or a retrieval pipeline. Keep your existing search or retrieval system where needed, and use the accepted record and its source links as the accountable knowledge artifact.
Start with one bounded knowledge update
A proposed record is not canonical until the authorized review and merge steps complete.
Connect your agent