From an assistant’s proposal to an auditable change

TickerTrac keeps an investor's saved reasoning beside public evidence and its history. An assistant working with that information needs to know which version it read and which account owns it. Its interpretation of a source must also remain distinguishable from a saved product judgment.

I used Model Context Protocol (MCP) to expose a small set of typed tools over the existing product. The server owns access checks and uses the same saving and version-history rules as the application. A conversation can propose work; it cannot silently become the source of truth.

The first connection uses a named, revocable credential. Read access is the default. Enabling the reviewed-write capability allows an assistant to prepare a proposal, while approval remains an authenticated action by the account owner. This adds a deliberate step when the investor's saved reasoning changes.

The connector reads retained theses, history and evidence within the connected account. Results identify the saved version and the relevant time window. A retained-source search reports its coverage limits, and unavailable financial information stays explicitly unavailable. An empty search cannot establish that nothing happened.

Access to an account is only one part of the read decision. Retained source material also has to be permitted for the intended use, including processing by an external model. Current restrictions can withhold material that was previously available. Fresh cached data does not itself establish permission to export it.

These reads use retained information without initiating new research or model calls inside TickerTrac. The host assistant may have its own model cost. I kept that distinction explicit so a simple inspection request could not quietly become paid background research.

For a thesis revision, the assistant prepares a proposal against the version it read. Preparation creates a reviewable proposal without changing the thesis. The investor opens a review page that shows the exact before-and-after text, affected items and requesting connection.

1. Inspect. Read the relevant saved version and available evidence.
2. Propose. Prepare the concrete changes and their expected starting state.
3. Approve and apply. The owner reviews the proposal; the server rechecks access and current state before saving the complete batch atomically.
4. Read back. Return a durable receipt identifying the saved versions so the assistant can report what actually happened.

I initially separated owner approval from assistant execution. The revised interface lets the owner approve and apply in one action, reducing a handoff while keeping the same authorization and history rules. The assistant can then retrieve the result, even if its original session was interrupted.

Approval covers that proposal and starting state. If the wording or saved version changes, the old approval cannot be reused. A saved change also does not implicitly authorize a new research run or the publication of private reasoning.

A dropped response creates a common integration problem: the client does not know whether the server committed the change. Blindly repeating the write could add a duplicate version or apply only part of a related set of changes. The executor instead saves the result with a durable receipt and makes an identical retry recover that receipt.

The client repeats a completed operation

The same receipt and saved versions are returned, without another mutation.

The underlying thesis changes before application

The stale proposal is refused so the investor can review the current state.

Access is revoked or belongs to another account

The request is refused. A prepared proposal does not preserve access after revocation.

One operation in a batch cannot be applied

The batch does not leave a partial set of saved changes.

Idempotent recovery and atomic application solve different problems. One makes repeated requests safe; the other keeps related changes together. Version checks add a third property: a successful retry cannot silently overwrite work done since the proposal was prepared.

Automated backend checks exercised wrong-account requests, changed proposals, stale versions, revoked credentials, concurrent execution, receipt recovery and all-or-nothing application. SDK and transport checks exercised tool discovery and the connector contract. A local browser journey covered owner review, application, reload and recovery of the same receipt through MCP.

The October 13 release passed the repository's complete verification run. A fresh installation from the public download then succeeded without private repository access. Live SDK discovery and scoped retained reads succeeded; an existing applied receipt remained readable. The live financial read withheld values when source permission was unavailable rather than presenting a fresh cache as authorization.

That release check did not apply a new production batch merely to demonstrate the flow. The new review-and-apply journey was exercised with test data and locally, while the production observations above verified deployment and retained access. These are implementation and single-owner observations, not a claim of broad adoption, measured time savings or reliability at scale.

This is a dated account of the local connector and explicitly reviewed writes. Hosted OAuth, optional standing write permissions and expanded source-passage retrieval are separate extensions; their implementation or later availability does not retroactively expand the evidence reported here. The assistant connection guide describes the currently available setup.

The integration does not establish that an assistant's proposed thesis is factually correct. It makes the inputs, authority, change and outcome easier to inspect and recover. Judgment quality still needs the source-based evaluation work described separately.

Published October 15, 2026. Observations through October 14.

An assistant's permission to read says little about how much shared capacity a read can occupy. After adding retained source-passage retrieval to TickerTrac's MCP connection, I separated expensive searches from ordinary reads before they reached the database pool.

This is an October 14, 2026 follow-through to the earlier assistant approval and recovery case. The earlier article records its own release and validation. These later observations do not change those claims.

The connection lifecycle came first

Passage searches now wait for bounded admission before checking out a projection connection. A full gate refuses a search with a retry hint. Ordinary keyed reads bypass that gate. REST and hosted MCP use the same admission and measurement seam.

A review pass before the merge caught a flaw in the initial connection lifecycle: a REST read held the authentication connection while requesting another connection for its result. Concurrent ordinary reads could exhaust the pool without doing an expensive search. Authentication now releases its checkout before admission and projection work. A regression test checks that a read holds at most one connection at a time; another checks that a refused search takes no projection connection while an ordinary read proceeds.

A larger pool would allow more simultaneous database work; this comparison did not measure whether the database could support that. I kept admission control at the point where expensive work starts.

The gate is local to each process. It does not provide tenant fairness or a shared limit across processes. Bounded telemetry records admission wait, pool wait, projection duration and outcomes without retaining arguments or research text. The measured total begins after authentication.

The benchmark showed a cost

A local comparison used real HTTP clients, the in-process API and a test database containing 460 synthetic documents. At ten concurrent callers, each condition made 120 requests. The mixed workload split callers equally between searches and ordinary reads.

All requests succeeded. The fast searches did not put the pool under meaningful pressure, so the gate mainly added queueing. The mixed row combines both kinds of request; it is not an isolated measurement of ordinary-read latency. These results support neither a throughput improvement nor a production capacity claim.

The separate exploratory run that exposed the authentication-checkout defect used different code and a different request count. It establishes a failure mechanism, not a paired performance baseline for this table.

What shipped, and what remains uncertain

After deployment, Claude Code exercised five read operations through its hosted MCP connection, including pagination and source-passage retrieval. All succeeded. Search projection measurements fell within histogram buckets whose p95 upper edge was 500 ms. That quiet smoke check verified the hosted path and telemetry; it did not test capacity under contention or establish a latency guarantee.

The useful result is explicit admission before scarce resource acquisition, with a tested connection lifecycle and visible refusal. I kept the queueing cost in the record because it is part of that decision. Whether the limit protects interactive reads under a sustained slow-search workload remains unmeasured.