mirror of
https://github.com/mcp-use/mcp-use.git
synced 2026-09-14 18:06:01 +08:00
Andrew Khadder
f2f4fdbf33
* 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>