* 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>
The guide hand-rolled a verifier with jose: signature and issuer checks, sub
and exp guards, scope splitting, client_id/azp fallback, and the resource
binding. That is 33 lines of security-sensitive code for readers to copy and
get right.
#2234 exported createJwtVerifier, which is the helper the six built-in
providers already use and does all of it. Show that instead, and keep the
hand-written path documented for providers that do not issue JWTs.
* 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>
* fix(cli): report success from mcp-use typecheck (#2099)
`tsc --noEmit` prints nothing on a clean project, so `mcp-use typecheck`
exited 0 with no output at all, which is indistinguishable from the
command hanging or silently failing.
Print `[mcp-use] no type errors (<duration>ms)` on exit code 0, matching
the existing `[mcp-use] built ... (<duration>ms)` line from `build`.
Failing runs are untouched and still show only the compiler's own
diagnostics.
Closes#2083
* chore: enter canary prerelease mode
* chore(typescript): version packages (canary)
* chore: sync main into canary (#2119)
* chore(release): exit prerelease mode and publish npm README hotfix
Publishes mcp-use 2.0.1 and @mcp-use/inspector 20.0.1 with the repository README included in the mcp-use package tarball.
* chore(release): exit prerelease mode and publish npm README metadata hotfix
Publishes mcp-use 2.0.2 and @mcp-use/inspector 20.0.2 after preparing README metadata before npm publication.
* chore(release): exit prerelease mode and commit npm package README
Publishes mcp-use 2.0.3 and @mcp-use/inspector 20.0.3 with a committed package-root README.
* chore(release): exit prerelease mode and fix npm README assets
Fix npm README asset and repository links, publish mcp-use 2.0.4, and keep Inspector aligned at 20.0.4.
* Update libraries/typescript/packages/server/README.md
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>
* docs: sync migration guide link
---------
Signed-off-by: Andrew Khadder <54488379+khandrew1@users.noreply.github.com>
Co-authored-by: Enrico Toniato <2827496+tonxxd@users.noreply.github.com>
Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>
* fix(cli): say whether `start` mounted the inspector (#2100)
* fix(cli): say whether start mounted the inspector
`mcp-use dev` advertises the inspector in its banner, but `mcp-use start`
says nothing about it and `${basePath}/inspector` 404s unless
`--with-inspector` was passed. With no hint, that reads as a broken
production build rather than an opt-in.
Plain `start` now prints that the inspector is not mounted and how to
mount it, and `--with-inspector` prints the URL it was mounted at, which
was previously silent too.
Closes#2084
* fix(cli): drop the inspector-not-mounted line from start
Per review: most people running start do not want the inspector, so
announcing its absence is noise. Plain start is now silent about the
inspector again, and only the --with-inspector path prints its URL.
Updates the spec, the changeset, and swaps the test to pin the silence
instead of the message.
* chore(typescript): version packages (canary)
* chore: upgrade changesets cli to 2.31.1 (#2121)
* fix(ci): pin pnpm in the docs workflow so the job can start (#2116)
The docs job fails in "Set up pnpm" before it generates anything:
Error: No pnpm version is specified.
pnpm/action-setup@v4 was used with no version:, so it falls back to
reading packageManager from package_json_file, which defaults to the
repository root. This repo has no root package.json, so the step could
never succeed and the check was red on every branch including main.
Pins 11.13.1, matching all nine action-setup uses in ci.yml and the
packageManager field in libraries/typescript/package.json.
* fix(cli): support package-manager dev arg forwarding (#2124)
* fix(cli): support package-manager dev arg forwarding (MCP-2549)
* chore: add MCP-2549 changeset
* fix(cli): normalize forwarded arguments across commands
* chore(typescript): version packages (canary)
* docs: fix TypeScript README links into the removed mcp-use package (#2114)
The v2 merge deleted libraries/typescript/packages/mcp-use, but the
TypeScript README still pointed at it in four places: the three logo
sources at the top of the page, and the documentation link at the bottom.
The logo now uses the absolute raw.githubusercontent.com URL that every
sibling package README already uses, and the docs link points at
packages/server, which is where the mcp-use package lives in v2 and what
the create-mcp-use-app and inspector READMEs already link to.
* fix(create-mcp-use-app): drop stale main field and give templates distinct descriptions (#2085)
* fix(create-mcp-use-app): drop stale main field and give templates distinct descriptions
Two small things in the scaffolded package.json, both visible as soon as
you generate a project.
main pointed at dist/index.js. v2 builds emit .mcp-use/build instead, so
that path never exists and main never resolves. These templates are apps
you run with mcp-use start, not packages anyone imports, and .mcp-use is
gitignored build output, so the field is dropped rather than repointed.
All three templates also carried the description 'an mcp-use server'.
--list-templates reads that field, so the three were indistinguishable
from the CLI, and every generated project inherited the same string.
Each now says what it actually gives you.
Closes#2080Closes#2081
* chore: add changeset for the template package.json fixes
* fix(create-mcp-use-app): stop discarding the template description
updatePackageJson overwrote description with a generic
"<name>: an mcp-use server" on every scaffold, so the per-template
descriptions only ever reached --list-templates and never the generated
project. It now fills that in only when the template has no description
of its own, which keeps the previous behaviour for templates without one.
* chore(typescript): version packages (canary)
* fix(client): stop leaking parent env to stdio servers (#2125)
Port the security fix from #1949 to the v2 client package and verify the child process receives only safe defaults plus explicitly configured variables.
Co-authored-by: VihaanAgarwal <72850668+VihaanAgarwal@users.noreply.github.com>
* chore(typescript): version packages (canary)
* fix(client): bound conformance auth scenarios (#2126)
* fix(client): make stdio errlog actually receive the child's stderr (#2086)
* fix(client): make stdio errlog actually receive the child's stderr
StdioConnectionManager takes an errlog stream and documents that the
child server's stderr is piped to it, but the transport was created
without stderr: "pipe". The SDK defaults to "inherit", which leaves
transport.stderr null, so the forwarding block guarding on it never
ran and the child's stderr always went to the parent instead.
Spawn with stderr: "pipe" by default, spread so an explicit mode in
server params still wins. Tests spawn real child processes: one checks
a custom errlog receives the output, one checks stderr: "ignore" still
opts out.
* chore: drop stray version.ts that does not belong on beta
Left over from a main checkout; packages/mcp-use does not exist on this
branch.
* fix(client): expose stderr mode on the public stdio APIs
Per review, the compatibility escape hatch only worked for callers that
built StdioConnectionManager directly. StdioConnector did not accept or
forward stderr and StdioServerConfig did not expose it, so users of the
normal public APIs could not opt back into inherited stderr.
- Add a StdioStderrMode of "pipe" | "inherit" | "ignore", default "pipe".
- Accept it on StdioConnector and StdioServerConfig, forward it into
StdioServerParameters, and thread it through the config path.
- Apply the default after the spread so an explicit stderr: undefined no
longer defeats it.
- Only forward transport.stderr when the mode leaves a readable stream.
- Pipe with { end: false } and unpipe on close, since errlog is
caller-owned and may be reused across reconnects.
- Handle stream errors instead of letting a destroyed errlog surface as
an unhandled 'error' event.
Tests now start the transport before asserting, so the non-pipe cases are
exercised against a real child instead of passing by construction.
* fix(client): handle errlog write errors
---------
Co-authored-by: Andrew Khadder <andrew@manufact.com>
* chore(typescript): version packages (canary)
* fix(inspector): block loopback proxy targets by default (#2134)
mountInspector defaulted oauthProxyAllowLoopback to true, and the standalone
CLI hardcoded it — including in the published Docker image, which runs the
CLI with NODE_ENV=production on a public port. A publicly reachable inspector
could therefore proxy requests to the host's loopback services (SSRF), while
RFC1918/metadata targets were already blocked.
- mountInspector: default allowLoopback to false; local dev tooling opts in
- CLI: allow loopback unless NODE_ENV=production; INSPECTOR_ALLOW_LOOPBACK
overrides either way
- Express-adapter test opts in explicitly (it proxies to its own 127.0.0.1
echo server); new regression test covers the default and the opt-in
* chore(typescript): version packages (canary)
* docs: add v2 changelog updates
* chore: remove retired beta release flow (#2141)
* fix: keep prerelease versioning visible to Knip (#2142)
* fix: patch dependency vulnerabilities (#2151)
* fix: patch vulnerable dependencies
* fix: use mcp-use in client demo servers
* chore(typescript): version packages (canary)
---------
Signed-off-by: Andrew Khadder <54488379+khandrew1@users.noreply.github.com>
Co-authored-by: Ayaan Gazali <ayaangazali.work@gmail.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Enrico Toniato <2827496+tonxxd@users.noreply.github.com>
Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>
Co-authored-by: VihaanAgarwal <72850668+VihaanAgarwal@users.noreply.github.com>
* docs: the v1 compatibility bridge no longer exists in v2
The migration guide tells people they can stage a migration by keeping
`import { MCPServer, text } from "mcp-use/server"`. That export was
removed before v2 went stable, so the import does not resolve and the
advice sends migrating users down a path that fails immediately.
Replaces the staging section with what actually happened and points at
the package root, and drops the matching allowance from the cleanup step.
* docs: drop the compatibility bridge section entirely
Per review: the bridge was never part of the official release, so
documenting its removal keeps a beta remnant alive in the migration
guide. Removes the section rather than rewriting it.
The cleanup step keeps its correction, since v1 really did import from
mcp-use/server and migrating users still need to remove those.
* Set V2 as the default documentation version
* Reorganize documentation navigation and redirects
* Remove deprecated repository content
* Rename Manufact deployment guide
The templates table and the templates page both list meal-plan and
recipe-suggestion under Tools for the Recipe Finder, but the server
registers those two as prompts, not tools. Querying the linked demo
server confirms it:
tools/list -> search-recipes, get-recipe
prompts/list -> meal-plan, recipe-suggestion
The distinction matters because a model can call a tool on its own but
cannot invoke a prompt, so anyone reading the table expects behavior
they will not get. #1883 is someone hitting exactly that.
* fix: use hosted WebSocket tunnel relay
* fix: reattach tunnels across relay deploys
* fix: negotiate tunnel keepalive support
* refactor: remove spinner state and improve loading indicators in ViewRenderer and MCP Apps components
- Updated migration guide link in README.md to point to the correct TypeScript v2 documentation.
- Added a new warning banner in docs.json to announce that mcp-use v2 is now in beta.
- Enhanced TypeScript SDK description in docs.json to clarify documentation for both V1 and V2.
- Restructured documentation sections in docs.json for better organization and clarity.
- Replaced logo with a new banner image for better visibility.
- Improved text formatting for readability.
- Updated badge links for npm version and downloads.
- Adjusted Discord badge style for consistency.
Preserve the V1 TypeScript docs, add independently navigable V2 beta documentation, and align shared documentation. Rename both V2 migration guides to “Migrating to v2”.
- 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.
Andrew Khadder