feat(modules): pin the tinymcp v0.3.1 module, and correct what step two of the extraction actually sheds

[senamakel]

What this is

Step two of the tinymcp extraction, as far as it can honestly go today: the
TINYMCP module record lands, and three pieces of documentation that predicted
the rest of step two are corrected against measurement.

tinymcp cut v0.3.1 on 2026-08-22, publishing artifacts for all eleven host
keys modules::platform knows about. So the registry entry is unblocked and is
here. Cutting the tinymcp path dependency is not — tinymcp-bus v0.3.1
does not publish everything the host reaches for, and that is upstream work in
tinyhumansai/tinymcp that has to land and be released first. The details are
below and are also written into Cargo.toml next to the dependency, so the next
person reads them where the decision lives.

The headline number is not the one the plan predicted

scripts/kernel-floor.limits' 2026-08-22 entry said step two would drop the path
dependency "at which point the MCP transport stack leaves the always-on graph
entirely. Lower it in that PR."

Measured, it does not. scripts/dep-sim.py --cut tinymcp:

profile:  no-default + flows
baseline: 286 packages / 268 names / 2 native
cut:      tinymcp
after:    285 packages / 267 names / 2 native
delta:    -1 packages / -1 names

-1 package / -1 name / 0 native builds, and the package that leaves is
tinymcp itself with nothing beneath it. reqwest and rusqlite do not go,
because in this profile they are not tinymcp's to take: rusqlite has six
parents (openhuman, tinyagents, tinychannels, tinycortex, tinymcp,
tinymemory-core) and reqwest has ten. Confirmed with
cargo tree --no-default-features --features flows -e normal -i rusqlite / -i reqwest.

So the ratchet is not lowered here — nothing was shed. It is not lowered in
the follow-up either, beyond that -1. The corrected prediction is recorded as a
dated History entry rather than by editing the old one away; this is the same
lesson the TinyMemory port produced, and it is worth it staying findable: a module
boundary buys a compilation boundary, not a dependency shed, whenever the
module's dependencies are already shared with kernel surface.

Kernel floor before and after this PR: 286 / 268 / 2, unchanged.
scripts/check-kernel-floor.sh passes.

What blocks cutting the path dependency

Verified against the code, not assumed. tinymcp-bus v0.3.1 has a complete
names::METHODS (28 members), CONTRACT_VERSION and payload types — the survey
started optimistic. What it is missing:

Members that do not exist

• OAuthComplete(state, code). The contract has OAuthBegin only. The loopback
  callback route calls oauth_complete, which does the token exchange and the
  reconnect, and resolves state → server_id through a module-private pending map.
  Not reconstructible from Connect.
• The boot-connect pass (connect_installed_servers) and the reconnect
  supervisor (Supervisor::tick). Neither is a member, and the module does not
  run either internally — tinybus_module/mod.rs's setup() builds the service,
  serves it, requests the name and returns. Its lazy = false comment ("a host
  that loaded this module wants its servers connected") is aspirational; nothing
  implements it. The supervisor's probe_alive liveness check has no wire
  equivalent either, so a host-side reimplementation over Status polling would
  be strictly worse than what it replaces.
• A member returning ConnectedServerOverview. The type is exported by
  tinymcp-bus but nothing on the interface returns it — an exported type with no
  wire path. The orchestrator prompt and the agent tool registry both read it, and
  composing it from Status + InstalledList + N × ListTools is an N+1.

Types the contract does not publish

• ServerDetail (returned by RegistryGet, SetupGet, ConfigAssist) is defined
  inside tinymcp/src/tinybus_module/service.rs.
• AuthDetection / AuthKind (returned by DetectAuth) live in
  tinymcp/src/registry/oauth/types.rs.

Four of the 28 members return types a host cannot name. They are decodable with
hand-written mirror structs, which is exactly the "parallel type set with no
check" that tinymcp-bus's own module docs forbid.

Smaller, but each one real

• registry::curation::{tag_official, float_official_first} — applied host-side
  after a search; not in the contract, and RegistrySearch deliberately does not
  apply them ("applied by crate::registry::curation on top of this, by a caller
  that wants them").
• render_tool_result and redact_endpoint — both in tinymcp::transport, not in
  the contract. gitbooks consumes result.rendered; StaticCallTool returns the
  raw reply only.
• src/core/observability.rs's classifies_mcp_connect_401_as_needs_auth is a
  live test anchored on tinymcp::Error::Unauthorized's Display.
  tinymcp-bus exports no error type, so the classifier's coupling would become an
  untethered string literal — the wording-drift leak AGENTS.md specifically says
  this test exists to prevent.

And one architectural item, which is the largest

mcp::host keys a HashMap<PathBuf, McpHost> by workspace, one store per
workspace. A loaded module receives one data_dir in its load-time config
blob. This is not a test-only concern: login rewrites the active-user marker and
reloads config in-process (desktop::app_state::ops::activate_revalidated_user_dir),
moving workspace_dir from users/local to users/<id>, and logout reverses it —
so an ordinary desktop session opens at least two. Without a per-data_dir object
seam of the shape modules::memory already uses (Open(dir) -> object_path), a
post-login RPC would be answered silently from the pre-login store.

What is in this PR

• TINYMCP in src/openhuman/modules/registry.rs, pinning v0.3.1 with digests
  taken verbatim from the release's checksum.toml for the eleven host keys
  platform::candidates_for can ask for (the fedora/archlinux archives the release
  also publishes are ignored, since nothing asks for them). LoadPolicy::Lazy —
  a host that never dials an MCP server should not pay a download and a dlopen;
  the doc comment says why that differs from the module's own lazy = false hint.
• The Cargo.toml comment above the dependency, replaced with what is actually
  true and what actually blocks.
• AGENTS.md's mcp gate scope note, extended rather than rewritten: the old
  "sheds zero dependencies" finding stands, and the new measurement showing the
  module extraction does not change it is added beside it.
• The dated scripts/kernel-floor.limits History entry described above.

Known follow-up, not silently dropped

src/openhuman/modules/mcp.rs (the host call client) and the move of
src/openhuman/mcp/** onto it are not in this PR. Writing a client whose
"every declared member is called by this client" test forces calls to members
whose reply types cannot be named would mean inventing the twin types the contract
forbids, and would trade compile-time failures for MemberNotFound at runtime —
the failure mode AGENTS.md already documents for the memory module.

One more thing worth fixing upstream while the release is being re-cut: the v0.3.1
archives contain libtinymcp.so, but modules::ops::platform_library_name expects
libtinymcp_module.so. Downloads still work (tinybus finds the library itself),
but the warm-start installed_artifact fast path never matches, so the module
re-downloads on every process start.

Verification

• GGML_NATIVE=OFF cargo check --no-default-features --features mcp — clean
• GGML_NATIVE=OFF cargo check --no-default-features (the disabled build, the only
  stub-drift catcher) — clean
• cargo test --lib over openhuman::modules::registry — 9/9, including
  object-path derivation, lowercase-hex digests, archive naming, version-in-name,
  the tag URL, and full host-key coverage
• cargo test --lib --features "$(bash scripts/ci/product-features.sh)" --no-default-features
  over openhuman::mcp:: + openhuman::modules:: — 266 passed, 0 failed
• cargo test --lib --no-default-features core:: (the disabled-build test suite,
  which CI's smoke lane does not run) — 574 passed, 0 failed
• scripts/check-kernel-floor.sh — passes at 286/268/2
• node scripts/ci/check-feature-forwarding.mjs — passes
• cargo fmt --check — clean

scripts/dep-sim.py --cut-nothing --expect-names 268 in the Feature-Gate Smoke
lane is deliberately not touched. That number moves whenever
scripts/kernel-floor.limits does, and neither moves here, because this PR sheds
nothing — the -1 arrives with the PR that actually cuts the path dependency.
(#5688 takes it to 269 for tinyjuice-bus; on a conflict keep both history lines
and let whichever lands second reconcile the number.)

Conflicts

PR #5688 (module-bus-wiring, the tinydocs/tinyvoice/tinyjuice/tinyruntime batch)
is in flight and touches Cargo.toml, src/openhuman/modules/registry.rs,
scripts/kernel-floor.limits and AGENTS.md. Conflicts are expected and resolve
by keeping both sides. Note #5688 raises the flows floor to 287/269/2 for
tinyjuice-bus; whichever lands second should keep both History entries and take
the lower limit line.

[tinysweeper]

tinysweeper found nothing blocking. Approving.

$0.0000 · 0 in / 0 out · 922 embedded · openrouter/openai/text-embedding-3-small

[senamakel]

Upstream requirements filed as tinyhumansai/tinymcp#4 — the members, types and the per-data_dir seam that have to land and be released before the path dependency can be cut.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 2d0f7aac-3d58-43be-affd-812bc87190fb

📥 Commits

Reviewing files that changed from the base of the PR and between c79adfd and 757a573.

📒 Files selected for processing (4)

• AGENTS.md
• Cargo.toml
• scripts/kernel-floor.limits
• src/openhuman/modules/registry.rs

Included review availability: Your plan provides up to 10 included reviews per hour; 8 remain after this review.

---

📝 Walkthrough

Walkthrough

The PR adds a lazily loaded TINYMCP registry entry for pinned v0.3.1 artifacts across supported platforms. It updates dependency documentation with measured results, shared dependencies, and remaining tinymcp-bus integration requirements.

Changes

tinymcp registry and dependency documentation

Layer / File(s)	Summary
Register the pinned tinymcp module src/openhuman/modules/registry.rs	Adds the lazily loaded TINYMCP module record with platform archives, SHA-256 digests, and registration in ALL.
Document dependency-floor results AGENTS.md, Cargo.toml, scripts/kernel-floor.limits	Documents the unchanged dependency profile, measured tinymcp removal effect, shared reqwest and rusqlite dependencies, and pending tinymcp-bus APIs and seams.

Estimated code review effort: 2 (Simple) | ~10 minutes

Merge Risk: 🔵 Low · up to 757a5

The PR makes TINYMCP available for explicit native-module loading while retaining lazy loading and artifact integrity checks. Authorization for callers that can request the module and use its interface is not established, so the change is mergeable with explicit owner awareness and follow-up on those permission boundaries.

Suggested reviewers: al629176

Poem

A rabbit pins the module tight,
With hashes neat and versions right.
The dependency trail stays in view,
While upstream bus work waits its cue.
“Hop!” says the registry, “v0.3.1 is true.”

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	Docstring check was indeterminate for this PR — some files could not be analyzed in time. Not blocking.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly identifies the pinned tinymcp v0.3.1 module and the corrected dependency impact of the extraction.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}