Move MCP plugin to temporalio.mcp

[brianstrauch]

Summary

• move the temporalio-mcp import root from temporalio.contrib.mcp to temporalio.mcp
• change registered Activity names from temporalio.contrib.mcp.<server>.<operation> to temporalio.mcp.<server>.<operation>
• update package metadata, smoke imports, tests, and documentation
• enforce temporalio.<name> as the root API for release-ready Python plugins

An upstream-backed migration may retain temporalio.contrib.<name> only while final releases are disabled. This narrow transition exception keeps the current OpenAI Agents import valid until #23 completes its cutover.

Breaking change

This is intended for temporalio-mcp 0.2.0 and deliberately provides no compatibility shim for the 0.1.x import path or Activity names.

Workflows started with 0.1.x histories may contain scheduled Activity types under the old prefix. They must finish on 0.1.x workers before those workers upgrade to 0.2.0.

temporalio-mcp 0.1.0 remains published and is not currently yanked.

Release sequence

1. Merge this PR.
2. Publish temporalio-mcp 0.2.0 through the normal release workflow.
3. Update the OpenAI Agents cutover branch to require temporalio-mcp>=0.2.0,<0.3 and import temporalio.mcp.

Validation

• make sync && make format && make lint && make test && make build
  • 40 passed
• wheel and sdist ownership/metadata checks
• repository conventions
• tooling tests: 94 passed
• root-API convention tests: 18 passed

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[DABH]

Ultrareview verdict: requesting changes. I reviewed the exact head, audited the existing discussion, ran the canonical package/tooling checks, inspected the wheel and sdist, and exercised the upgrade path from the published 0.1.0 package. The package rename itself is clean and all ordinary checks pass, but the durable-name change has a reproducible history-compatibility failure.

Blocking findings are inline:

1. Keep the persisted Activity type compatible, or implement a genuinely versioned migration and replay a captured 0.1 history. I reproduced TMPRL1100 by running a 0.1 workflow and replaying its history at this head.
2. Bring the documented new-plugin scaffolder/template into agreement with the new top-level-root invariant.

If the Activity-name break is deliberately retained, the 0.2 drain/migration warning must be restored to a distributed artifact. The PR body is not shipped on PyPI, and release_tool.py derives notes from commit subjects; the generated note would only say Move MCP plugin to temporalio.mcp. The applied author suggestion that deleted the README warning is therefore sound only if the durable names stay compatible.

There is also a small convention-test gap inline. As a nonblocking robustness cleanup, root_api in {...} currently raises TypeError for a malformed list/dict value rather than reporting a convention error; guard it as a string before the membership test.

Cross-PR sequencing: after this is fixed and MCP 0.2 is published, #23 still needs a rebase/update to temporalio-mcp>=0.2,<0.3, temporalio.mcp imports, the new Activity-prefix decision, and #24's stricter convention policy. Its current green CI uses MCP 0.1 and does not validate that state.

Validation completed locally: make sync, make lint, make test (40 passed), make build, wheel/sdist ownership and isolated smoke checks, tooling tests (94 passed), repository conventions, and git diff --check. GitHub CI is green. Copilot did not produce a review (quota exhausted); the only prior inline thread was the author's already-applied README deletion.

[DABH]

Blocking — preserve the durable Activity type across the import rename. I installed published temporalio-mcp==0.1.0, ran TemporalMCPClient("probe").list_tools() against the embedded server, captured the completed history, then replayed it at this head. Replay fails with [TMPRL1100] Nondeterminism error: Activity type of scheduled event 'temporalio.contrib.mcp.probe.list-tools' does not match activity type of activity command 'temporalio.mcp.probe.list-tools'. This affects every open 0.1 workflow that has scheduled an MCP operation, and a new-only worker also cannot service pending old Activity types. The module root and the persisted protocol name do not need to match, so the simplest safe fix is to keep temporalio.contrib.mcp.* as the durable name and add a captured 0.1 replay fixture. Otherwise this needs workflow patching/versioning plus both worker registrations; dual registration alone does not make replay deterministic.

[brianstrauch]

We actually want to make a breaking change here

[DABH]

If the persisted Activity names remain intentionally breaking, please restore the deleted 0.2 migration warning here. The PR body is not part of the installed/PyPI documentation, and the automated release notes contain only commit subjects, so users otherwise get no warning that upgrading workers can make existing histories nondeterministic. This comment is moot if the durable prefix is kept stable.

[brianstrauch]

We plan on yanking 0.1.0, so we don't need this warning.