chore(spec): propose unified MCP tool_registry .tri upstream in t27 #7

chore(spec): propose unified MCP tool_registry .tri upstream in t27

Info-drop, async-only.

Context

We drafted a .tri specification for a unified MCP tool registry: a small SSOT for Tool { name, version, args_schema, returns_schema, side_effect_class } that any MCP server can consume.

The spec lives at gHashTag/t27 under specs/mcp/tool_registry.tri (ring-105-004). A rust STUB target is planned as gen/rust/tool_registry.rs (auto, no hand-edit).

Intent: schema-first, so that a downstream MCP server (including trios-mcp) can align its tool descriptors with the SSOT before any code lands.

Three optional questions

1. Are the side_effect_class values (pure / read / write / net / exec) aligned with the tri-flavoured MCP convention used in trios-mcp, or should they be renamed?
2. Should args_schema reference a JSON Schema string, or a first-class .tri type node?
3. Is there an existing trios-mcp issue tracking a shared tool schema, to avoid duplication?

References

• specs at gHashTag/t27 (ring-105-004)
• GoldenFloat preprint arXiv:2606.05017

No ask.