* 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>
openapi-to-mcp twice tells the reader to switch to build-mcp-app, which this
repo does not ship. The widget skill here is mcp-apps-builder, which is also
the template named in the same sentence.
* docs(inspector): drop the stale SSE claim from the feature table
The Connect Panel hardcodes transportType to http and the same README says
Streamable HTTP only a few sections later, so the feature table was the
outlier. #2363 corrected the WebSocket half of this row and left the SSE half.
* docs(create-mcp-use-app): import MCPAgent from the langchain entry
The example passes a ChatOpenAI instance as llm, which only the langchain
MCPAgent accepts. The root entry types llm as string | ProviderConfig, so the
snippet fails to typecheck. The agent package README uses the same pairing
with @mcp-use/agent/langchain.
* 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>
* 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>
* 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>
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
* 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>
* docs(inspector): remove unsupported WebSocket and stdio transport claims
The Inspector README advertised WebSocket and stdio transports that are
not implemented. The client only supports Streamable HTTP (with SSE for
legacy servers), and the connect form no longer exposes a transport
selector. Update the Key Features table and the "Adding an MCP Server"
instructions to describe only the supported options.
Fixes#2361
* docs(inspector): clarify supported transport
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
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.
* 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.
* ci(links): stop the weekly link report flagging the Vite entry HTML
The Link Checker workflow opens an issue whenever lychee exits non-zero.
One of the two errors in this week's report (#2317) is not a broken link:
[ERROR] error: (at 5:49) | Cannot resolve root-relative link
'/favicon-black.svg?v=4': To resolve root-relative links in local
files, provide a root dir
packages/inspector/index.html is a Vite entry document. Its two absolute
paths, /favicon-black.svg?v=4 and /src/client/main.tsx, are dev-server
paths that Vite resolves from public/ and src/. Both files exist:
packages/inspector/public/favicon-black.svg
packages/inspector/src/client/main.tsx
lychee has no web root to resolve them against, and a repo-wide
--root-dir cannot supply one: pointed at the repo root it looks for
<repo>/favicon-black.svg and fails the same way.
Add the file to the exclude_path list that already skips generated
changelogs, with the reason inline. Offline run over every tracked
markdown and html file, before and after:
before 612 total, 1 error
after 610 total, 0 errors
The two links that stop being counted are the two Vite paths.
* ci(links): fix the changelog exclusion that names a directory that does not exist
exclude_path skips libraries/typescript/packages/mcp-use/CHANGELOG.md.
There is no such tracked directory: `mcp-use` is the npm package name,
and its source lives in packages/server.
$ git ls-files libraries/typescript/packages/mcp-use | wc -l
0
So that entry matches nothing and packages/server/CHANGELOG.md is still
scanned, which is not what the comment above the list intends. Point it at
the real path.
The effect today is small: that changelog currently holds one URL. The
entry was simply never doing its job.
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.
* feat(client): support RequestOptions for prompt reads (#2302)
* feat(client): support request options for prompts
* Apply suggestion from @cubic-dev-ai[bot]
Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>
Signed-off-by: Andrew Khadder <54488379+khandrew1@users.noreply.github.com>
---------
Signed-off-by: Andrew Khadder <54488379+khandrew1@users.noreply.github.com>
Co-authored-by: Andrew Khadder <54488379+khandrew1@users.noreply.github.com>
Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>
* chore: enter canary prerelease mode
* chore(typescript): version packages (canary)
* feat(inspector): correlate RPC response labels (#2303)
* feat(inspector): correlate RPC response labels
* fix(inspector): refine RPC latency label styling
* chore(typescript): version packages (canary)
* fix(server): restore Claude resource domain hashing in v2 (#2326)
* fix(server): restore Claude resource domain hashing in v2
v1.29.0 rewrote a view resource's `_meta.ui.domain` to
`<sha256(domain)[0..32]>.claudemcpcontent.com` when the reading client
advertised a name containing "claude". The v2 rewrite dropped that along
with the v1 server package, so Claude receives the authored `view.domain`
verbatim and refuses to render the view.
Restore the three helpers in `src/views/claude-domain.ts`. The digest and
the substring match are byte-for-byte the v1 ones, so a server upgrading
from v1 emits the same domain it did before; the v1 fixtures are ported
as unit tests. The digest uses Web Crypto rather than `node:crypto` to
keep the root module graph free of Node builtins for the Workers build.
Client identity reaches the `resources/read` handler through the
per-request `_meta` envelope (`io.modelcontextprotocol/clientInfo`) — the
same source `ctx.client.info()` already reads, extracted as
`requestClientInfo()` in `src/context.ts`. Non-Claude clients, an
already-hashed authored domain, and `resources/list` are all unchanged,
matching v1.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BAiXkmFngnfwhAeNuDbFKg
* docs(v2): drop the stale per-client View metadata limitation
The v2 migration guide's beta-limitations list stated that "v2 has no
supported hook for rewriting `domain` or other View resource metadata per
client". Restoring the Claude resource domain hashing makes that false —
`_meta.ui.domain` is now derived per requesting client on `resources/read`.
Remove the bullet outright rather than softening it. The rest of the Views
limitations list is unaffected and reads cleanly without it; the
`resources/list` and authoring surfaces it also described are covered by
the resource-facts guidance earlier in the same guide.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BAiXkmFngnfwhAeNuDbFKg
* fix(server): detect legacy Claude clients by user agent
* fix(server): lazy-load the Claude domain helper to stay under the edge budget
`tests/budgets/cli-budget.test.ts` caps the edge entry's static graph at
120 KiB. Statically importing `views/claude-domain.js` from `server.ts` put
the graph at 123061 bytes, 181 over the cap, failing CI on this branch
(`main` sits at 121721, so the branch consumed all 1159 bytes of headroom).
The `resources/read` callback is already async, so the helper loads through
a dynamic import at its one call site instead, matching the lazy-loading the
same budget test enforces for the CLI commands. The re-export from
`views/index.ts` is dropped so the module leaves the static graph; the unit
tests already import it from `views/claude-domain.js` directly. Behavior is
unchanged — the user-agent fallback and the hash are untouched.
Edge static graph: 123061 -> 122208 bytes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BAiXkmFngnfwhAeNuDbFKg
* fix(server): keep Claude domain helper in edge graph
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Andrew Khadder <andrew@manufact.com>
* chore(typescript): version packages (canary)
* docs: update TypeScript release changelogs
---------
Signed-off-by: Andrew Khadder <54488379+khandrew1@users.noreply.github.com>
Co-authored-by: WeiHaoxuan <156066259+Whxuan0701@users.noreply.github.com>
Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: Claude <noreply@anthropic.com>
* fix(typescript): truncate landing page hero URL instead of overflowing past copy button (#2313)
* 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.
* fix(typescript): truncate landing page hero URL instead of overflowing past copy button
On narrow (mobile) viewports the server URL is an unbreakable string
that overflowed the pill-shaped box and reappeared beyond the copy
button. The hero .url-box now truncates with an ellipsis, keeping the
full URL available via the copy button.
---------
Co-authored-by: saif-at-scalekit <saif.shaik@scalekit.com>
* chore: enter canary prerelease mode
* chore(typescript): version packages (canary)
* feat(inspector): export connection settings form (#2318)
* chore(typescript): version packages (canary)
---------
Co-authored-by: Marcin Zajkowski <zajkowski.dev@gmail.com>
Co-authored-by: saif-at-scalekit <saif.shaik@scalekit.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
* 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.
* fix(typescript): truncate landing page hero URL instead of overflowing past copy button
On narrow (mobile) viewports the server URL is an unbreakable string
that overflowed the pill-shaped box and reappeared beyond the copy
button. The hero .url-box now truncates with an ellipsis, keeping the
full URL available via the copy button.
---------
Co-authored-by: Marcin Zajkowski <zajkowski.dev@gmail.com>
Co-authored-by: saif-at-scalekit <saif.shaik@scalekit.com>
* fix(agent): count Anthropic cache tokens and stop message_delta erasing usage (#2127)
* fix(agent): count Anthropic cache tokens and stop message_delta erasing usage
Two counting bugs on the Anthropic path, both silent.
Anthropic reports `input_tokens` net of the prompt cache and bills
`cache_read_input_tokens` and `cache_creation_input_tokens` separately, so
`input_tokens + output_tokens` is not what the call is charged on. It never sends
`total_tokens`, so the computed branch is always the one that runs. A call billed on
21,623 tokens reported 123. `cache_creation_input_tokens` was not read anywhere in the
repository, and Anthropic bills cache writes above the base rate.
OpenAI is the opposite: its `cached_tokens` sits inside `prompt_tokens`, so adding it
would double count. Only the Anthropic-shaped keys are summed, and a test pins that.
Second, `tokenUsageFromRecord` returns every key and sets the ones it did not find to
`undefined`. Anthropic's streaming `message_delta` carries `output_tokens` only, so
`usage = { ...usage, ...deltaUsage }` overwrote `inputTokens` and `cachedInputTokens`
with `undefined`, discarding what `message_start` had already reported. After any
streamed call the whole input side of the accounting was gone, with nothing raised.
`mergeTokenUsage` merges only defined values. It does not touch `totalTokens`, because
whether a cache counter is additive is a provider question and that information is gone
once usage has been normalised, so the caller owns the total.
Three of the added tests fail on main.
* fix(agent,inspector): one owner for the Anthropic total, and stop the inspector dropping cache
Follow-up on the review. Four points were raised; three were right and are fixed, one
would have introduced a bug and the reasoning is below.
The same wrong total existed in a third place. `message_stop` recomputed it as
`inputTokens + outputTokens`, so the fix at `message_delta` survived only because `??`
short-circuited on the total already set. Two places knowing how Anthropic bills is how
this drifts, so `message_stop` now owns it alone and `message_delta` just merges. Added an
end-to-end test that drives real `message_start` then `message_delta` SSE through
`streamChat`, rather than exercising `mergeTokenUsage` in isolation. On the base commit it
reports `totalTokens: undefined`, not merely a wrong number, because the input counters
were gone by the time `message_stop` ran.
The inspector was dropping more than the new field. `InspectorTokenUsage` declares
`cachedInputTokens` and `reasoningTokens`, the trace view reads them, and
`inspectorTokenUsageFromUnknown` returned only `inputTokens`, `outputTokens` and
`totalTokens`. Both have always rendered as absent whatever the provider sent. It also
repeated the same input-plus-output total. Both fixed, and `cacheCreationInputTokens` is
carried through.
The merge test now seeds `cache_creation_input_tokens` too, since cache writes are billed
above base rate and need the same protection as cache reads.
Not done, deliberately: adding `cachedInputTokens` to the computed total inside
`tokenUsageFromRecord`. On Anthropic that counter sits outside `input_tokens`; on OpenAI
`cached_tokens` sits inside `prompt_tokens`. Once usage is normalised that distinction is
gone, so summing it would double count OpenAI. Only the Anthropic-shaped keys are added,
and a test pins the OpenAI case at 14.
* style(inspector): run prettier on trace.ts
format:check fails the typescript-lint job on this one file. Prettier wraps
the cachedInputTokens call across three lines, the way the two calls below it
already are. Formatting only, no behaviour change.
* fix(inspector): aggregate cacheCreationInputTokens and stop double-counting OpenAI cache reads
Addresses @khandrew1's review on #2127.
addUsage dropped cacheCreationInputTokens: the field was parsed onto individual
usage events but never summed, so it vanished from state.usage, the LLM span's
usage, and the aggregate tokenUsage in the raw-chat payload. It is now summed
alongside the other counters.
The fallback total could also over-count. uncountedCache was built from the
provider-neutral cachedInputTokens, but on OpenAI those tokens are already inside
inputTokens, so { inputTokens: 10, outputTokens: 4, cachedInputTokens: 3 }
totalled 17 instead of 14. The total now adds only the Anthropic-shaped
cache_read_input_tokens, mirroring the provider-safe path in agent/src/llm/usage.ts.
cachedInputTokens is still parsed and returned for observability.
Two tests in trace.test.ts pin both: the OpenAI-vs-Anthropic total distinction,
and that cacheCreationInputTokens survives aggregation and the LLM span. Changesets
added for @mcp-use/agent and @mcp-use/inspector.
* chore: enter canary prerelease mode
* chore(typescript): version packages (canary)
* fix(inspector): scope loading state by chat session (#2232)
* fix(inspector): give each chat session one id and one state record
Chat state lived in hook-wide React state, so starting a new chat cleared
the values an in-flight stream was still writing to: the fresh chat
inherited the previous session's loading state and could not send.
Rework it around a single identity. A session is created with one id and
keeps it; that id is handed to ChatStorageProvider.createChat, so runtime
state, chat history and OAuth retry all name the same chat. All of a
session's state and turn machinery live in one record inside
ChatSessionStore, which notifies only the subscribers of the session that
changed, so a background turn keeps streaming into its own record.
useChatSessions owns the lifecycle: minting ids, activating a session,
reattaching to persisted chats, and reopening the session a full-page
OAuth redirect interrupted. New Chat now only switches the active id.
Closes#2217
* refactor(inspector): simplify chat session state
* fix(inspector): harden chat session recovery
---------
Co-authored-by: Andrew Khadder <andrew@manufact.com>
* chore(typescript): version packages (canary)
* fix(ci): give inspector tests the same timeout as every other package (canary) (#2290)
* fix(ci): give inspector tests the same timeout as every other package
Same one-line change as #2268, which targets main. canary carries the same
10s cap and is failing on it independently:
run 32053629834 compressed-assets.test.ts 10230ms Test timed out in 10000ms
run 32051250836 same test
main is red on it too (run 32054211669). Recent margins are 10029ms, 10230ms
and 10837ms, all just over the cap.
The inspector is the only package at 10s; agent, client, cli and server all
use 60000, and these cases mount a server and decompress the bundled app.
45 files, 217 tests still pass locally.
* chore(ci): remove timeout rationale comment
---------
Co-authored-by: Andrew Khadder <andrew@manufact.com>
* feat(oauth): add Scalekit provider (#2272)
* feat(oauth): add Scalekit provider
Add oauthScalekitProvider next to Auth0 and Clerk. The verifier accepts
both environment-root and resource-scoped issuers, binds audience to the
res_… resource id, and advertises DCR plus CIMD. No Scalekit SDK.
* fix(oauth): keep Scalekit resource-id audience with extra aud
Always verify aud includes the resource id. Optional audience is an extra
AND check, not a replacement. Drop the new v1 provider page.
* fix(oauth): drop Scalekit issuerBoundAccessTokens option
Scalekit binds tokens to the resource id. The dashboard will own
that opt-in. Keep the static oauthMetadata copy because mcp-use
requires it. Custom claims stay on ctx.auth.payload.
* docs: drop v1 and legacy skill changes
* docs: fix Scalekit environment variables
---------
Co-authored-by: Saif Shines <saifshine7@gmail.com>
Co-authored-by: Andrew Khadder <andrew@manufact.com>
* chore(typescript): version packages (canary)
* fix(inspector): add a test script so pnpm test covers this package (#2289)
* fix(inspector): add a test script so pnpm test covers this package
The root test script is `pnpm run -r test`, and the inspector only had
test:unit. pnpm skips a package with no matching script and reports nothing,
so 217 unit tests were absent from the workspace-wide run:
$ pnpm --filter @mcp-use/inspector test
(no output)
$ pnpm --filter @mcp-use/inspector test:unit
Test Files 45 passed (45)
Tests 217 passed (217)
CI is unaffected; its step calls test:unit directly. This is the documented
`pnpm test` contributors run.
Uses run mode rather than watch, matching tunnel, so a recursive run cannot
sit waiting on a watcher.
* chore(inspector): remove test-only changeset
---------
Co-authored-by: Andrew Khadder <andrew@manufact.com>
* fix(types): align pnpm workspace tooling (#2301)
* docs: update TypeScript release changelogs
* fix(inspector): use secure chat session ids
---------
Co-authored-by: Arthi Arumugam <62213284+arthi-arumugam-git@users.noreply.github.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Mert Çetin <97505365+merttcetn@users.noreply.github.com>
Co-authored-by: Ayaan Gazali <ayaangazali.work@gmail.com>
Co-authored-by: saif-at-scalekit <saif.shaik@scalekit.com>
Co-authored-by: Saif Shines <saifshine7@gmail.com>
* docs(skills): drop baseUrl from the openapi-to-mcp server config
The skills rewrite in #2286 did not reach this one. MCPServer still rejects
baseUrl on current main:
error TS2353: Object literal may only specify known properties,
and 'baseUrl' does not exist in type 'ServerConfig<never>'.
The skill also says the scaffold provides that field; it does not, the
create-mcp-use-app template sets name, title, version and description.
Unrelated and left alone: MCPServer.fromOpenAPI() does accept baseUrl
(FromOpenAPIOptions), so the advanced-features references are correct.
* 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>
* 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>
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.
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.
github-actions[bot]