Documentation
Everything a technical reviewer — or a CCO’s outside consultant — needs to verify how agentdatasync works: a reference server you can run in five minutes, the document library, the permissions model, and the audit-log format, specified to the field.
The reference server is a small, readable MCP server that serves a synthetic dataset — a fictional 14-household firm, no real client data — through the same five read-only tools and the same audit logging as the product. It ships with the full agentdatasync package; if you received this site as part of that package, the source is in the mcp-server/ folder next to it.
Requires Node.js 20+. The server is TypeScript; the build compiles it to build/index.js.
# The mcp-server/ folder ships with the full agentdatasync package. # If you received it as a repository checkout: git clone <your-package-url> agentdatasync cd agentdatasync/mcp-server npm install npm run build
Add this to your client’s MCP configuration — claude_desktop_config.json for Claude Desktop, or your project’s .mcp.json / MCP settings for Claude Code. Use the absolute path to the folder on your machine.
{
"mcpServers": {
"agentdatasync": {
"command": "node",
"args": ["/absolute/path/to/agentdatasync/mcp-server/build/index.js"]
}
}
}
Restart the client. The server starts over stdio, loads the synthetic dataset, and begins appending to its audit log from the first tool call. There is no network listener and no account to create.
The MCP Inspector connects to the server and lets you call each tool by hand — the fastest way to see exactly what an agent can and cannot do.
npx @modelcontextprotocol/inspector node build/index.js
What you should see: the Inspector opens in your browser, connects over stdio, and its Tools tab lists exactly five tools — no more:
| Tool | What it does (all read-only) |
|---|---|
list_households | List all households at the firm. |
list_clients | List clients, optionally filtered to one household. |
get_client | Get one client by ID, with their accounts and household. |
search_notes | Keyword search over client notes; returns matches with client context. |
list_accounts | List accounts, optionally filtered by client or household. |
Call get_client with a sample ID such as CL-001, then check the server’s audit log file: a new JSON line records the call — timestamp, tool, arguments, result count, and duration. Then try to find a write tool. There isn’t one; that absence is the design.
The written record behind the marketing pages. Every document below is published and bundled with this site.
AVAILABLE
The full control story: scope and data flow, a control-by-control mapping to Regulation S-P (safeguards, incident response, the 30-day customer-notification clock, service-provider oversight and the 72-hour term) and to Rule 204-2’s books-and-records requirements, a threat model, and an explicit list of what we claim and what we do not. Written to be handed to a CCO or an outside compliance consultant as-is.
IN PROGRESS
The step-by-step engagement: exporting from your CRM, running the cleanup, CCO review and sign-off of the cleaned dataset, setting the permissions matrix, connecting the first agent, and the first monthly audit review. Includes the checklist your ops team works from.
IN PROGRESS
One page for your vendor file: what data agentdatasync receives, where it lives, who can access it, sub-processors, retention, the 72-hour incident-notification commitment, and deletion at contract end — the answers your Reg S-P service-provider due diligence will ask for, on a single sheet.
IN PROGRESS
The questions firms actually ask: which CRMs we work from, which agents and MCP clients are supported, what happens to the cleaned data if you cancel, how denials surface to users, and what the Audit tier adds over the base log.
TEMPLATE
The column layout the Scorecard and the cleanup process expect: client_id, first_name, last_name, email, phone, dob, state, household_id, household_name, account_number, account_type, notes — one row per account, client fields repeated. The Scorecard also accepts common aliases, so most native CRM exports work unmodified.
crm-export-template.csv (template — the fictional sample used by the Scorecard is bundled with this site as sample-crm-export.csv)
REFERENCE
The fictional CRM export behind the Scorecard’s “Try it with sample data” button: 28 clients, 42 accounts, duplicates and formatting defects planted on purpose. Useful for testing the reference server and the Scorecard without touching real data — which is also the rule for everything here: evaluate on synthetic data first.
Permissions are granted per agent and per data domain, default to denied, and are set with the CCO during onboarding. An out-of-scope call is refused and the refusal is written to the audit log. Changes to the matrix are themselves logged. The matrix below is the illustrative starting configuration from the Audit tier page.
| Data domain | Meeting-prep agent | Client Q&A agent | Ops reporting agent |
|---|---|---|---|
| Households & client identity | Read | Read | Read |
| Contact details (email, phone) | Read | Read | Counts only |
| Client notes (search) | Read | Own clients only | Denied |
| Account types & listings | Read | Denied | Read |
| Write, export, or bulk download | Denied | Denied | Denied |
Two invariants hold for every firm’s matrix, regardless of configuration: the tools are read-only (there is no write capability to grant), and every call — allowed or denied — is logged.
The audit log is JSON Lines: one JSON object per line, UTF-8, appended in execution order, never rewritten in place. Any tool that reads text files can read it; exports need no proprietary viewer.
| Field | Type | Meaning |
|---|---|---|
ts | string (ISO 8601, UTC) | When the query executed. |
agent_id | string | Identity of the calling agent. |
user | string | Firm user the agent acted on behalf of. |
tool | string | MCP tool invoked. |
args_hash | string | SHA-256 of the canonical argument JSON. |
args_summary | string | Redacted summary: IDs and search terms only; never note bodies. |
records_touched | array of strings | Client/household IDs read or attempted. |
result_count | integer | Records returned (0 for denials and empty results). |
outcome | string | ok, error, or a denial code such as denied_out_of_scope. |
duration_ms | integer | Execution time. |
The downloadable reference server writes the core subset of the same record, so the approach can be verified locally before any engagement:
{"timestamp":"2026-10-20T13:02:11.204Z","tool":"get_client","arguments":{"client_id":"CL-001"},"result_count":1,"duration_ms":3}
Fields: timestamp (ISO 8601), tool, arguments (as received), result_count, duration_ms. Failed calls are logged the same way, with result_count 0. Retention and indexing in the Audit tier are designed to support Rule 204-2’s five-year retention with the first two years easily accessible (sourced: 17 CFR §275.204-2) — your firm remains responsible for its own recordkeeping determinations; this documentation is not legal advice.