Hosted activity monitoring Reference

This optional hosted facility records MCP call metadata for a separate administrator browser surface. It registers no business tools or recovery types. Its source contains the earlier 103-operation integration, not the separate 104-operation sales/provider candidate. Match the running build before applying this contract.

Identity and configuration

/system-admin is a browser administration surface. A publ seller session, account/channel MCP target or MCP bearer token does not grant administrator access.

The built-in adapter enables administration and metadata collection together. Both are disabled by default. Existing hosted database, HTTPS, CSRF and credential settings remain prerequisites.

Bootstrap creates the initial account and singleton marker atomically. Later starts do not overwrite that account or reset its password. The administrator identity uses separate tables and the __Host-publ_system_admin cookie. Passwords are salted scrypt hashes; MFA secrets are encrypted with AES-256-GCM and bound to the administrator ID. Session, invitation and recovery tokens are hashed in storage. These implementation properties are not a general security certification.

Browser sign-in starts at /system-admin/login. Initial enrollment displays ten recovery codes once. Enrolled users can use a single-use recovery code for login; privileged invitation/revocation/disable actions require a fresh authenticator code. Sessions have an eight-hour absolute lifetime and a thirty-minute inactivity limit. Persisted failure limits and consumed TOTP steps guard repeated attempts and code replay.

Invitations expire after 48 hours, are single-use and can be revoked. The recipient chooses a password and enrolls MFA. The service does not email the invitation. Disabling an administrator invalidates their sessions; the last active administrator cannot be disabled. Authentication and administrator changes have a separate audit view at /system-admin/audit; the account directory is /system-admin/admins.

What a call records

For unified /mcp, one observation wraps each entered discover or execute callback. Execute records the requested business operation, rather than the wrapper name. Its private business server has no second observer, preventing double counting. Scoped /mcp/account and /mcp/channels/{channelCode} observe the registered business callbacks directly.

Selected metadata excludes argument and response bodies, discovery keywords, passwords, bearer tokens, cookies and authorization URLs. The projection does not store grant IDs, business request/job IDs or a running-build manifest. Account/channel/client identifiers remain in metadata; this is not anonymous usage data.

Two HTTP observations supplement callback data: invalid MCP authentication records mcp_authenticate, auth, error, INVALID_TOKEN, duration zero and confirmed:false; handled /oauth/token responses record oauth_token, auth, HTTP_<status>, success below 400 or error otherwise, and confirmed:false. They have no authenticated account attribution. Generic token errors are not dedicated publ refresh diagnostics.

Outer SDK input-schema rejection occurs before the callback and records no tool observation. Protocol initialization, tools/list, parsing/origin/content-type rejection and other early failures are not a complete audited request stream. Child business-schema rejection inside entered unified execute is observed through its returned dispatcher result. A missing record is not proof that a request was never made, and a recorded attempt is not proof that a business handler performed a write.

Outcome and confirmation

The observer applies this precedence to the returned structured result:

1. If structuredContent.outcome is unknown or partial, retain it even when isError is true.
2. Otherwise, isError:true or a thrown callback with no result records error.
3. Otherwise, use structuredContent.status only if it is success, error, action_required, partial or unknown; a missing/unrecognized status records unknown.
4. Independently set confirmed only when structuredContent.verification.confirmed === true.

Consequently, successful discovery can have confirmed:false. A read can have confirmed:true without writing. A no-op or historical completion must still be interpreted using its full business result. An action_required handoff is not a finished financial action. Monitoring does not infer that a write occurred, recompute verification, or upgrade uncertain results from HTTP success.

Observer exceptions are swallowed after the business callback so telemetry failure does not alter a completed business result or cause a business retry. Database failures retry only the queued metadata. Preserve the original target, task and request identity when following the tool's recovery instructions; do not resubmit a write because a dashboard record is absent.

Filters, time and pagination

Authenticated administrators read the HTML activity view at /system-admin. These are browser query parameters, not MCP arguments or a new public JSON endpoint.

The lower time bound is the start of the current UTC hour minus days UTC days. For a query at 2026-10-14T04:37:00Z with days=1, it is 2026-10-13T04:00:00Z, inclusive. This includes the current partial hour; it is not exactly the preceding 24 hours or a midnight-based calendar day. Raw events and hourly summaries use the same computed cutoff. SQL explicitly uses UTC for both hour buckets and cutoff arithmetic, independently of the database session time zone and DST. There is no explicit upper timestamp bound in this query.

The page returns per-operation/category, account and channel aggregates, each capped at the 100 largest call counts. It also reads hourly series, outcome totals and the 50 most recently inserted events. Recent-call pagination fetches a 51st row to decide whether a next cursor exists; the next before is the ID of the 50th returned row. Insertion order is not guaranteed to be occurrence-time order when queued events arrive later. before affects recent rows only, not aggregate totals or charts.

Aggregate errors count only outcome:error; partial, unknown and action-required counts retain their own outcome totals. Average latency is the rounded arithmetic mean of stored durations, not a percentile; maximum is the largest stored duration. last_hour is an hour bucket, not a precise last-seen timestamp. Recent rows retain exact timestamps, outcome and confirmation separately. Empty SQL filtered sums can be null; the browser displays a zero fallback. The six data queries share a cutoff but run separately, so concurrent ingestion can produce different views of the latest writes; the page is not an atomic database snapshot.

Storage and health limits

The built-in adapter uses a separate two-connection pool for monitoring writes and dashboard queries. The store flushes on a one-second timer or after at least 250 pending entries, one batch of at most 250 at a time. Capacity is 2,000 pending events plus the active batch. Calls are not blocked waiting for a persisted monitoring record.

Each batch inserts raw events and updates corresponding UTC hourly aggregates in one transaction. A repeated event UUID is ignored for insertion and aggregation, so retry after an uncertain COMMIT response does not double count that event. Failed batches re-enter the bounded queue; overflow is dropped. A process crash can lose buffered events, and shutdown draining stops if it makes no progress.

Collection health reports queued, dropped, failedBatches and lastFlush. Queued excludes the active batch, failed batches are not failed business calls, and lastFlush is the successful batch-storage time rather than the last MCP operation. These counters are in-memory process state. Health and metrics do not provide lossless delivery, billing accuracy or a complete security audit.

Active-connection presence, exact p95 latency, alerts, dedicated refresh diagnosis and sustained production capacity are not provided by these metrics. A recent successful call does not prove that a client remains online.