mirror of
https://github.com/mcp-use/mcp-use.git
synced 2026-09-14 18:06:01 +08:00
python-v1.7.1
277 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Andrew Khadder
|
485c79cc56 |
Canary (#2483)
* 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> |
||
|
aishwary-dongre
|
2ef6367b4e |
docs(cli): document env unset failure when the variable is missing (#2467)
* docs(cli): document env unset failure when the variable is missing #2411 made servers env unset throw env_variable_not_found instead of reporting a deletion that never happened, but the CLI reference still only mentions the confirmation prompt. A reader has no way to know the command now exits non-zero, or that --branch is part of the scope the lookup resolves against. * docs(cli): fold the env unset failure note into the confirmation bullet |
||
|
Mohammed Alkindi
|
c44400417b |
docs(server): stop teaching the removed ctx.elicit in v2 samples (#2409)
* docs(server): stop teaching the removed ctx.elicit in v2 samples ctx.elicit was removed and tests/type-level.test.ts asserts its absence, but the v2 elicitation page and the migration guide still built every sample on it, so none of them compiled. Rewrite them on inputResponse, acceptedContent and inputRequired, mirroring examples/elicitation. migration.mdx already stated the replacement in its own comparison table while the sample below it used the old call. * docs(server): describe the real inputResponse result in the status table The table still listed the removed call's statuses and its result and data fields. Unions taken from the compiler: kind is elicit, missing, roots or sampling, and action is accept, cancel or decline. * docs(server): finish the URL mode note and qualify the response table The URL section still described passing the url as a third positional argument, which was the removed call's shape. The response table also lost the original's note that URL mode carries no form data, and read as the helper's complete union when roots and sampling exist for other request types. * docs(server): show the helper imports in the migration snippet The replacement snippet used inputResponse, acceptedContent and inputRequired without showing where they come from, so copying it into a migrated server left unresolved identifiers. |
||
|
Andrew Khadder
|
695ae31395 | docs(server): clarify OAuth resource claim semantics (#2443) | ||
|
Enrico Toniato
|
5e7e350f80 |
Canary (#2424)
* fix(create-mcp-use-app): drop the dead --no-git flag from help (#2392)
Scaffolding stopped initializing a git repository in
|
||
|
Ayaan Gazali
|
0fb3005356 |
docs(typescript): fix CLI flag syntax that silently deploys the wrong directory (#2386)
* docs(typescript): fix CLI flag syntax that silently deploys the wrong directory
The v2 CLI reference wrote the repeatable --env, --watch-paths and
--deploy-branches flags in commander's variadic notation (<glob...>) and
showed examples passing several values to one flag. The CLI parses argv
with node's util.parseArgs, where multiple: true means the flag is
repeatable, not variadic, so only the first value is read and the rest
become positionals.
That makes the two documented examples wrong in different ways:
mcp-use deploy --root-dir apps/mcp-server \
--watch-paths "apps/mcp-server/**" "packages/shared/**"
deploy takes an optional [path] positional, so "packages/shared/**" is
accepted as the deploy path. The command succeeds and deploys the wrong
directory with one watch path instead of two.
mcp-use servers update srv_abc123 \
--watch-paths "apps/api/**" "packages/shared/**" --deploy-branches "release/*"
servers update allows exactly one positional, so the extra value fails
with exit code 2 and "Usage: mcp-use servers update <id-or-slug>".
Also drops the -y short flag from servers delete. deploy defines
yes: { type: "boolean", short: "y" }, but servers delete defines only
yes: { type: "boolean" }, so -y exits 2 with "Unknown option '-y'".
The legacy docs/typescript reference already uses the repeated-flag form.
This brings v2 in line with it and with the CLI's own --help output.
* docs: say outright that the servers update pattern flags are repeatable
The deploy table carries Repeatable in the description column, but the
servers update row is a flat options list with nowhere to put it, so the
one place a reader learns the rule was the corrected example.
|
||
|
Andrew Khadder
|
32da34505b |
Canary (#2384)
* test(cli): make the remaining skill rewrites change file length (#2374) * chore: enter canary prerelease mode * feat(inspector): show request duration instead of timestamp in RPC logger (#2364) The RPC log rows rendered the wall-clock timestamp on the right of each row while the request latency was squeezed into the truncated method label. The timestamp is rarely useful compared to how long a request took, and the inline latency contributed to text truncation. Move the latency into the right-side slot where the timestamp rendered and remove it from the method label. Rows for a correlated response now show "42 ms" with a tooltip including the wall-clock time; rows without a measured duration (notifications, pending requests) render no right-side time. Search and row test ids now match the bare method name. Fixes #2327 * chore(typescript): version packages (canary) * fix(typescript): fail screenshot CLI on MCP App init failure (#2355) * fix(typescript): fail screenshot CLI on MCP App init failure * fix(typescript): ignore post-init guest re-sync errors in view lifecycle signal * fix(typescript): re-arm view lifecycle error signal on bridge reconnect * fix(typescript): keep view load failure marker across late teardown events * chore(typescript): version packages (canary) * feat(auth): add Convex OAuth provider example and integration (#2372) * feat(auth): add Convex OAuth provider example and integration - Introduced a new example for an MCP server authenticated by a Convex OAuth Provider. - Updated pnpm-lock.yaml to include dependencies for the Convex example. - Added necessary configurations in package.json, tsup.config.ts, and typedoc.json for the new Convex integration. - Created new source files for Convex OAuth handling and example server logic. - Updated tests to include verification for Convex OAuth functionality. - Enhanced documentation to include Convex in the examples section. * feat(auth): add Convex OAuth provider example and integration - Add Convex OAuth provider documentation with setup and usage examples - Create new Convex provider guide covering configuration, environment variables, and identity verification - Update authentication provider index to include Convex in built-in providers list - Update authentication overview table to reference Convex as a supported provider option - Add Convex example to auth registry with environment configuration - Enhance Convex example server with OAuth provider implementation - Add changeset entry documenting new Convex OAuth provider support * feat(auth): add Convex OAuth provider example and integration - Add Convex OAuth provider documentation with setup and usage examples - Create new Convex provider guide covering configuration, environment variables, and identity verification - Update authentication provider index to include Convex in built-in providers list - Update authentication overview table to reference Convex as a supported provider option - Add Convex example to auth registry with environment configuration - Enhance Convex example server with OAuth provider implementation - Add changeset entry documenting new Convex OAuth provider support * docs(typescript): move Convex provider guide to v2 --------- Co-authored-by: Andrew Khadder <andrew@manufact.com> * chore(typescript): version packages (canary) * fix(client): stop OAuth retries after disconnect (#2367) * fix(client): stop OAuth retries after disconnect * chore: add client patch changeset * chore(typescript): version packages (canary) * ci: update checkout, setup-python, setup-node, and upload-artifact to current majors (#2377) * ci: update checkout, setup-python, setup-node, and upload-artifact to current majors in ci.yml * ci: bump github-script to v9 to finish action updates --------- Co-authored-by: katsugtgz <katsugtgz@users.noreply.github.com> Co-authored-by: katsugtgz <187455787+katsugtgz@users.noreply.github.com> * fix(client): hold one client reference across listAllResources pagination (#2387) * fix(client): hold one client reference across listAllResources pagination listAllResources guards on this.client, then paginates inside a single executeRequest closure that re-reads this.client on every page. disconnect() runs cleanupResources, which sets this.client to null, so a teardown landing between pages makes the next iteration throw TypeError: Cannot read properties of null (reading 'listResources') instead of the not-connected error the rest of the connector reports. Capturing the client in the existing guard fixes it without changing the guard's behaviour: the reference is read once, at a point where it is known to be set, and the loop keeps using it. A disconnect mid-listing now surfaces whatever the closed transport reports rather than a null dereference. This is the pagination half of #2366. #2367 covered the OAuth retry path by re-checking the connector state before re-invoking the closure; that guard does not apply here because the loop never leaves executeRequest, and the race needs no OAuth provider to reach. * docs: describe what the captured reference actually prevents The comment claimed the loop would otherwise report the not-connected error. It would not: capturing the reference means a disconnect mid listing fails on the closed transport, which is what the test asserts. * chore(typescript): version packages (canary) * feat(inspector): configure embedded max steps (#2401) * feat(inspector): configure embedded max steps * fix(inspector): refresh embedded max steps * chore(typescript): version packages (canary) --------- 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: Mert Çetin <97505365+merttcetn@users.noreply.github.com> Co-authored-by: Prasad Shinde <144712280+Prasad8830@users.noreply.github.com> Co-authored-by: Anirban Ghosh <anirbanghosh060@gmail.com> Co-authored-by: Elioooon <102770919+Elioooon@users.noreply.github.com> Co-authored-by: Muhammad Naufal Mahdi <053792227@ecampus.ut.ac.id> Co-authored-by: katsugtgz <katsugtgz@users.noreply.github.com> Co-authored-by: katsugtgz <187455787+katsugtgz@users.noreply.github.com> Co-authored-by: Pietro Zullo <62951181+pietrozullo@users.noreply.github.com> |
||
|
Ayaan Gazali
|
6bd6181e34 |
docs(cli): org use, and logout takes --yes (#2382)
* docs(cli): org use, and logout takes --yes
Two more rows that do not match the binary.
`org switch` does not exist. The dispatch is:
$ mcp-use org switch my-org
Usage: mcp-use org <list|current|use> exit 2
$ mcp-use org use my-org
Not logged in. Run `mcp-use login`. exit 1
The third subcommand is `use`.
`logout` is documented as taking no options, and the example is a bare
`mcp-use logout`. It prompts, so without a TTY that example fails:
$ mcp-use logout
Log out? Pass --yes to confirm. exit 2
$ mcp-use logout --yes
Logged out. exit 0
It also honours `--json`, verified both ways:
$ mcp-use logout --json --yes
{"loggedOut":true} exit 0
Document both options and make the example runnable.
* docs(cli): clarify org use and logout
---------
Co-authored-by: Andrew Khadder <andrew@manufact.com>
|
||
|
Ayaan Gazali
|
2aafffead5 |
docs(cli): drop the two deploy flags that do not exist (#2380)
* docs(cli): drop the two deploy flags that do not exist The deploy option table lists --port and --runtime. Neither is accepted: $ mcp-use deploy --port 3000 Unknown option '--port'. exit 2 $ mcp-use deploy --runtime node Unknown option '--runtime'. exit 2 deploy's parseArgs declares exactly org, name, branch, root-dir, region, env, env-file, build-command, start-command, dockerfile, watch-paths, wait-for-ci, no-github, new, open, yes, json and help. There is nowhere for port or runtime to land. Every other row in that table was checked the same way and is correct, including `-y, --yes`, whose short form does work here even though the deployments table's does not. `--port` stays in the dev and start tables, where it is real. * docs(cli): remove invalid runtime example --------- Co-authored-by: Andrew Khadder <andrew@manufact.com> |
||
|
Ayaan Gazali
|
3a330e6c21 |
docs(cli): correct the deployments subcommand table (#2379)
* docs(cli): correct the deployments subcommand table Seven claims in this table do not match the binary. Each was checked by running it; the CLI errors with exit 2 on a bad option or subcommand and reaches "Not logged in" with exit 1 once it parses, which makes the two easy to tell apart without credentials. ls alias Usage: mcp-use deployments <list|get|logs|restart|stop|delete> rm alias same start subcommand same --sort Unknown option '--sort' -b (logs) Unknown option '-b' -f (logs, restart) Unknown option '-f' stop, no --yes Stop deployment dep_x? Pass --yes to confirm. The long forms --build and --follow do work; only the short aliases are absent. The dispatch accepts exactly list, get, logs, restart, stop and delete (deployments.ts:63-71), so ls, rm and start have nowhere to land. Also adds --org and --server to the list row. Both are real and were missing; the command's own usage string advertises them. Removes the `deployments start dep_abc123` example, which cannot run, and notes that stop prompts for confirmation like delete does. Every row in the corrected table now parses and reaches the auth check rather than failing on arguments. * docs(cli): document deployment JSON output --------- Co-authored-by: Andrew Khadder <andrew@manufact.com> |
||
|
Ayaan Gazali
|
667c89a32f |
docs(cli): client remove takes --json, not --yes (#2376)
The client command table lists `--yes` as the key option for
`remove <name>`. Passing it fails:
$ mcp-use client remove doomed --yes
Unknown option '--yes'.
exit 2
`remove` parses no options of its own (`options: {}` in client.ts:178)
and never prompts, so there is no confirmation for `--yes` to skip. It
does honour the global `--json`:
$ mcp-use client remove tmp1 --json
{"removed":"tmp1"}
exit 0
`--yes` is real, but only on `auth logout`, which does prompt. That row
already documents it correctly and is unchanged:
$ mcp-use client s1 auth logout --yes
Logged out s1.
exit 0
|
||
|
Enrico Toniato
|
82772dcbab |
Canary (#2359)
* 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> |
||
|
Ayaan Gazali
|
1facc84c6c |
docs(cli): document screenshot, drop the generate-types section (#2352)
The page calls itself the exhaustive command reference. Two entries do not
match the CLI.
`generate-types` does not exist. It has a full section with a syntax
block, an options table and examples, but the command is gone:
$ grep -rn "generate-types" libraries/typescript/packages/cli/src
(no matches)
$ mcp-use generate-types --help
mcp-use — run MCP servers built with mcp-use # general help
`screenshot` does exist and had no section. It is a top-level command,
dispatched at bin/main.ts:220, not a subcommand of `client`:
$ mcp-use client --help
Commands:
connect <name> <url> list remove <name> <name>
The page instead scoped it to `client screenshot` in the environment
variable table and showed `mcp-use client local screenshot --tool
show-board`, which cannot work.
Replace the phantom section with a real one for `screenshot`, taken from
`mcp-use screenshot --help`: source options, capture options, argument
form, examples and exit codes. Fix the three environment rows and the
example.
All thirteen commands in `mcp-use --help` now appear on the page. Link
check is unchanged at 7 pre-existing root-relative warnings, the same
before and after.
|
||
|
Andrew Khadder
|
f2f4fdbf33 |
Canary (#2334)
* 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> |
||
|
Bobo
|
690a458e69 |
docs: correct server environment CLI reference (#2288)
* docs: correct server environment CLI reference * docs: document env organization option --------- Co-authored-by: Bo Zhang <187063395+Tethys0@users.noreply.github.com> |
||
|
Andrew Khadder
|
1af9bebce5 |
Canary (#2329)
* 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> |
||
|
saif-at-scalekit
|
5865e5c142 |
docs: add Scalekit provider sidebar logo (#2306)
The other first-class providers use a custom SVG. shield-halved did not render in the Mintlify sidebar. |
||
|
Andrew Khadder
|
d0107b3484 |
Canary (#2304)
* 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> |
||
|
Ayaan Gazali
|
bcd9befbcd |
docs: use createJwtVerifier in the custom OAuth provider guide (#2265)
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. |
||
|
Andrew Khadder
|
64480f083c |
docs(examples): add json-render generative UI example (#2222)
* docs(examples): add json-render generative UI example * style(examples): format generative UI view * fix(examples): guard incomplete streamed UI elements * docs: add generative UI guide |
||
|
Andrew Khadder
|
b6a720b912 | docs: move Skills over MCP navigation (#2248) | ||
|
Andrew Khadder
|
e17cd7b8ca |
Canary (#2216)
* feat(client): support mixed OAuth servers
* fix(inspector): pause mixed-auth tool calls
* Revert "fix(inspector): pause mixed-auth tool calls"
This reverts commit
|
||
|
Enrico Toniato
|
1f7df2a82c |
fix release blockers before stable promotion (#2206)
* fix release blockers before stable promotion * fix conformance summary expected outcomes * harden release and conformance validation |
||
|
Andrew Khadder
|
885310e433 | docs: update Canary changelogs | ||
|
Andrew Khadder
|
c83d1d9737 |
Merge remote-tracking branch 'origin/main' into canary
# Conflicts: # libraries/typescript/packages/server/specs/CLI_SPEC.md # libraries/typescript/packages/server/specs/SPEC.md # libraries/typescript/packages/server/specs/VIEWS_SPEC.md |
||
|
Andrew Khadder
|
e41076fb3f |
feat: improve Skills over MCP Inspector support (#2196)
* Codex worktree snapshot: archive-cleanup Co-authored-by: Codex * feat: improve skills over MCP inspector support * fix: address Skills review feedback |
||
|
Andrew Khadder
|
859dcca632 | fix docs SEO metadata and migration redirect (#2181) | ||
|
Andrew Khadder
|
7f915b6407 | docs: remove v2 design specs (#2180) | ||
|
Enrico
|
2daf9c9d42 | fix: resolve skills over MCP canary conflicts | ||
|
Enrico
|
6911124f34 | feat: add Skills over MCP | ||
|
Enrico
|
668a312100 | add standalone WebSocket tunnel package | ||
|
Andrew Khadder
|
33e30cb8e3 |
Canary (#2117)
* 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 #2080 Closes #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> |
||
|
Ayaan Gazali
|
4d61f840a9 |
docs: the v1 compatibility bridge no longer exists in v2 (#2145)
* 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.
|
||
|
Andrew Khadder
|
e52ebe39a3 | docs: remove completed v2 migration checklists (#2140) | ||
|
Andrew Khadder
|
db46159c84 |
v2 docs fixes (#2139)
* Set V2 as the default documentation version * Reorganize documentation navigation and redirects * Remove deprecated repository content * Rename Manufact deployment guide |
||
|
Pietro Zullo
|
d391b6383e | docs: update OG image (MCP-2169) (#2137) | ||
|
Ayaan Gazali
|
16216399a8 |
docs: list the recipe template's prompts separately from its tools (#2079)
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. |
||
|
Enrico
|
11eb39a545 | docs: remove prerelease guidance from stable v2 docs | ||
|
Enrico
|
06ff3075b5 | release: merge v2 beta into main | ||
|
Enrico Toniato
|
e1c8aa4685 |
fix: prepare v2 stable release channels and launch surfaces (#2106)
* fix: prepare v2 stable release channels * fix: normalize peers only when exiting prerelease |
||
|
Enrico Toniato
|
f06deff02c | fix v2 beta release blockers (#2104) | ||
|
Enrico Toniato
|
c6043e4d05 |
fix: use hosted WebSocket tunnel relay (#2057)
* 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 |
||
|
Enrico Toniato
|
67b4a27d9d | remove v1 compatibility layer (#2049) | ||
|
Enrico
|
f6634fb688 |
Update README.md and docs.json for TypeScript v2 migration and new banner
- 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. |
||
|
Enrico
|
05a1e63e30 | docs: update beta banner content in v2 documentation to include a link for more information | ||
|
Andrew Khadder
|
386dc8c3a5 |
v2 docs (#2038)
* docs: split TypeScript V1 and V2 documentation * Rewrite v2 getting started docs * docs: rewrite v2 server overview * docs: refine v2 server overview * docs: remove v2 session management * docs: add v2 server migration checklist * docs: refine v2 server migration checklist * docs: audit v2 server migration checklist * docs: complete TypeScript server guide migrations * docs: remove oauth proxy factory references * docs: simplify MCP terminology in descriptions * docs: keep core API links in next steps * docs: export view-bound tool reference * docs: remove OAuth proxy warning * docs: document tool-list notifications * docs: simplify custom OAuth verifier example * docs: restore full Hono middleware guide * docs: remove custom provider proxy warning * docs: hide server sampling guide from navigation * docs: complete MCP client guide migration * docs: align Inspector and tunnel guides * docs: rewrite v2 MCP Apps overview * docs: remove v2 response helpers guide * rewrite TypeScript V2 MCP Agent guides (#2022) * docs: add v2 server migration guide * docs: add native TypeDoc API reference (#2032) Add the unified native TypeDoc site, package TSDoc coverage, Vercel deployment configuration, and the V2-only Mintlify API reference link while preserving V1 navigation. * docs: use declarative model context in v2 guidance (#2033) * docs: fix V2 API reference link (#2034) * docs: refine V2 header controls (#2035) * docs: align migration page titles * docs: preserve main v1 documentation * docs: recover v2 MCP Apps rewrite |
||
|
Enrico
|
4c5e162009 |
Update README.md to enhance visual elements and clarify content
- 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. |
||
|
Andrew Khadder
|
01208e052a |
Revert "docs: split TypeScript V1 and V2 documentation (#2010)" (#2036)
This reverts commit
|
||
|
Andrew Khadder
|
5b5fe96d28 |
docs: split TypeScript V1 and V2 documentation (#2010)
Preserve the V1 TypeScript docs, add independently navigable V2 beta documentation, and align shared documentation. Rename both V2 migration guides to “Migrating to v2”. |
||
|
Enrico Toniato
|
ef8187a67d | fix(typescript): support runtime-first view deployments (#2028) |