* fix(client): clean up sandbox message listener and cancel readiness wait on unmount in ViewRenderer (#2421)
* fix(client): clean up sandbox message listener on unmount and add timeout in ViewRenderer
* fix(client): avoid early handshake promise rejection on blob fetch abort and verify timeout listener cleanup
* fix(client): tie ViewRenderer sandbox readiness wait to effect lifecycle and clean up on unmount
* refactor(client): support optional timeoutMs in waitForSandboxProxyReady and add timeout unit tests
* test(client): add ViewRenderer default 15s timeout integration test
* refactor(client): remove sandbox readiness timeout and verify exact listener teardown
* chore: enter canary prerelease mode
* chore(typescript): version packages (canary)
* fix(server): report a malformed verifier resource as configuration (#2412)
createJwtVerifier canonicalizes options.resource with canonicalUrl, the
same helper used for the resource claim carried by a token. That helper
raises invalidToken, so misconfiguring the server throws an OAuth
invalid_token error at construction, complaining about a token resource
claim when no token exists yet. oauthCustomProvider validates the same
option with a TypeError.
Validation now happens in configuredResourceUrl, which applies the same
URL rules and reports a config problem as TypeError.
Deliberately not normalizedProviderUrl, which the first revision used:
that helper prefixes https:// onto a scheme-less string. Right for a
provider domain, wrong here, because it would have accepted
"api.example.com/mcp" from a JavaScript caller that the URL type does not
constrain. Which URLs are accepted is therefore unchanged from before
this PR; only the error type and message move.
canonicalUrl now only ever sees a token claim, so it takes a string.
* chore(typescript): version packages (canary)
* fix(tunnel): default localHostHeader to localhost in standalone mcp-tunnel CLI (#2456)
* fix(tunnel): default localHostHeader to localhost in standalone mcp-tunnel CLI
* fix(tunnel): drop redundant --local-host-header alias and document Host rewriting
* fix(tunnel): drop --local-host CLI flag per maintainer review while keeping localhost default
* docs(tunnel): document forwarded Host: localhost default and x-forwarded-host in README
* chore(typescript): version packages (canary)
* fix(cli): warn on env set secret downgrade, document --secret required on every write (#2423)
* fix(cli): preserve sensitive flag on env update when --secret is omitted
* refactor: simplify sensitive flag expression per review feedback
* fix(cli): warn on env set secret downgrade, document --secret required every write
* chore: remove stale changeset describing reverted behavior
* fix(cli): tighten env set messages and drop downgradedFromSecret per review
* refactor(cli): drop env set downgrade detection, keep help and docs clarification
Scope the change to help text, docs, and the success message. The success
message now depends only on whether --secret was passed on this invocation.
Write semantics and JSON output are unchanged.
* chore(typescript): version packages (canary)
* fix(client): stabilize useMcp configuration dependencies to prevent reconnection loops (#2403)
* fix(client): stabilize useMcp configuration dependencies to prevent reconnection loops
* test(client): expand array comparison and clientOptions stability test coverage
* feat(client): trigger reconnection in useMcp when headers or clientOptions change
* refactor(client): scope useMcp stability to clientInfo and proxyConfig
* fix(client): preserve absent vs empty icon fields and normalize proxy headers
* fix(client): preserve raw proxyConfig and strengthen useMcp stability and transition tests
* fix(client): return shallow copy in clientInfo and proxyConfig useMemo callbacks
* test(client): remove oversized integration test file and retain focused helper tests
* chore(typescript): version packages (canary)
* fix(cli): report a malformed JSON argument as a usage error (#2444)
parseMcpArguments raises a clean UsageError for a key=value grammar
mistake and for JSON that parses but is not an object, then lets the
engine's own SyntaxError escape for JSON that does not parse at all.
$ mcp-use client probe tools call foo '{bad json'
Expected property name or '}' in JSON at position 1 (line 1 column 2)
exit 1
Exit 1 is the operational-failure code, so a typed command line is
reported as an API or runtime problem, and the message says nothing about
which argument was wrong. That matters most for the key:=<json> form,
where one token out of several is at fault.
Both parses now go through a helper that names the argument and raises
UsageError, so they exit 2 like every other grammar mistake in the same
function.
The parse runs during argument validation, before the client connects, so
this is reachable without a reachable server.
* chore(typescript): version packages (canary)
* fix(cli): validate servers list pagination before authenticating (#2448)
* fix(cli): validate servers list pagination before authenticating
servers list creates the cloud client and then validates --limit and
--skip, so signed out the check never runs:
$ mcp-use servers list --limit 0
Not logged in. Run `mcp-use login`. exit 1
deployments list takes the same two options and reports them properly,
because it validates first:
$ mcp-use deployments list --limit 0
--limit must be an integer from 1 to 100. exit 2
Moving the call above cloudApiForOrganization makes the two agree, and
stops the command reaching for credentials to run something that cannot
run either way.
* test(cli): cover the --skip message in the validate-before-auth case
parsePagination raises a distinct message for --skip, and the fix moves
both checks ahead of the cloud client, so both deserve coverage. Reverting
servers.ts to the canary ordering now fails two tests rather than one.
* chore(typescript): version packages (canary)
* fix(client): coalesce concurrent connector operations and prevent process leaks (#2458)
* fix(client): coalesce concurrent connector operations and prevent process leaks
In @mcp-use/client, BaseConnector delegated connect() to subclasses with only
a synchronous `if (this.connected)` guard. Because this.connected was only
set after child process spawning, transport creation, and protocol handshakes:
1. Concurrent connect() calls on StdioConnector instantiated multiple
StdioConnectionManager instances, spawning duplicate OS child processes
and overwriting this.connectionManager. The first child process was
abandoned and leaked permanently in the OS.
2. Concurrent connect() calls on HttpConnector overwrote transport and client
references, causing partial teardowns mid-flight on failure or leaking
SSE sessions.
3. Invoking disconnect() while connect() was in flight saw !this.connected
and returned immediately as a no-op, leaving the connection and its
underlying resources permanently open after connect() settled.
4. Concurrent disconnect() calls issued racing duplicate calls to
cleanupResources().
This moves lifecycle synchronization directly into BaseConnector:
- Coalesce concurrent connect() calls using an internal connectPromise.
- Coalesce concurrent disconnect() calls using an internal disconnectPromise.
- When disconnect() is called while connect() is in flight, await the in-flight
connection attempt before tearing down resources so nothing is orphaned, and
prevent the connector from marking itself connected.
- When connect() is called while disconnect() is in flight, wait for teardown
to complete before opening a new connection.
- Subclasses now implement protected establishTransport() without needing to
re-implement connection concurrency guards.
* fix(client): reject in-flight connect when cancelled by disconnect
When disconnect() is initiated while establishTransport() is in flight,
connect() now rejects with 'Connection cancelled by disconnect' instead of
fulfilling. This prevents callers awaiting connect() from assuming the
connection succeeded and then encountering disconnected-state errors on
subsequent operations.
* fix(client): cancel queued reconnects on later disconnect
* chore(client): add patch changeset for connector lifecycle fixes
---------
Co-authored-by: Andrew Khadder <andrew@manufact.com>
* chore(typescript): version packages (canary)
* fix(server): keep upstream resource annotations and _meta when proxying (#2469)
ResourceDefinition carries annotations and _meta, and both survive local
registration. The proxy mount copies only title, description and
mimeType, and ProxyResource does not even declare the other two, so an
upstream resource loses its client hints and its extension metadata the
moment the server is composed with use().
Both are documented on the resource descriptor and neither has a
framework-derived counterpart, unlike a tool's _meta.ui.* keys, which the
server computes from view and visibility. There is nothing to collide
with here, so forwarding is a straight passthrough.
Prompts need no equivalent change: PromptDefinition has no _meta.
* chore(typescript): version packages (canary)
* ci: add CLI mirror workflow to canary
* feat(server): add public chat CTA to landing page (#2496)
* chore(typescript): version packages (canary)
* chore(typescript): use official ext-apps 2.0.0 (#2498)
* chore(typescript): version packages (canary)
* fix(agent): use Responses API for OpenRouter OpenAI models (#2501)
* fix(agent): use Responses API for OpenRouter
* fix(agent): preserve Responses request options and errors
* test(agent): remove OpenRouter Responses coverage
* fix(agent): scope OpenRouter Responses to OpenAI models
* docs(agent): clarify OpenRouter BYOK fix
* fix(agent): preserve direct OpenAI temperature behavior
* chore(typescript): version packages (canary)
* fix(release): propagate bundled Inspector releases and validate peers (#2504)
* fix(release): propagate bundled artifacts and validate published peers
* fix(ci): include release automation in dependency analysis
* chore(typescript): version packages (canary)
* fix(release): allow npm publish-time scanning to finish (#2505)
* chore(release): update changelogs for Inspector and TypeScript packages to reflect recent patch releases and enhancements
---------
Co-authored-by: Rohith Reddy Nama <104615697+rohith500@users.noreply.github.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Ayaan Gazali <ayaangazali.work@gmail.com>
Co-authored-by: aishwary-dongre <87765118+aishwary-dongre@users.noreply.github.com>
Co-authored-by: Enrico Toniato <2827496+tonxxd@users.noreply.github.com>
Co-authored-by: Pietro Zullo <62951181+pietrozullo@users.noreply.github.com>
* fix(create-mcp-use-app): drop the dead --no-git flag from help (#2392)
Scaffolding stopped initializing a git repository in a62db703, but the help
text kept advertising --no-git. parseArgs declares no git option and nothing
reads the flag, so passing it has been indistinguishable from omitting it.
* chore: enter canary prerelease mode
* chore(typescript): version packages (canary)
* fix(client): rebind the OAuth loopback listener after a failed bind (#2393)
* fix(client): rebind the OAuth loopback listener after a failed bind
startLoopback() assigned this.server before listen() resolved, so a bind
failure left a handle that was never listening. The guard at the top of the
method then made every later call return early without binding, and the
caller waited on a dead port until authTimeoutMs expired.
Assign only after a successful bind, and close the server on failure.
* fix(client): keep the loopback handle set while the bind is in flight
Clearing this.server only on failure keeps an overlapping redirectToAuthorization()
and dispose() able to observe the in-flight listener. Assigning after the bind
resolved left a window where both saw null, so two calls could race onto the
same port and dispose() could miss a listener that was still being created.
* test(client): occupy the reserved loopback port instead of a fixed guess
portRange: 1 with an asserted port made the test fail whenever an unrelated
process held the preferred port. Widen the range to match the sibling tests
and bind whatever reservePort settled on.
* chore(client): shorten loopback binding comment
---------
Co-authored-by: Andrew Khadder <andrew@manufact.com>
* chore(typescript): version packages (canary)
* fix(inspector): resolve chat widgets by connection id (#2404)
* chore(typescript): version packages (canary)
* chore(docs): update changelogs for v20.3.5 and v20.3.4 releases
- Added details for v20.3.5, including fixes for chat widgets using the connection id and an update to mcp-use v2.4.1.
- Documented v20.3.4 enhancements, such as request duration display, screenshot failures on initialization, and an update to mcp-use v2.4.0.
---------
Co-authored-by: Mohammed Alkindi <alkndymhmd692@gmail.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Andrew Khadder <andrew@manufact.com>
* fix(cli): isolate dev test cleanup failures (#2337)
* chore: enter canary prerelease mode
* fix(client): project OAuth tokens before ready (#2358)
* docs(python): fix misleading CI badges (#1871) (#1872)
* fix(client): project OAuth tokens before ready
---------
Co-authored-by: AxelRay <raynaldo.axel@gmail.com>
* chore(typescript): version packages (canary)
* feat(inspector): show RPC latency in the timing column (#2349)
* feat(inspector): prioritize RPC latency in traffic rows
* fix(inspector): preserve timestamp semantics
* chore(typescript): version packages (canary)
* docs(cli): add a README so the npm page is not blank (#2350)
* docs(cli): add a README so the npm page is not blank
@mcp-use/cli is the only published package in the family without a
README, and the registry shows it:
$ curl -s https://registry.npmjs.org/@mcp-use%2Fcli | jq -r .readme
""
So npmjs.com/package/@mcp-use/cli renders nothing for the package that
provides the `mcp-use` executable.
The README is deliberately short, because the package is rarely installed
directly: `mcp-use` depends on it and exposes the same bin, which the
existing CLI reference page states and package.json confirms. It covers
what the package is, how it actually reaches users, the command list from
`mcp-use --help`, and links to the v2 CLI reference and quickstart. Both
links resolve with no redirect.
README.md is not in this package's `files` array, but npm always includes
it. Confirmed rather than assumed:
$ npm pack --dry-run
npm notice Tarball Contents
npm notice 1.5kB README.md
* docs(cli): apply review, lead with the client
Review feedback on #2350: mention the built-in MCP client, drop the
paragraph about not installing the package directly, and show
`mcp-use client` in the example.
The example commands are the ones I ran against a local server while
checking the command list: `client connect <name> <url>` then
`client <name> tools list`.
* docs(client): put the sandbox subpath inside the coverage gate (#2353)
`@mcp-use/client` publishes three subpaths and typedoc only inspected
two of them. `./sandbox` was missing from entryPoints, so everything
exported from `src/sandbox.ts` sits outside the gate #2312 turned on.
Not theoretical. Appending an undocumented export to that file and
running `pnpm docs:api`:
without src/sandbox.ts in entryPoints exit 0, no warnings
with it exit 3
sandbox.SandboxProbe (TypeAlias) does not have any documentation
sandbox.SandboxProbe.probe (Property) does not have any documentation
Nothing is undocumented there today. The single export,
buildSandboxProxyBlobHtml, has TSDoc and is also re-exported through
./react, which is why the hole has not shown up yet. This closes it
before it does.
* test(cli): let Windows use native file watching (#2338)
* test(cli): let Windows use native file watching
Experiment requested in #2273. The dev server currently forces chokidar
into 100ms polling on Windows:
...(process.platform === "win32" && { usePolling: true, interval: 100 })
The comment justifies it with Windows notifications being coalesced or
dropped during a transform, and nobody has been able to find an upstream
Vite, Chokidar or Node report for that specific claim.
Polling also makes the initial scan much slower, which is the suspected
cause of the Windows-only `dev.test.ts` timeouts: if the test writes a
file before the scan finishes, the new contents become the polling
baseline and no change event is ever emitted. That failure mode cannot be
fixed by raising a timeout, and it matches the observed signature, a
`waitFor` timeout with no `last error` because the probe never threw.
This removes the override so the Windows CI job runs with native
watching. The point is the CI result, not the diff.
Local run is unaffected, since the override never applied off Windows:
dev.test.ts 34 passed, 34 total.
* test(cli): avoid equal-length watcher update
---------
Co-authored-by: Andrew Khadder <andrew.khadder@gmail.com>
* chore(typescript): version packages (canary)
* fix(dev): consolidate server request logs (#2351)
* fix(dev): consolidate server request logs
* refactor(server): simplify request log formatting
* fix(server): omit clients from HTTP logs
* fix(server): remove request log timestamps
* fix(server): address request logging regressions
* chore(typescript): version packages (canary)
* docs(changelog): update changelogs for v20.3.3 and v12.0.6 releases
- Added details for v20.3.3, including enhancements to RPC latency display and log prefixing for colocated Inspector logs.
- Updated mcp-use to v2.3.4.
- Added details for v12.0.6, highlighting CLI version heading enhancements and documentation fixes.
- Updated mcp-use to v1.34.6.
---------
Co-authored-by: Elioooon <102770919+Elioooon@users.noreply.github.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: AxelRay <raynaldo.axel@gmail.com>
Co-authored-by: Ayaan Gazali <ayaangazali.work@gmail.com>
Co-authored-by: Andrew Khadder <andrew.khadder@gmail.com>
Co-authored-by: Andrew Khadder <54488379+khandrew1@users.noreply.github.com>
* fix(cli): drop the React plugin from the binding-validation server
That server is only created when a project has no views (build.ts calls it
under views.length === 0), so it never has JSX to transform. Loading
@vitejs/plugin-react there pulls react, react-dom and both jsx runtimes into
optimizeDeps, which cannot resolve them because such a project has no reason
to depend on React.
Result was four 'Failed to resolve dependency' lines on the first build of a
fresh scaffold, on 3 of the 4 templates.
react() had no other use in views.ts, so the import goes too.
Closes#2297
* fix(create-mcp-use-app): send "Learn more" to the mcp-use docs (#2328)
* fix(create-mcp-use-app): send "Learn more" to the mcp-use docs
The last line the scaffold prints is:
📚 Learn more: https://manufact.com/docs
That URL no longer reaches mcp-use documentation. It redirects twice and
lands on Manufact's own dashboard docs:
https://manufact.com/docs -> 200 https://docs.manufact.com/dashboard
So someone who has just created an mcp-use server is pointed at a
different product's dashboard guide. The README the same command writes
into the new project points at the mcp-use quickstart instead, so the two
halves of one tool disagree.
Point it at the quickstart, which resolves directly with no redirect:
https://docs.mcp-use.com/v2/typescript/getting-started/quickstart -> 200, 0 hops
The feedback line below it still mentions manufact.com, which is correct:
that one is about where to reach the people, not the docs.
* fix(create-mcp-use-app): use the bare docs host in "Learn more"
Review feedback: docs.mcp-use.com already redirects to the getting-started
page, and the short host reads better in a console message than the full
path.
https://docs.mcp-use.com -> 200 https://docs.mcp-use.com/v2/typescript/getting-started/welcome
* chore: enter canary prerelease mode
* chore(typescript): version packages (canary)
* test(agent): assert in the two tests that assert nothing (#2316)
Two tests in @mcp-use/agent run their subject and then check nothing, so
they pass no matter what the code does. Both say so in a trailing comment.
stream_events.test.ts "should clean up resources on completion" installs
a spy on agent.close(), consumes the stream, and never looks at the spy.
agent-telemetry.test.ts "should track error type on failure" swallows the
error and leaves a comment guessing that telemetry "might not be called".
It is called: the recorded execution carries success false and errorType
"execution_error".
Both assertions were checked in the failing direction against a
deliberately broken source, not just against a passing run:
close() calls in the cleanup paths removed
-> expected "close" to be called at least once
errorType hardcoded to null
-> expected { executionMethod: 'stream', … } to match
object { success: false, errorType: 'execution_error' }
No new test files and no new cases. These are the same two tests, now
able to fail.
* fix(client): disconnect the session createSession replaces (#1964)
* chore(typescript): version packages (canary)
* docs(typescript): enforce the TypeDoc coverage gate the packages already declare (#2312)
* docs(typescript): enforce the TypeDoc coverage gate the packages already declare
Each package's typedoc.json sets validation.notDocumented and
treatWarningsAsErrors, and eslint.config.js states that documentation
coverage "is enforced against each package's public entrypoints by its
strict TypeDoc configuration".
It is not. The only invocation is `pnpm docs:api`, which runs typedoc
with the root typedoc.options.json in packages mode. Validation from the
sub-package configs is applied, but treatWarningsAsErrors is not, so the
command reported 15 coverage warnings and still exited 0.
Set treatWarningsAsErrors in the root options and clear what the gate
then catches:
- Document the members of SkillSnapshotEntry.resources, required by
packages/server/CLAUDE.md and missing.
- Document the members of SkillsListResult, SkillGetResult,
SkillDirectoryEntry and SkillDirectoryReadResult in the client.
- Drop five intentionallyNotDocumented entries for react.UseWidgetResult
and react.UserAgent, neither of which exists in the server source any
more, and the intentionallyNotExported entry for UseWidgetResultBase.
- Add TurbopackConfig to intentionallyNotExported, matching the existing
NextHeaderRule entry for the same pattern in the same file, and
FinishOAuthAuthorization on the client side.
`pnpm docs:api` now exits 0 with zero warnings, and exits 3 again if any
public export loses its documentation.
No changeset: the source edits are doc comments only, with no runtime or
type change to any published API.
* chore(typescript): ignore generated TypeDoc output in eslint
`.typedoc/` is gitignored but not eslint-ignored, so running
`pnpm docs:api` and then `pnpm lint` reports 534 errors from the
generated, minified theme assets. The other generated output
directories are already listed.
* docs(tunnel): bring the fourth package under the same coverage gate
server, client and agent each carry a typedoc.json with
validation.notDocumented and treatWarningsAsErrors. tunnel is in the same
root entryPoints list and had no config at all, so turning the gate on
would have left it as the one published package still unchecked.
Add the matching config and document the three inline members it turns
up, on TunnelManager.start and TunnelManager.status.
* ci(docs): run the documentation checks on canary (#2321)
The Documentation workflow regenerates the API reference, runs
`mint broken-links`, and fails if the committed docs are out of date. It
triggers on `main` and `monorepo`.
`monorepo` does not exist. `git ls-remote --heads origin monorepo` returns
nothing, so that half of the trigger has been dead for a while.
Meanwhile every published package's source lands on `canary` first, and
the workflow never runs there. Checked against the four most recent
canary-targeted pull requests, #2316, #2312, #2309 and #2307: the
"Generate and validate API documentation" check is absent from all of
them, while it runs on main-targeted PRs that touch the same paths.
The practical effect is that documentation drift and broken links are
only caught on the canary-to-main release PR, in one batch, rather than
on the change that introduced them.
Point the trigger at `canary` instead of the branch that is gone. The job
only reads: it regenerates into the working tree and fails if anything
differs. It publishes nothing, so running it on canary is safe.
* docs(cli): remove inaccurate binding server comment
* chore(typescript): version packages (canary)
* fix(inspector): warn when model tool limit is exceeded (#2333)
* chore(typescript): version packages (canary)
* docs: update canary changelogs
* fix: address canary review findings
---------
Co-authored-by: ayaangazali <ayaangazali.work@gmail.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Vihaan Agarwal <vihaan@clique.so>
* feat(client): support RequestOptions for prompt reads (#2302)
* feat(client): support request options for prompts
* Apply suggestion from @cubic-dev-ai[bot]
Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>
Signed-off-by: Andrew Khadder <54488379+khandrew1@users.noreply.github.com>
---------
Signed-off-by: Andrew Khadder <54488379+khandrew1@users.noreply.github.com>
Co-authored-by: Andrew Khadder <54488379+khandrew1@users.noreply.github.com>
Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>
* chore: enter canary prerelease mode
* chore(typescript): version packages (canary)
* feat(inspector): correlate RPC response labels (#2303)
* feat(inspector): correlate RPC response labels
* fix(inspector): refine RPC latency label styling
* chore(typescript): version packages (canary)
* fix(server): restore Claude resource domain hashing in v2 (#2326)
* fix(server): restore Claude resource domain hashing in v2
v1.29.0 rewrote a view resource's `_meta.ui.domain` to
`<sha256(domain)[0..32]>.claudemcpcontent.com` when the reading client
advertised a name containing "claude". The v2 rewrite dropped that along
with the v1 server package, so Claude receives the authored `view.domain`
verbatim and refuses to render the view.
Restore the three helpers in `src/views/claude-domain.ts`. The digest and
the substring match are byte-for-byte the v1 ones, so a server upgrading
from v1 emits the same domain it did before; the v1 fixtures are ported
as unit tests. The digest uses Web Crypto rather than `node:crypto` to
keep the root module graph free of Node builtins for the Workers build.
Client identity reaches the `resources/read` handler through the
per-request `_meta` envelope (`io.modelcontextprotocol/clientInfo`) — the
same source `ctx.client.info()` already reads, extracted as
`requestClientInfo()` in `src/context.ts`. Non-Claude clients, an
already-hashed authored domain, and `resources/list` are all unchanged,
matching v1.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BAiXkmFngnfwhAeNuDbFKg
* docs(v2): drop the stale per-client View metadata limitation
The v2 migration guide's beta-limitations list stated that "v2 has no
supported hook for rewriting `domain` or other View resource metadata per
client". Restoring the Claude resource domain hashing makes that false —
`_meta.ui.domain` is now derived per requesting client on `resources/read`.
Remove the bullet outright rather than softening it. The rest of the Views
limitations list is unaffected and reads cleanly without it; the
`resources/list` and authoring surfaces it also described are covered by
the resource-facts guidance earlier in the same guide.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BAiXkmFngnfwhAeNuDbFKg
* fix(server): detect legacy Claude clients by user agent
* fix(server): lazy-load the Claude domain helper to stay under the edge budget
`tests/budgets/cli-budget.test.ts` caps the edge entry's static graph at
120 KiB. Statically importing `views/claude-domain.js` from `server.ts` put
the graph at 123061 bytes, 181 over the cap, failing CI on this branch
(`main` sits at 121721, so the branch consumed all 1159 bytes of headroom).
The `resources/read` callback is already async, so the helper loads through
a dynamic import at its one call site instead, matching the lazy-loading the
same budget test enforces for the CLI commands. The re-export from
`views/index.ts` is dropped so the module leaves the static graph; the unit
tests already import it from `views/claude-domain.js` directly. Behavior is
unchanged — the user-agent fallback and the hash are untouched.
Edge static graph: 123061 -> 122208 bytes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BAiXkmFngnfwhAeNuDbFKg
* fix(server): keep Claude domain helper in edge graph
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Andrew Khadder <andrew@manufact.com>
* chore(typescript): version packages (canary)
* docs: update TypeScript release changelogs
---------
Signed-off-by: Andrew Khadder <54488379+khandrew1@users.noreply.github.com>
Co-authored-by: WeiHaoxuan <156066259+Whxuan0701@users.noreply.github.com>
Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: Claude <noreply@anthropic.com>
* fix(agent): count Anthropic cache tokens and stop message_delta erasing usage (#2127)
* fix(agent): count Anthropic cache tokens and stop message_delta erasing usage
Two counting bugs on the Anthropic path, both silent.
Anthropic reports `input_tokens` net of the prompt cache and bills
`cache_read_input_tokens` and `cache_creation_input_tokens` separately, so
`input_tokens + output_tokens` is not what the call is charged on. It never sends
`total_tokens`, so the computed branch is always the one that runs. A call billed on
21,623 tokens reported 123. `cache_creation_input_tokens` was not read anywhere in the
repository, and Anthropic bills cache writes above the base rate.
OpenAI is the opposite: its `cached_tokens` sits inside `prompt_tokens`, so adding it
would double count. Only the Anthropic-shaped keys are summed, and a test pins that.
Second, `tokenUsageFromRecord` returns every key and sets the ones it did not find to
`undefined`. Anthropic's streaming `message_delta` carries `output_tokens` only, so
`usage = { ...usage, ...deltaUsage }` overwrote `inputTokens` and `cachedInputTokens`
with `undefined`, discarding what `message_start` had already reported. After any
streamed call the whole input side of the accounting was gone, with nothing raised.
`mergeTokenUsage` merges only defined values. It does not touch `totalTokens`, because
whether a cache counter is additive is a provider question and that information is gone
once usage has been normalised, so the caller owns the total.
Three of the added tests fail on main.
* fix(agent,inspector): one owner for the Anthropic total, and stop the inspector dropping cache
Follow-up on the review. Four points were raised; three were right and are fixed, one
would have introduced a bug and the reasoning is below.
The same wrong total existed in a third place. `message_stop` recomputed it as
`inputTokens + outputTokens`, so the fix at `message_delta` survived only because `??`
short-circuited on the total already set. Two places knowing how Anthropic bills is how
this drifts, so `message_stop` now owns it alone and `message_delta` just merges. Added an
end-to-end test that drives real `message_start` then `message_delta` SSE through
`streamChat`, rather than exercising `mergeTokenUsage` in isolation. On the base commit it
reports `totalTokens: undefined`, not merely a wrong number, because the input counters
were gone by the time `message_stop` ran.
The inspector was dropping more than the new field. `InspectorTokenUsage` declares
`cachedInputTokens` and `reasoningTokens`, the trace view reads them, and
`inspectorTokenUsageFromUnknown` returned only `inputTokens`, `outputTokens` and
`totalTokens`. Both have always rendered as absent whatever the provider sent. It also
repeated the same input-plus-output total. Both fixed, and `cacheCreationInputTokens` is
carried through.
The merge test now seeds `cache_creation_input_tokens` too, since cache writes are billed
above base rate and need the same protection as cache reads.
Not done, deliberately: adding `cachedInputTokens` to the computed total inside
`tokenUsageFromRecord`. On Anthropic that counter sits outside `input_tokens`; on OpenAI
`cached_tokens` sits inside `prompt_tokens`. Once usage is normalised that distinction is
gone, so summing it would double count OpenAI. Only the Anthropic-shaped keys are added,
and a test pins the OpenAI case at 14.
* style(inspector): run prettier on trace.ts
format:check fails the typescript-lint job on this one file. Prettier wraps
the cachedInputTokens call across three lines, the way the two calls below it
already are. Formatting only, no behaviour change.
* fix(inspector): aggregate cacheCreationInputTokens and stop double-counting OpenAI cache reads
Addresses @khandrew1's review on #2127.
addUsage dropped cacheCreationInputTokens: the field was parsed onto individual
usage events but never summed, so it vanished from state.usage, the LLM span's
usage, and the aggregate tokenUsage in the raw-chat payload. It is now summed
alongside the other counters.
The fallback total could also over-count. uncountedCache was built from the
provider-neutral cachedInputTokens, but on OpenAI those tokens are already inside
inputTokens, so { inputTokens: 10, outputTokens: 4, cachedInputTokens: 3 }
totalled 17 instead of 14. The total now adds only the Anthropic-shaped
cache_read_input_tokens, mirroring the provider-safe path in agent/src/llm/usage.ts.
cachedInputTokens is still parsed and returned for observability.
Two tests in trace.test.ts pin both: the OpenAI-vs-Anthropic total distinction,
and that cacheCreationInputTokens survives aggregation and the LLM span. Changesets
added for @mcp-use/agent and @mcp-use/inspector.
* chore: enter canary prerelease mode
* chore(typescript): version packages (canary)
* fix(inspector): scope loading state by chat session (#2232)
* fix(inspector): give each chat session one id and one state record
Chat state lived in hook-wide React state, so starting a new chat cleared
the values an in-flight stream was still writing to: the fresh chat
inherited the previous session's loading state and could not send.
Rework it around a single identity. A session is created with one id and
keeps it; that id is handed to ChatStorageProvider.createChat, so runtime
state, chat history and OAuth retry all name the same chat. All of a
session's state and turn machinery live in one record inside
ChatSessionStore, which notifies only the subscribers of the session that
changed, so a background turn keeps streaming into its own record.
useChatSessions owns the lifecycle: minting ids, activating a session,
reattaching to persisted chats, and reopening the session a full-page
OAuth redirect interrupted. New Chat now only switches the active id.
Closes#2217
* refactor(inspector): simplify chat session state
* fix(inspector): harden chat session recovery
---------
Co-authored-by: Andrew Khadder <andrew@manufact.com>
* chore(typescript): version packages (canary)
* fix(ci): give inspector tests the same timeout as every other package (canary) (#2290)
* fix(ci): give inspector tests the same timeout as every other package
Same one-line change as #2268, which targets main. canary carries the same
10s cap and is failing on it independently:
run 32053629834 compressed-assets.test.ts 10230ms Test timed out in 10000ms
run 32051250836 same test
main is red on it too (run 32054211669). Recent margins are 10029ms, 10230ms
and 10837ms, all just over the cap.
The inspector is the only package at 10s; agent, client, cli and server all
use 60000, and these cases mount a server and decompress the bundled app.
45 files, 217 tests still pass locally.
* chore(ci): remove timeout rationale comment
---------
Co-authored-by: Andrew Khadder <andrew@manufact.com>
* feat(oauth): add Scalekit provider (#2272)
* feat(oauth): add Scalekit provider
Add oauthScalekitProvider next to Auth0 and Clerk. The verifier accepts
both environment-root and resource-scoped issuers, binds audience to the
res_… resource id, and advertises DCR plus CIMD. No Scalekit SDK.
* fix(oauth): keep Scalekit resource-id audience with extra aud
Always verify aud includes the resource id. Optional audience is an extra
AND check, not a replacement. Drop the new v1 provider page.
* fix(oauth): drop Scalekit issuerBoundAccessTokens option
Scalekit binds tokens to the resource id. The dashboard will own
that opt-in. Keep the static oauthMetadata copy because mcp-use
requires it. Custom claims stay on ctx.auth.payload.
* docs: drop v1 and legacy skill changes
* docs: fix Scalekit environment variables
---------
Co-authored-by: Saif Shines <saifshine7@gmail.com>
Co-authored-by: Andrew Khadder <andrew@manufact.com>
* chore(typescript): version packages (canary)
* fix(inspector): add a test script so pnpm test covers this package (#2289)
* fix(inspector): add a test script so pnpm test covers this package
The root test script is `pnpm run -r test`, and the inspector only had
test:unit. pnpm skips a package with no matching script and reports nothing,
so 217 unit tests were absent from the workspace-wide run:
$ pnpm --filter @mcp-use/inspector test
(no output)
$ pnpm --filter @mcp-use/inspector test:unit
Test Files 45 passed (45)
Tests 217 passed (217)
CI is unaffected; its step calls test:unit directly. This is the documented
`pnpm test` contributors run.
Uses run mode rather than watch, matching tunnel, so a recursive run cannot
sit waiting on a watcher.
* chore(inspector): remove test-only changeset
---------
Co-authored-by: Andrew Khadder <andrew@manufact.com>
* fix(types): align pnpm workspace tooling (#2301)
* docs: update TypeScript release changelogs
* fix(inspector): use secure chat session ids
---------
Co-authored-by: Arthi Arumugam <62213284+arthi-arumugam-git@users.noreply.github.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Mert Çetin <97505365+merttcetn@users.noreply.github.com>
Co-authored-by: Ayaan Gazali <ayaangazali.work@gmail.com>
Co-authored-by: saif-at-scalekit <saif.shaik@scalekit.com>
Co-authored-by: Saif Shines <saifshine7@gmail.com>
* feat(client): support mixed OAuth servers
* fix(inspector): pause mixed-auth tool calls
* Revert "fix(inspector): pause mixed-auth tool calls"
This reverts commit 9bac9ddfe7.
* chore: finalize mixed OAuth changeset
* docs: explain mixed OAuth client flows
* fix: bound mixed auth metadata discovery
* docs(server): add runnable mixed oauth example
* fix(inspector): recover stale local connections
* fix(inspector): resume tools after mixed auth
* fix: address mixed auth review feedback
* fix(inspector): scope mixed auth retries
* test(inspector): remove jsdom-only regressions
* chore: enter canary prerelease mode
* chore(typescript): version packages (canary)
* fix(inspector): stream v2 subscription acknowledgements
* fix(client): discover mixed auth after ready
* test(client): preserve mocked connection compatibility
* fix(client): defer mixed auth discovery until ready
* fix(client): discover mixed auth after ready paint
* perf(client): expose tools before auxiliary inventories
* fix(client): refresh mixed auth discovery after reconnect
* chore(typescript): version packages (canary)
* fix(client): make codeMode custom executor functions actually work (#2123)
* fix(client): make codeMode custom executor functions actually work
`_ensureCodeExecutor()` handled a function-valued `codeMode.executor` by
assigning `this._customCodeExecutor` and then throwing
"Custom executor function should be handled in executeCode". Since
`executeCode()` read that field *before* calling `_ensureCodeExecutor()`,
and only `_ensureCodeExecutor()` ever populated it, the first
`executeCode()` call always rejected and only the second succeeded.
`searchTools()` had no such fallback, so it rejected on every call --
including via the `search_tools` meta tool on `CodeModeConnector`. Because
`_codeExecutor` stayed null, `close()` also skipped executor cleanup.
Route function executors through a new `FunctionCodeExecutor` adapter so
they participate in the normal executor lifecycle, and drop the now-unused
`_customCodeExecutor` field and its pre-check in `executeCode()`.
Also fix `detail_level` validation in `CodeModeConnector.callTool`: it
used `detailLevel in ["names", "descriptions", "full"]`, and `in` tests
property keys, so an array literal only has `"0"`/`"1"`/`"2"`/`"length"`.
Every valid detail level failed the guard and was silently rewritten to
`"full"`, so an agent requesting `"names"` received full input schemas for
every tool. Replaced with a `Set` membership test.
Adds 10 unit tests: first-call success, timeout forwarding, `searchTools`,
`close()` cleanup, the `BaseCodeExecutor` instance path, each valid
`detail_level`, and the unknown/omitted fallbacks.
Closes#2122
* fix(client): preserve `this` for custom executors, tighten tests, document the contract
Addresses review feedback on the code-mode custom-executor fix.
The `this` binding regression is real -- I measured it both ways. On the
pre-fix code the executor function was invoked as
`this._customCodeExecutor(code, timeout)`, so a non-arrow function saw the
`MCPClient` as its `this`; through the new adapter it saw the
`FunctionCodeExecutor`. `FunctionCodeExecutor.execute` now calls
`this.fn.call(this.client, ...)` so a `function`-form executor keeps the same
context it had before, and a test asserts it.
Two tests were weaker than their titles claimed:
- the `searchTools` test ran against an empty client, so it only proved the
call did not throw. It now registers a stub session with one tool and
asserts the full `{ meta, results }` payload, including the namespace and
the tool's `input_schema`.
- the `close()` test only asserted the promise resolved, which would pass
even if cleanup were skipped. It now spies on the resolved executor's
`cleanup()` and asserts it ran exactly once.
Documentation: the API reference listed one "Custom" executor row saying to
implement `execute()` + `cleanup()`, which is only true for the
`BaseCodeExecutor` subclass form. Split it into separate class and function
rows, add the `CodeExecutorFunction` signature to the types block, and add a
worked example to the code-mode guide (current and v2) stating the `this`
context and that the function owns its runtime cleanup.
* docs(client): use a non-arrow custom executor in the code-mode example
The example demonstrated the documented `this` context with an arrow function,
which has lexical `this` and therefore cannot observe it. Switched to
`async function (this: MCPClient, code, timeout)` and had it actually call
`this.getServerNames()`, so the snippet exercises the contract it describes.
Type-checked the snippet shape against the real `MCPClient` type with
`tsc --noEmit` before committing.
Also reworded the surrounding paragraph: the `this` binding is specific to the
non-arrow form, whereas the cleanup-ownership rule applies to every custom
function.
* docs(client): drop v1 code-mode custom executor docs
This change is v2-only; keep the custom-executor contract on the v2 docs path.
* chore(typescript): version packages (canary)
* fix(create-app): sanitize the npm name for named projects, not just "." (#2209)
deriveProjectInfo only ran sanitizePackageName on the "." branch. A named
project passed the raw argument straight through as packageName, which is
then written into package.json and substituted into the template's index.ts.
The CLI rejects path separators, ".." and a few protected names, but not
spaces, quotes or capitals, so `create-mcp-use-app 'My "App"'` emitted
`name: "My "App""` in index.ts, which is not valid TypeScript.
Sanitize on both branches. The directory still uses the name as typed.
* chore(typescript): version packages (canary)
* fix: enable skills tab after HMR (#2220)
* chore(typescript): version packages (canary)
* fix(create-app): strip leading underscores when sanitizing a package name (#2221)
sanitizePackageName removed leading dots and dashes but not underscores, so
create-mcp-use-app _foo wrote "name": "_foo" into package.json.
npm publish rejects that outright:
npm error code EINVALIDPACKAGENAME
npm error Invalid package name "_foo": name cannot start with an underscore.
Widen the leading-character class to [._-] and cover both the sanitizer and a
named project starting with an underscore.
Closes#2219
* chore(typescript): version packages (canary)
* fix(client): surface auth for protected operations
* fix(inspector): resume mixed-auth chat tools (#2226)
* chore(typescript): version packages (canary)
* fix: harden stable mixed-auth flows
---------
Co-authored-by: Enrico <2827496+tonxxd@users.noreply.github.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: LHMQ878 <72402929@cityu-dg.edu.cn>
Co-authored-by: Ayaan Gazali <ayaangazali.work@gmail.com>
- Updated CLI command syntax to include [path] for deployment.
- Improved descriptions for deployment options, including `--name`, `--new`, and `--region`.
- Added `--json` option for machine-readable output and clarified its behavior in the documentation.
- Enhanced error handling and output formatting for better user feedback.
- Updated various command help texts to reflect new features and usage patterns.
- Improved local authentication flow and clarified the behavior of `--no-open` and `--json` options.
- Added tests to ensure correct behavior of new features and error handling.
Drop chalk/cli-highlight from @mcp-use/agent (inline ANSI for prettyStreamEvents), remove the redundant ./browser entry, default autoInitialize in simplified mode, and ship package examples plus corrected install guidance (client is a transitive dep; /langchain is a subpath).
- Updated the API reference to reflect the migration from v1 enum elicitation helpers to Zod form schemas.
- Revised descriptions and examples in the elicitation schemas documentation to guide users on the new Zod-based approach.
- Adjusted links and callouts to emphasize the removal of deprecated v1 helpers and provide migration guidance.
- Renamed `ToolContext` to `RequestContext` in documentation and code.
- Updated the context object to provide enhanced client metadata, including user information and capabilities.
- Improved examples and descriptions for clarity on client capabilities and request-scoped metadata.
- Adjusted tests to reflect changes in client metadata handling and ensure type safety.
Bring back typed Hono routes/middleware with server.fetch as the serving
boundary, restore deprecated response helpers for upgrades, and require
useCallTool names to resolve against mcp-env.d.ts ToolRefs (with
useDynamicTool + mcp-use typecheck as the escape hatch).
* fix inspector hosted proxy and oauth recovery
* remove inspector compatibility report
* refactor(inspector): mount project-local dev inspector
* refactor(inspector): remove CDN application delivery
* fix(inspector): finalize local mount and proxy health checks
- Updated documentation to clarify the use of `mcp-use dev --tunnel` and `mcp-use start --tunnel`, including automatic tunnel restart on registration drop.
- Refined TypeScript API references for `allowedOrigins` and `cors` configurations to improve clarity on behavior.
- Transitioned view-related files from `resources/` to `views/`, aligning with new authoring standards.
- Introduced a new `mcp-env.d.ts` for type definitions and simplified favicon selection logic.
- Enhanced the `create-mcp-use-app` template to support views, including a new fruit search example with improved UI components.
- Added mock OpenAI file APIs for local development environments to facilitate testing.
- Updated package.json descriptions and keywords for better clarity and alignment with project goals.
Andrew Khadder