Key takeaways
- Shared access needs a shared service: Configuring several clients with separate local stores does not create one shared knowledge backend.
- Test identity as well as connectivity: A successful tool call does not prove that permissions, revocation, or tenant boundaries work correctly.
- Plan the operating model: Assign owners for updates, backups, client compatibility, and incident response before rollout.
- Evaluate the knowledge layer separately: MCP connects clients to capabilities; storage, retrieval quality, and curation depend on the selected implementation.
Connecting the first coding assistant to a knowledge service is only the start. The harder question is whether several assistants can use the right shared information reliably as users, permissions, clients, and documents change. This checklist helps a platform team evaluate that operating model without confusing protocol compatibility with a complete managed service.
Establish what is actually shared
Draw the path from each client to the service and from the service to its knowledge stores. Mark local processes, remote endpoints, credentials, and persistent data. Two clients using the same configuration template may still write to separate local files or databases. Conversely, a local proxy process can forward requests to a remote service; its presence does not establish offline operation.
Use a harmless test record to check the architecture. Create it through one authorized client, retrieve it through another, then update it through the supported write interface. Record when the second client sees the new version and whether its answer identifies the source correctly. This is a proposed acceptance test, not a claim about a particular product's synchronization speed.
The Model Context Protocol specification defines interactions between clients and servers. Record the exact client, server, and proxy releases, supported protocol revision, transport, authentication mode, tool schemas, and safe error handling behavior. Use the authentication and endpoint configuration documented for the selected client, server and deployment. When upgrading components, test invalid or expired credentials and unsupported protocol errors to confirm that failure defaults to access denial rather than broader privileges. For security guidelines, refer to the MCP Security Best Practices.
Use a rollout matrix rather than a connection demo
Data table · Scroll horizontally to see all columns. Arrow keys work when focused.
| Test area | What to exercise | Evidence to retain |
|---|---|---|
| Client compatibility | Each supported client and protocol mode | Version, transport, auth mode, tool schema, and successful representative calls |
| Shared state | Create, update, and retrieve a test record across clients | Source revision and observed update behavior |
| Permissions & Revocation | Scoped principals across search, snippet, read/write, and relations; revoke active and fresh sessions | Initial access, revocation outcome, control principal status, and dual-layer ingestion/serving ACL checks |
| Interrupted calls | Timeout or cancellation during a harmless write mutation; reconcile before retry; bounded backoff without assuming request ID deduplication | Operation outcome, resource revision, and absence of duplicate writes |
| Untrusted content safety | Controlled document containing prompt instructions to alter scope or call secondary tools | Verification that server enforces authorization independently of model choice and approval UI |
| Change control | A server update and a client update | Regression results, credential error checks, and a recovery procedure |
| Recovery | Restore data, deployment config, and identity mappings using an approved secrets process | Verified records, permissions, configurations, and system targets |
Choose representative questions that require exact names, paraphrases, and source links. Compare the returned evidence as well as the final answer. If one client applies a different prompt, model, cache, or tool policy, it can answer differently even when the backend is shared.
For identity testing, use distinct scoped test principals rather than shared admin tokens. Verify initial access on a retained test fixture, revoke access, and test both existing connections and fresh sessions while ensuring an allowed control principal retains read access. Use a separate fixture for deletion and retention tests. Test search results, snippets, direct reads, writes, and relationship queries. Note that permission revocation cannot retract text already disclosed into client context or logs. Ensure permissions are verified both at ingestion and at serving time, as source ACLs are not automatically inherited.
Interrupted calls require clear handling: a timeout or cancellation does not prove that a write failed or rolled back. Before retrying, test an interrupted harmless mutation and reconcile the recorded operation result or resource revision. Use documented idempotency or conditional-write controls only when explicitly supported by the implementation; JSON-RPC request IDs do not provide deduplication or exactly-once execution. Apply bounded retries with backoff for eligible transient errors, and avoid blind replays of write operations.
Include a controlled untrusted document or tool-output fixture that contains instructions to alter scope or invoke secondary tools. Confirm that the client does not treat retrieved text as authorization and that the server enforces principal, action, and resource authorization regardless of model output. Note that approval controls in client interfaces are distinct from server authorization, and passing this test does not guarantee resistance to all prompt injection techniques.
Log lightweight operational evidence for debugging and auditing: record a sanitized correlation or operation ID, resource revision, outcome, latency, and retry count, while omitting secrets and full document bodies. Rather than imposing arbitrary numeric SLOs, define owner-agreed acceptance targets for availability, freshness, recovery time, and retrieval quality. Ensure recovery testing covers data, deployment configuration, and identity mappings, handling secrets strictly through an approved secure process.
Divide maintenance responsibilities explicitly
A useful operating agreement names the owner of each recurring task. The knowledge owner reviews definitions and stale records. The platform owner maintains the service, secrets, backups, and monitoring. Client owners test compatibility when assistants or extensions change. These roles may belong to one small team, but the tasks still exist.
Source ingestion has its own workload. A connector can reduce integration work when it supports the required source, format, and update model. Custom imports may be appropriate for unusual records or transformations. In either case, test deleted documents, changed permissions, expired credentials, and partial failures. “Connected” is not the same as “current and authorized.”
Keep a short incident procedure: identify the affected client and source, pause unsafe writes if needed, restore access through the normal process, and rerun representative checks. Avoid logging unrestricted document contents or credentials simply to make debugging easier.
Where AKB fits in this evaluation
Dnotitia's Agent Knowledge Base (AKB) is a candidate when a team wants reusable knowledge available to multiple agent clients. Its documented capabilities include MCP access, versioned knowledge, explicit relations, and hybrid retrieval. Optional ingestion and workflow integrations should be assessed separately from the core store; their availability does not mean a deployment includes a fully managed connector or autonomous curation service.
Use AKB's documented client setup and supported write tools for the rollout test. Check the exact protocol mode supported by each client rather than treating modern discovery and legacy initialization flows as interchangeable. If OAuth, a proxy, or a source-specific plugin is part of the design, include it in the compatibility and recovery tests.
AKB Core uses BSL 1.1. Its conditional production-use grant applies below 100 Named Seats aggregated across deployments and related entities as defined in the LICENSE. Production use at 100 or more aggregated Named Seats, or offering AKB to third parties as a hosted, embedded or rebranded service at any seat count, requires a separate commercial license. The npm akb-mcp client proxy has separate MIT licensing. Check the LICENSE supplied with the exact release being deployed.
Frequently asked questions
Does MCP provide a shared memory database?
MCP provides a way for clients and servers to interact. Whether information persists and is shared across clients depends on the server and storage implementation you deploy.
Can one successful client test cover all assistants?
No. Clients can differ in protocol support, tool behavior, credentials, caching, and approval controls. Test each supported configuration against the same acceptance cases.
What should be ready before rollout?
At minimum, establish the shared-service boundary, test access and updates, name maintenance owners, and demonstrate a recovery path. Expand only after the representative clients pass those checks.
Review the AKB documentation alongside your client requirements to decide whether its knowledge service fits the proposed operating model.