Uploadkit

List every React upload component shipped by @uploadkitdev/react with its name, category, one-line description, and design inspiration.

When to use: before recommending or scaffolding any UploadKit component, to confirm the exact name exists and to pick the right variant for the user's context (e.g. browse all "dropzone" variants when the user wants a drag-and-drop area).

Returns: JSON { count, components: [{ name, category, description, inspiration }] }. Read-only, no side effects, idempotent.

Fetch full metadata plus a ready-to-paste React usage example for one specific UploadKit component.

When to use: once you know the exact component name (from list_components or search_components) and need to show the user how to drop it into their code. The returned "usage" field is copy-pasteable TSX including the correct import line and the styles.css import.

Returns: JSON { name, category, description, inspiration, usage }. If the name does not match any component, returns a suggestion message with the 5 closest matches. Read-only, idempotent.

Fuzzy-search the UploadKit component catalog by any free-text keyword — component name, category, description, or design inspiration (e.g. "apple", "stripe", "vercel", "terminal", "progress ring", "kanban board", "matrix").

When to use: the user describes the vibe or use case but does not know the component name yet ("I want something like Stripe Checkout", "show me Apple-style uploaders"). Prefer this over list_components when the goal is discovery rather than enumeration.

Returns: JSON { query, count, matches: [{ name, category, description, inspiration }] }. Read-only, idempotent, case-insensitive.

Return the exact shell command to install UploadKit packages for a given package manager.

When to use: before asking the user to add dependencies — match their package manager (detect from the presence of pnpm-lock.yaml / package-lock.json / yarn.lock / bun.lockb if you can, otherwise ask or default to pnpm). Saves you from guessing pnpm vs npm vs yarn vs bun syntax.

Returns: a plain-text shell command as a single string (e.g. "pnpm add @uploadkitdev/react @uploadkitdev/next"). Read-only, idempotent, never modifies anything.

Generate the complete file content for a Next.js App Router upload route handler — typed file router, handler export, correct path comment.

When to use: when the user is setting up UploadKit server-side in a Next.js App Router project and needs the app/api/uploadkit/[...uploadkit]/route.ts file created. The returned string is a complete, compilable TypeScript file — write it to disk as-is.

Returns: a markdown-formatted string containing the target path and the complete TS source inside a fenced code block. You must create the file at the literal path app/api/uploadkit/[...uploadkit]/route.ts. Read-only — generates text, never touches the filesystem itself.

Return a ready-to-paste snippet that wraps the Next.js root layout with <UploadKitProvider> so React components can talk to the upload route handler.

When to use: right after scaffold_route_handler, to complete the wiring. The snippet goes in app/layout.tsx. Without the provider, UploadKit React components throw at runtime.

Returns: a plain-text string containing a short explanatory note followed by a fenced tsx code block. Takes no parameters — the endpoint path is always /api/uploadkit since that is what scaffold_route_handler produces. Read-only, deterministic, idempotent.

Generate Bring-Your-Own-Storage (BYOS) configuration for an UploadKit Next.js handler — environment variables, handler code, and setup notes for a specific storage provider.

When to use: the user wants to store uploads in their own cloud bucket instead of UploadKit's managed R2. Typical triggers: compliance/data-residency requirements, existing bucket infra, desire to avoid vendor lock-in.

Returns: a plain-text string with three sections — provider-specific notes, the .env variable block, and the TypeScript handler code. Credentials are always server-side; the browser never sees them. Read-only, deterministic. No network calls, no secrets exposed.

Return the complete UploadKit quickstart walkthrough for Next.js — install, API key env, route handler, provider, first component, optional BYOS — in one markdown document.

When to use: the user is brand new to UploadKit and asks "how do I get started?", "set this up for me", or any variation that signals zero prior context. Prefer scaffold_route_handler + scaffold_provider + get_install_command when you already know which specific step they need.

Returns: a plain-text markdown document. Takes no parameters. Read-only, static content, idempotent.

Full-text search across every UploadKit docs page (88+ pages — getting-started, core-concepts, SDK reference, API reference, dashboard, guides). Ranks matches by keyword frequency in title, description, and body.

When to use: any question about UploadKit behaviour, configuration, or integration that the component tools do not answer — middleware, onUploadComplete callbacks, REST API endpoints, webhooks, presigned URLs, CSS theming variables, type-safety setup, migration from UploadThing, rate limits, etc.

Returns: JSON { query, count, indexGeneratedAt, matches: [{ path, url, title, description, snippet, score }] }. Sorted by score descending. Read-only. Bundled index (no network call) — results reflect docs at build time.

Fetch the full markdown content of a single UploadKit docs page by its path, formatted with title, description, source URL, and the body.

When to use: after search_docs identifies a relevant page and you need its full contents to answer a deep question — prefer search_docs first, then get_doc on the top result. Reading the full page avoids relying on snippets that may omit critical context (callbacks, env vars, edge cases).

Returns: a plain-text string — "# {title}\n\n> {description}\n\nSource: {url}\n\n---\n\n{content}". If the path is unknown, returns a not-found message suggesting list_docs. Read-only, idempotent.

Enumerate every available UploadKit docs page with title, description, URL, and path.

When to use: to discover what documentation exists before targeted searching, or to orient yourself around the shape of the docs site. Prefer search_docs when you already have a concrete question.

Returns: JSON { count, generatedAt, pages: [{ path, url, title, description }] }. Pages are sorted alphabetically by path. Read-only, static at bundle time, idempotent.