Skip to content

chore(deps): bump mcp-toolsets-runtime to 0.10.2 - #44

Merged
ciaransweet merged 1 commit into
mainfrom
chore/runtime-0.10.1
Sep 21, 2026
Merged

ciaransweet merged 1 commit into
mainfrom
chore/runtime-0.10.1

Conversation

@ciaransweet

@ciaransweet ciaransweet commented Sep 21, 2026 •

Copy link
Copy Markdown
Contributor

Moves the template to mcp-toolsets-runtime 0.10.2, and to the @developmentseed/mcp-view release that ships with it.

Pins

  • Root pyproject.toml: >=0.9.0,<0.10.0 → >=0.10.2,<0.11.0, uv.lock relocked.
  • toolsets/stac-explorer/ui: @developmentseed/mcp-view ^0.2.0 → ^0.10.2. Its ext-apps 2.0.0 dependency drops the server half of the MCP SDK, so the lockfile loses about 1,100 lines. tsc --noEmit and ./scripts/build-views are clean.

Nothing here needed wiring: the chat is mcp_agent_api.app, so it picks all of this up by being upgraded.

What 0.10.x brings

  • The agent can ask the visitor a question. It calls an interrupt tool and the page shows the question with its options; the answer resumes the same turn. On by default; MCP_AGENT_INTERRUPT_GATE=0 leaves the tool out.
  • One run per thread. Two windows on one conversation could previously answer over each other and lose a turn. The second is now refused, and the page waits for the other window's answer and shows it, keeping what was typed. How far the lock reaches follows MCP_AGENT_CHECKPOINT: the process in memory, every replica on PostgreSQL.
  • GET /connections is answered per caller. The keys panel asks only for what the request does not already carry, so a header an auth proxy adds, or one the deployment holds, is no longer asked for again.
  • 0.10.2 fixes the scaffold (runtime#154, raised from this work): mcp-toolset new --with-ui wrote mcp-view ^0.1.0 into every new UI. It now writes the version of the runtime that scaffolded it, so a toolset added to this repo starts on the bridge that matches the pin.

Docs

  • The hosted-chat section states the three above.
  • The per-user credentials section said /connections only reported whether the deployment held a value; it now describes the per-caller answer.
  • The runtime table and upgrade note name mcp-toolset skill, which prints the path to the authoring skill inside the wheel.

The authoring skill, read not copied

0.10.0 ships an authoring skill in the wheel. mcp-toolset skill --install would copy it to .claude/skills/writing-mcp-toolsets/ with a pointer in AGENTS.md, but a copy here is runtime content this repo does not own and would go stale at the next bump. README.md and CLAUDE.md instead name uv run mcp-toolset skill, which prints the path in the installed wheel, so what an agent reads always matches the pin.

Checks

./scripts/lint and ./scripts/test (50 passed) clean, plus tsc --noEmit and ./scripts/build-views.

🤖 Generated with Claude Code

ciaransweet added a commit to developmentseed/mcp-toolsets-runtime that referenced this pull request Sep 21, 2026
…154)

`mcp-toolset new --with-ui` wrote `"@developmentseed/mcp-view":
"^0.1.0"` into every scaffolded UI, and had done since 0.1.x. A caret
range on `0.1.0` resolves within `0.1.x`, so a toolset scaffolded today
started eight minor releases behind the runtime that serves it — without
the content sizing from #149, and on the pre-2.0 `ext-apps`.

## Change

The bridge is published from this repo in the same version as the wheel,
so the scaffold reads its own installed version rather than carrying a
literal:

```python
"@developmentseed/mcp-view": "__MCP_VIEW__",   # rendered as ^0.10.1 today
```

Only the release triple is used, so a local build whose version carries
a `.devN` or `+local` suffix still names a range npm has published.

## Why not release-please

The other three version-carrying files are rewritten by release-please,
but its generic updater needs an `x-release-please-version` comment on
the line, and this line lives inside a JSON template — the comment would
land in every scaffolded `package.json`. Reading the installed version
needs no release wiring and cannot drift.

## Tests

- `mcp_view_range` returns `^0.10.1` for `0.10.1` and `^0.11.0` for
`0.11.0.dev3+g1a2b3c`.
- The scaffold test now asserts the written `package.json` carries that
range, so a literal cannot come back.
- 564 passed, 6 skipped; lint clean.

Found while bumping
[mcp-toolsets#44](developmentseed/mcp-toolsets#44),
whose own view was still on `^0.2.0`.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
@ciaransweet ciaransweet changed the title chore(deps): bump mcp-toolsets-runtime to 0.10.1 chore(deps): bump mcp-toolsets-runtime to 0.10.2 Sep 21, 2026
The runtime pin moves from >=0.9.0,<0.10.0 to >=0.10.2,<0.11.0, and the view
bridge from ^0.2.0 to ^0.10.2, which ships with it. ext-apps 2.0.0 drops the
server half of the MCP SDK, so the view's lockfile loses about 1,100 lines.

What the chat gains, all of it by upgrading and none of it wired here:

- the agent asks the visitor rather than guessing, with an `interrupt` tool
  the page draws as a question; MCP_AGENT_INTERRUPT_GATE=0 leaves it out
- one run per thread, so two windows on one conversation no longer answer
  over each other; the reach of the lock follows MCP_AGENT_CHECKPOINT
- /connections is answered per caller, so the keys panel asks only for what
  the request does not already carry
- 0.10.2 scaffolds a new toolset's UI against the runtime's own version, so
  `mcp-toolset new --with-ui` no longer writes mcp-view ^0.1.0

README says the first three in the hosted-chat section, and corrects what the
per-user credentials section said about /connections.

0.10.0 also ships an authoring skill in the wheel. README and CLAUDE.md name
`mcp-toolset skill`, which prints its path, and say to read it there: a copy
in this repo would be runtime content this repo does not own, and would go
stale at the next bump.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@ciaransweet
ciaransweet merged commit d4aa079 into main Sep 21, 2026
11 checks passed
@ciaransweet
ciaransweet deleted the chore/runtime-0.10.1 branch September 21, 2026 10:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant