* 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>
detect-changes gates every TypeScript job on the `typescript` path filter,
which only matches `libraries/typescript/**`. A pull request that edits
nothing but this workflow therefore matches no filter, so every job the
workflow defines is skipped on the change that defines them.
The three most recent workflow-only fixes all merged without the job they
were wiring up ever executing:
#2201 "actually run the inspector unit tests" typescript/inspector skipped
#2214 "run the create-mcp-use-app unit tests" typescript/create-app-tests skipped
#2213 "actually run the mcp-use unit tests" no TypeScript job ran
Add `.github/workflows/ci.yml` to the typescript and create-mcp-use-app
filters, matching what #2331 already did for knip. GitHub uses the pull
request's own copy of the workflow for `pull_request` runs, so the jobs
that run are the edited ones.
Review feedback on #2310: rather than skipping the score comment for
forks, make the workflow_run companion the only writer and teach it to
resolve fork pull requests.
conformance.yml's report-conformance job is removed. It ran in the
unprivileged pull_request context, so on a fork PR it could only fail
with "Resource not accessible by integration". conformance-comment.yml
already runs in the privileged workflow_run context and posted the Python
score on those same fork PRs.
Its TypeScript path could not, because it resolved the pull request from
workflow_run.pull_requests[0], which GitHub leaves empty for
fork-originated runs. It now resolves from the run's own head:
head = `${run.head_repository.owner.login}:${run.head_branch}`
and only comments when an open pull request at that head still points at
run.head_sha, so a slow run cannot overwrite a newer result. The pull
request number is never read from the downloaded artifact, which a fork
controls.
Verified the resolution against a live fork PR:
#2350 head=ayaangazali:docs/cli-readme sha=f1fa0469
resolved#2350 head_sha=f1fa0469
* 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>
* fix(ci): actually run the release-channel tests
scripts/release-channel.test.mjs and the test:release-channel script
landed with #2167, but nothing invokes them. The only mention of
test:release-channel in the repo is its own definition, so the six tests
guarding release versioning never run.
Runs them in typescript-changeset-check, which already owns the
release-channel preflight and has the toolchain set up.
* fix(ci): run the release-channel tests in their own job
Addresses review feedback. The step was under typescript-changeset-check,
which skips canary-targeted PRs, and release-channel changes commonly land
through canary. It also never ran on this PR, because that job needs
detect-changes.typescript and this branch only touches ci.yml.
Move it to typescript-release-channel-test with its own path filter covering
the helper, its tests, the package manifest that holds the script, and the CI
and release workflows. No base_ref condition, so it runs for main and canary
PRs alike, and the filter includes ci.yml so changes to this wiring exercise
the suite.
* ci: always run the release-channel test on reusable-workflow runs
The approved-fork path calls this workflow with only python, typescript
and create_mcp_use_app inputs, so it cannot report that a release
workflow changed. Deriving the release-channel flag from the typescript
input meant a workflow-only PR promoted through that path skipped the
test the direct path would have run.
The helper test takes a few seconds, so run it whenever the workflow is
called rather than infer a flag the caller never sends.
typescript-test-cli is the only TypeScript job with more than one matrix
leg: ubuntu-latest and windows-latest. It leaves fail-fast at the default,
which is true, so the first leg to fail cancels the other one.
That throws away the only thing a two-OS matrix is for. When the Windows
leg goes red, the question is always whether Ubuntu went red too, and
cancelling it removes the answer.
It nearly happened last week. On run 32652809882 the Windows leg failed
on a load-sensitive timeout while Ubuntu passed:
ubuntu-latest success completed 16:51:12Z
windows-latest failure completed 16:52:17Z
Ubuntu finished 65 seconds before Windows failed. Had it been a minute
slower it would have been cancelled, and the failure would have looked
like it could be either platform-wide or Windows-only.
Every other multi-leg matrix in this repo already sets fail-fast: false,
including python-transport-tests, python-primitive-tests,
python-agent-tests and create-mcp-use-app-tests. The remaining TypeScript
matrices are single-leg, so the setting does not affect them.
The step ran `pnpm --filter mcp-use --if-present test:unit`, but the mcp-use
package has no test:unit script, so --if-present turned it into a silent pass
and 447 tests never ran.
Point it at test:run, which is the script that exists and the same one the
client step above already uses.
Two failures were hiding behind the skip:
- usage.test.ts asserted telemetry was sent, but the step sets
MCP_USE_ANONYMIZED_TELEMETRY=false, which short-circuits recordUsage. Those
cases are about identity persistence, not the opt-out, so capture() now sets
the variable itself. The file already tracks and restores it in afterEach.
- budgets/runtime-boundary.test.ts compared the builtin list with toEqual, so
it depended on module resolution order between node:process and node:http.
Sorted, which is what the case means by "loads only".
Verified with the step's own env: MCP_USE_ANONYMIZED_TELEMETRY=false
pnpm --filter mcp-use test:run gives 43 files, 447 passed, exit 0.
Closes#2203
The package has 25 vitest cases under src/__tests__, and no workflow ran
them. create-mcp-use-app-build builds and packs, and create-app-tests only
scaffolds a project with each package manager and checks the files exist.
Add the step to the build job, which already installs and builds, so the
unit tests run before the artifact is packed.
Verified: pnpm --filter create-mcp-use-app test gives 2 files, 25 passed.
The "Run Inspector Tests" step calls `--if-present test`, but
@mcp-use/inspector has no `test` script, only `test:unit`. With
--if-present a missing script is a silent success, so the step has been
passing without running anything while 159 unit tests sat unexecuted.
Points it at test:unit, matching the sibling steps for mcp-use and
@mcp-use/agent. Dropped --if-present since the script exists and a
missing one should fail rather than pass quietly.
Restore stable source versions to npm truth and harden the stable/canary release workflow against version regressions and partial publication failures.
* 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>
update-mcp-sdk-fork.yml maintained the @mcp-use/modelcontextprotocol-sdk
version in libraries/typescript/packages/mcp-use. The v2 merge deleted
that package, and v2 depends on the upstream @modelcontextprotocol
packages instead, so the fork is referenced nowhere in the tree or the
lockfile.
Every path the workflow touches is gone: the package.json it reads, and
the tests/deno/deno.json it also rewrites. Its first run against the v2
tree would fail on the version check.
The python-lint job installs ruff unpinned, so it always resolves to the
latest release. ruff 0.16.0 started formatting fenced code blocks inside
Markdown, which brought libraries/python/README.md into the scope of
`ruff format --check .` for the first time. Its quickstart examples were
never formatted that way, so the job now fails on every pull request that
touches libraries/python, regardless of what the change is.
Pin to 0.15.22, the newest release that passes both steps on current main.
This restores a reproducible check and leaves the Markdown question as a
deliberate choice rather than something a tool release decides.
Refs #1856
Fix MCPAgent not spawning MCPClient for explicit llm + mcpServers URL config, omit reasoning.effort unless opted in, and add CI e2e against remote analytics-demo.
* Resolve Inspector CDN releases before loading assets
* fix(ci): pin pnpm for server examples
* fix(ci): relink server example CLI
* fix(examples): support clean Next builds in CI
* fix(examples): expose built workspace CLI
* fix(inspector): address CDN loader review
* fix(inspector): support legacy abort signals
* fix(client): surface manual OAuth failures
* ci: publish TypeScript previews for beta PRs
* ci: pin pnpm for server example checks
* revert: keep server example CI out of OAuth fix
* refactor(create-mcp-use-app): replace --canary flag with --sdk-version for version pinning
- Updated GitHub Actions workflows to use --sdk-version instead of --canary for creating apps.
- Modified CLI options and internal logic to support --sdk-version for specifying npm dist-tags or semver.
- Updated documentation and tests to reflect the change from --canary to --sdk-version.
* chore(ci, workflows): downgrade Node.js version to 20.19.0 across all workflows
- Updated GitHub Actions workflows to use Node.js version 20.19.0 instead of 24.15.0.
- Adjusted package.json files to reflect the new Node.js engine requirements.
- Updated pnpm-lock.yaml and TypeScript dependencies to ensure compatibility with the new Node.js version.
Andrew Khadder