The UploadKit server provides tools to discover components, scaffold project setup, configure storage, and access documentation for integrating UploadKit into React/Next.js projects.
list_components: Enumerate all 40+ React upload components, optionally filtered by category (classic, dropzone, button, progress, motion, specialty, gallery).
get_component: Fetch full metadata and a ready-to-paste TSX usage example for a specific component by its PascalCase name.
search_components: Fuzzy-search the component catalog by keyword, vibe, or design inspiration (e.g. "apple", "stripe checkout", "matrix").
get_install_command: Generate the shell command to install UploadKit packages for a given package manager (pnpm, npm, yarn, or bun).
scaffold_route_handler: Generate a complete Next.js App Router upload route handler file with configurable route name, file size limits, allowed MIME types, and max file count.
scaffold_provider: Return a snippet for wrapping the Next.js root layout with <UploadKitProvider>.
get_byos_config: Generate Bring-Your-Own-Storage configuration (env variables + handler code) for AWS S3, Cloudflare R2, Google Cloud Storage, or Backblaze B2.
get_quickstart: Return a complete end-to-end UploadKit setup walkthrough for Next.js.
search_docs: Full-text search across 88+ UploadKit documentation pages.
get_doc: Fetch the full markdown content of a specific documentation page by its path.
list_docs: Enumerate all available documentation pages with titles, descriptions, and paths.
Provides premium upload components with Apple-inspired Aurora design theme for file upload interfaces.
Supports Backblaze B2 as a storage provider for file uploads through BYOS (Bring Your Own Storage) mode.
Integrates with Cloudflare R2 for managed storage and supports R2 as a BYOS storage provider.
Supports Google Cloud Storage as a storage provider for file uploads through BYOS (Bring Your Own Storage) mode.
Provides premium upload components with Linear-inspired Glass design theme for file upload interfaces.
Provides premium upload components with Raycast-inspired Terminal design theme for file upload interfaces.
Provides premium upload components with Vercel-inspired Glass design theme for file upload interfaces.
Provides upload components with Warp-inspired DataStream design for file upload interfaces.
Provides upload components with WeTransfer-inspired Envelope design for file upload interfaces.
File uploads for developers. Beautifully.
Open-source TypeScript SDK + 40+ premium React components + managed storage on Cloudflare R2 — with BYOS (Bring Your Own Storage) mode so you can use your own S3, R2, GCS, or Backblaze B2 bucket. 5 GB free forever.
Website · Docs · Dashboard · Changelog
Most people land here with a Next.js app already running. Three steps:
pnpm add @uploadkitdev/react @uploadkitdev/nextCreate app/api/uploadkit/[...uploadkit]/route.ts:
import { createUploadKitHandler, type FileRouter } from '@uploadkitdev/next';
const router = {
default: { maxFileSize: '4MB', allowedTypes: ['image/*'] },
} satisfies FileRouter;
export const { GET, POST } = createUploadKitHandler({
router,
apiKey: process.env.UPLOADKIT_API_KEY!,
});Wrap the root layout and drop in a dropzone:
// app/layout.tsx
import { UploadKitProvider } from '@uploadkitdev/react';
// <UploadKitProvider endpoint="/api/uploadkit">{children}</UploadKitProvider>
// any page
import { UploadDropzone } from '@uploadkitdev/react';
// <UploadDropzone route="default" />Set UPLOADKIT_API_KEY=uk_live_... in .env.local and you're done. Full walkthrough: docs.uploadkit.dev/docs/getting-started/quickstart.
npx uploadkit initDetects your framework, installs deps, creates the route handler, and wraps your layout — all in one command. See the CLI guide for details.
npx create-uploadkit-app my-appTemplates for Next.js, SvelteKit, Remix, and Vite — see the CLI guide.
Install the UploadKit MCP server and let Claude Code, Cursor, Windsurf, or Zed wire the whole thing up for you:
npx -y @uploadkitdev/mcpRelated MCP server: Rendobar MCP Server
Package | Version | Description |
Framework-agnostic upload client (browser, Node, Edge) | ||
40+ premium React upload components | ||
Next.js App Router handler + Express/Hono adapters | ||
Official MCP server for AI coding assistants | ||
Scaffolder for new projects (Next, SvelteKit, Remix, Vite) |
UploadKit ships 40+ components across 7 categories:
Classics — UploadButton, UploadDropzone, UploadModal, FileList, FilePreview
Premium dropzones — Glass (Vercel/Linear), Aurora (Apple), Terminal (Raycast), Brutal (Neo-brutalist), Minimal, Neon
Specialty — UploadAvatar, UploadInlineChat (ChatGPT-style), UploadStepWizard (Stripe Checkout-style), UploadEnvelope (WeTransfer-style)
Motion / Progress — UploadProgressRadial, UploadProgressLiquid, UploadProgressOrbit, UploadCloudRain, UploadBento, UploadParticles, UploadDataStream (Matrix/Warp-style)
Galleries — UploadGalleryGrid, UploadPolaroid, UploadTimeline, UploadKanban, UploadStickyBoard
All are MIT-licensed, dark mode out of the box, themeable via CSS custom properties, and work with or without motion as a peer dep.
Use the same SDK against your own bucket — zero frontend changes, credentials stay server-side.
import { createUploadKitHandler, type FileRouter } from '@uploadkitdev/next';
import { createR2Storage } from '@uploadkitdev/next/byos';
const router = {
media: { maxFileSize: '8MB', maxFileCount: 4, allowedTypes: ['image/*'] },
} satisfies FileRouter;
export const { GET, POST } = createUploadKitHandler({
router,
storage: createR2Storage({
accountId: process.env.CLOUDFLARE_R2_ACCOUNT_ID!,
accessKeyId: process.env.CLOUDFLARE_R2_ACCESS_KEY_ID!,
secretAccessKey: process.env.CLOUDFLARE_R2_SECRET_ACCESS_KEY!,
bucket: process.env.CLOUDFLARE_R2_BUCKET!,
}),
});Supported providers: AWS S3 · Cloudflare R2 · Google Cloud Storage · Backblaze B2.
UploadKit ships an official Model Context Protocol server so Claude Code, Cursor, Windsurf, Zed, ChatGPT, and Claude.ai can generate UploadKit code with first-class knowledge of every component and scaffold.
Stdio (IDE clients):
npx -y @uploadkitdev/mcpRemote HTTP (ChatGPT / Claude.ai web):
https://api.uploadkit.dev/api/v1/mcpFull setup: docs.uploadkit.dev/docs/guides/mcp · Source: packages/mcp · Registry: io.github.drumst0ck/uploadkit
apps/
web Landing + pricing (uploadkit.dev)
docs Fumadocs site (docs.uploadkit.dev)
dashboard SaaS dashboard (app.uploadkit.dev)
api REST API + MCP remote endpoint (api.uploadkit.dev)
packages/
core @uploadkitdev/core
react @uploadkitdev/react
next @uploadkitdev/next
mcp @uploadkitdev/mcp (stdio MCP server)
mcp-core shared MCP tool surface (internal)
create-uploadkit-app scaffolder for new projects
db MongoDB models
emails React Email templates
shared types, errors, utilities
ui dashboard components
config shared tsconfig / eslint / tailwind baseNext.js 16 · React 19 · Tailwind CSS v4 · TypeScript 5 · MongoDB + Mongoose · Cloudflare R2 · Auth.js v5 · Stripe · Resend + React Email · Fumadocs · Turborepo · pnpm · Changesets.
Version 1.0 shipped. Actively maintained. Issues and contributions are welcome on GitHub.
MIT © Drumst0ck and contributors.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | Yes | The storage provider to configure. "s3" = AWS S3 (watch egress costs). "r2" = Cloudflare R2 (recommended — zero egress fees). "gcs" = Google Cloud Storage via HMAC interop. "b2" = Backblaze B2 (S3-compatible, cheap egress). Choose based on where the user's bucket already lives. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: read-only, deterministic, no network calls, no secrets exposed. It also notes the return structure. Could mention error handling for invalid provider, but schema covers validation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with three clear paragraphs: purpose, usage guidelines, and return details. No redundant sentences, appropriately sized for the information provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, the description fully explains the return format (three sections) and key properties (plain-text string, credentials server-side). No gaps remain for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already provides detailed descriptions for each enum value. The tool description does not add new parameter semantics beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool generates a BYOS configuration for a specific storage provider, using a specific verb ('Generate') and resource ('Bring-Your-Own-Storage configuration for an UploadKit Next.js handler'). It distinguishes itself from siblings like scaffold_provider by focusing on config generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'When to use:' with specific triggers (compliance, existing infra, vendor lock-in). Does not provide when-not-to-use or alternative tools, but the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Exact PascalCase component name. Case-sensitive. Examples: "UploadDropzone", "UploadDropzoneAurora", "UploadProgressRadial", "UploadDataStream". Must match one of the names returned by list_components. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully covers behavioral traits: it is read-only, idempotent, returns JSON with specific fields, and on no match returns a suggestion message with the 5 closest matches.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three short paragraphs, each adding essential information: what it returns, when to use, and behavior on error. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema), the description is fully complete. It covers purpose, input requirements, return structure, error behavior, and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the parameter 'name' with a detailed description including examples and case sensitivity. The description adds value by reiterating case-sensitivity and the requirement that the name must match from list_components, but the schema already does most of the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches metadata and a React usage example for one specific UploadKit component. It distinguishes from siblings like list_components or search_components by specifying that it requires an exact component name and returns a usage example.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states '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.' This gives clear context and mentions the prerequisite tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Docs page path relative to /docs, WITHOUT leading slash and WITHOUT .mdx extension. Examples: "core-concepts/byos", "sdk/next/middleware", "api-reference/rest-api", "guides/avatar-upload". Get valid paths from search_docs results (the "path" field) or list_docs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only and idempotent behavior, return format, and error handling (not-found message suggesting list_docs). No annotations were provided, so description carries full burden and meets it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: purpose, usage, and return/error. No wasted words, front-loaded with key info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description explains return format. Only one parameter with full details. Safety (read-only) is covered. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed description. The description adds extra context: examples of valid paths and instructions to get them from search_docs or list_docs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches full markdown content by path, formatted with specific parts. It distinguishes from siblings like search_docs and list_docs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use after search_docs, prefers search_docs first, and explains why full page read avoids snippet gaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| packageManager | No | Which package manager's syntax to output. Default: "pnpm". Pick the one the user's project actually uses — check their lockfile. | pnpm |
| packages | No | Which UploadKit packages to install. Omit to get the default full-stack set: ["@uploadkitdev/react", "@uploadkitdev/next"]. Pass a subset to scope the command, e.g. ["@uploadkitdev/core"] for a framework-agnostic project, or ["@uploadkitdev/react"] for a React app without Next.js. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states the tool is read-only, idempotent, and never modifies anything. It also describes the return format. This is strong disclosure for a simple read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct with three focused paragraphs: purpose, usage guidelines, and return/safety. Every sentence adds value without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description covers all necessary aspects: return format, usage context, parameter defaults, and behavioral traits. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the context for package manager detection, defaults, and examples for package subsets. This enriches parameter understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool's purpose: returning the exact shell command to install UploadKit packages for a given package manager. It uses specific verbs and resources, and distinguishes itself from sibling tools like list_components or get_doc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use: before asking the user to add dependencies, and to match the package manager. It suggests detection based on lockfiles. While it does not explicitly list exclusions, the sibling tools are distinct enough that no confusion arises.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses return type (plain-text markdown), no parameters, read-only nature, static content, and idempotency, covering all behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with well-organized sections: what it does, when to use, what it returns. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description covers all necessary context: content, usage conditions, and alternatives. It is fully complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage, the description confirms 'Takes no parameters,' which is sufficient. Baseline for 0 params is 4, and no additional detail is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a complete quickstart walkthrough for Next.js, enumerating specific components (install, env, route handler, etc.). It distinguishes itself from sibling tools by mentioning the scope and content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides when to use (brand-new users asking general questions) and when to prefer alternatives (specific steps), naming sibling tools like scaffold_route_handler and get_install_command.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Optional filter. Narrows the list to one category. Omit to get every component. Values: "classic" (the original 5 primitives like UploadButton/UploadDropzone), "dropzone" (styled drag-and-drop variants), "button" (styled button variants with motion), "progress" (upload progress indicators), "motion" (motion-forward visualizations like data streams, particles), "specialty" (avatars, chat composers, wizards, envelopes), "gallery" (multi-file layouts like grid, timeline, kanban). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the tool is 'Read-only, no side effects, idempotent' and describes the return JSON shape. This is sufficient for a list tool, though further details like authentication or rate limits are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with three sections (purpose, when to use, returns) that are appropriately front-loaded. Every sentence adds value, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description is complete. It explains what is returned, when to use, and the general behavior. The context signals show high schema coverage, and the description effectively complements the structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter 'category' with 100% description coverage, so baseline is 3. The description does not add extra meaning beyond what the schema already provides, so no improvement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what the tool does: lists all React upload components with specific fields (name, category, description, inspiration). It distinguishes from sibling tools like get_component and search_components by its purpose and output structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'When to use: before recommending or scaffolding any UploadKit component' and gives an example about browsing dropzone variants. This clearly guides the agent on context and contrasts with other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully compensates by declaring read-only, static at bundle time, idempotent, and describing return format and sorting. Transparent about behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three well-structured sentences with front-loaded purpose, usage guidance, and return format. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description provides complete context: purpose, usage, return shape (JSON with fields), sorting, and safety guarantees.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4. Description adds nothing about parameters, which is appropriate since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool enumerates all docs pages with title, description, URL, and path. Differentiates from sibling search_docs by specifying when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (discovery before targeted searching) and when to prefer search_docs (concrete question). Provides clear decision guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, description explicitly states read-only, deterministic, idempotent, and explains no parameters and fixed endpoint. Fully discloses behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short paragraphs, each serving a clear purpose: what it returns, when to use, additional traits. Front-loaded with the main outcome. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully covers all needed information for a zero-parameter tool: return format (plain text with code block), location (app/layout.tsx), dependency (scaffold_route_handler), and safety guarantees. No output schema needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so schema coverage is 100% by default. Description goes beyond by explaining why there are no parameters (endpoint path always /api/uploadkit from scaffold_route_handler), which adds value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns a ready-to-paste snippet for Next.js root layout with UploadKitProvider, which is a specific verb+resource. Distinguishes from sibling scaffold_route_handler by specifying it's the next step in wiring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'When to use: right after scaffold_route_handler' and warns that without it, components throw at runtime. Provides clear context and alternative (scaffold_route_handler).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| routeName | Yes | The key for this file route in the `FileRouter` object. This exact string is what consumers pass as the `route` prop on components (e.g. `<UploadDropzone route="media" />`). Use a short lowercase identifier matching the file-category — examples: "media" for a general images+videos endpoint, "avatar" for user profile pictures, "attachments" for message/ticket attachments, "documents" for PDFs. | |
| maxFileSize | No | Maximum allowed size per uploaded file, expressed with a unit suffix. Examples: "4MB" (default), "512KB", "1GB", "100MB". Omit to use the default of "4MB". Rejects uploads larger than this value with a 413 response. | |
| allowedTypes | No | MIME types (or wildcard patterns) that this route accepts. Examples: ["image/*"] (default — any image), ["image/jpeg", "image/png"] (two specific types), ["application/pdf"] (PDF only), ["image/*", "video/mp4"] (images plus MP4). Omit for the default of ["image/*"]. Rejects mismatched uploads with a 415 response. | |
| maxFileCount | No | Maximum number of files per single upload request. Default: 1. Set to a larger number to enable multi-file drag-and-drop (e.g. 10 for gallery uploaders). Must be >= 1. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the key behavioral trait: it is read-only and never touches the filesystem, only generating text output. Since no annotations are provided, this carries full burden and does so effectively, with no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences) and front-loaded with the core action and key details. Every sentence adds value, and there is no unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (code generation with clear output), the description covers essential context: the exact file path to write, the return format, and the read-only nature. It could mention error handling or file creation confirmation, but the current level is sufficient for an informed agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds some context (e.g., the output format and disc attributes), but the schema already provides detailed descriptions with examples and defaults for each parameter. Thus, the description adds marginal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates complete file content for a Next.js App Router upload route handler, specifying the exact file path and that it returns a compilable TypeScript file. It distinguishes from sibling tools which deal with config, components, or documentation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an explicit 'When to use' section that provides context for when this tool is appropriate. While it does not explicitly state when not to use it or mention alternatives, the usage context is clear and sufficient for an AI agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Free-text search string. Case-insensitive substring match against name, category, description, and inspiration fields. Examples: "terminal", "apple", "progress ring", "kanban", "vercel", "matrix". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and declares read-only, idempotent, case-insensitive behavior. This is good, though it could mention any rate limits or permission requirements if applicable. Still, it provides sufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three well-structured sentences: purpose+examples, usage guidance, return format+behavior. Every sentence adds unique value with no redundancy. Front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explicitly states the return structure (JSON with query, count, matches array with name, category, description, inspiration). Combined with parameter clarity and behavioral notes, it is fully complete for the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the 'query' parameter well (100% coverage). The description adds value by giving concrete examples and explaining the fuzzy-search nature, going beyond the schema's substring match description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs fuzzy-search of the UploadKit component catalog by free-text keyword, providing multiple examples. It distinguishes itself from sibling tool 'list_components' by specifying that it is for discovery rather than enumeration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (user describes vibe but no component name) and when to prefer alternatives (list_components for enumeration). The second sentence provides clear context for choosing this tool over its sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Free-text search query. Multiple words are ANDed with per-field weighting (title matches score highest). Examples: "middleware onUploadComplete", "theming css variables", "presigned url", "migration uploadthing". | |
| limit | No | Maximum number of matches to return. Default: 8. Range 1-50. Use smaller values (3-5) when you already have a narrow query; use larger values (15-20) for exploratory scans across the whole docs site. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully compensates: discloses read-only nature, bundled index (no network call), sorted results, build-time freshness, and scope limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with main action, followed by scope, usage guidelines, and return format. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description thoroughly explains return format (JSON structure). Combined with full parameter coverage and behavioral details, it is perfectly complete for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage, but description adds significant value: query parameter details (ANDed, per-field weighting, examples), limit parameter with default, range, and usage guidance for narrow vs. exploratory scans.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states full-text search across all UploadKit docs pages (88+ pages, specific categories), ranks by keyword frequency, and distinguishes from sibling component tools by listing covered topics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' section with specific scenarios (middleware, webhooks, etc.) and implies alternative when component tools suffice, providing clear context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.1get_byos_config1 field changedInput schema / properties / provider / descriptionAdded value: +"The storage provider to configure. \"s3\" = AWS S3 (watch egress costs). \"r2\" = Cloudflare R2 (recommended — zero egress fees). \"gcs\" = Google Cloud Storage via HMAC interop. \"b2\" = Backblaze B2 (S3-compatible, cheap egress). Choose based on where the user's bucket already lives."get_component1 field changedInput schema / properties / name / descriptionPrevious value: -"Exact component name, e.g. \"UploadDropzoneAurora\"."New value: +"Exact PascalCase component name. Case-sensitive. Examples: \"UploadDropzone\", \"UploadDropzoneAurora\", \"UploadProgressRadial\", \"UploadDataStream\". Must match one of the names returned by list_components."get_doc1 field changedInput schema / properties / path / descriptionPrevious value: -"Page path relative to /docs (no leading slash, no .mdx extension)."New value: +"Docs page path relative to /docs, WITHOUT leading slash and WITHOUT .mdx extension. Examples: \"core-concepts/byos\", \"sdk/next/middleware\", \"api-reference/rest-api\", \"guides/avatar-upload\". Get valid paths from search_docs results (the \"path\" field) or list_docs."get_install_command2 fields changedInput schema / properties / packageManager / descriptionAdded value: +"Which package manager's syntax to output. Default: \"pnpm\". Pick the one the user's project actually uses — check their lockfile."Input schema / properties / packages / descriptionPrevious value: -"Which UploadKit packages to install. Default: [\"@uploadkitdev/react\", \"@uploadkitdev/next\"]."New value: +"Which UploadKit packages to install. Omit to get the default full-stack set: [\"@uploadkitdev/react\", \"@uploadkitdev/next\"]. Pass a subset to scope the command, e.g. [\"@uploadkitdev/core\"] for a framework-agnostic project, or [\"@uploadkitdev/react\"] for a React app without Next.js."list_components1 field changedInput schema / properties / category / descriptionPrevious value: -"Optional filter."New value: +"Optional filter. Narrows the list to one category. Omit to get every component. Values: \"classic\" (the original 5 primitives like UploadButton/UploadDropzone), \"dropzone\" (styled drag-and-drop variants), \"button\" (styled button variants with motion), \"progress\" (upload progress indicators), \"motion\" (motion-forward visualizations like data streams, particles), \"specialty\" (avatars, chat composers, wizards, envelopes), \"gallery\" (multi-file layouts like grid, timeline, kanban)."scaffold_route_handler4 fields changedInput schema / properties / allowedTypes / descriptionPrevious value: -"MIME types allowed. Default: [\"image/*\"]."New value: +"MIME types (or wildcard patterns) that this route accepts. Examples: [\"image/*\"] (default — any image), [\"image/jpeg\", \"image/png\"] (two specific types), [\"application/pdf\"] (PDF only), [\"image/*\", \"video/mp4\"] (images plus MP4). Omit for the default of [\"image/*\"]. Rejects mismatched uploads with a 415 response."Input schema / properties / maxFileCount / descriptionPrevious value: -"Default: 1."New value: +"Maximum number of files per single upload request. Default: 1. Set to a larger number to enable multi-file drag-and-drop (e.g. 10 for gallery uploaders). Must be >= 1."Input schema / properties / maxFileSize / descriptionPrevious value: -"Max file size, e.g. \"4MB\", \"1GB\". Default: \"4MB\"."New value: +"Maximum allowed size per uploaded file, expressed with a unit suffix. Examples: \"4MB\" (default), \"512KB\", \"1GB\", \"100MB\". Omit to use the default of \"4MB\". Rejects uploads larger than this value with a 413 response."Input schema / properties / routeName / descriptionPrevious value: -"Name of the file route, e.g. \"media\", \"avatar\", \"attachments\". This is the value you pass as the `route` prop on components."New value: +"The key for this file route in the `FileRouter` object. This exact string is what consumers pass as the `route` prop on components (e.g. `<UploadDropzone route=\"media\" />`). Use a short lowercase identifier matching the file-category — examples: \"media\" for a general images+videos endpoint, \"avatar\" for user profile pictures, \"attachments\" for message/ticket attachments, \"documents\" for PDFs."search_components1 field changedInput schema / properties / query / descriptionPrevious value: -"Free-text search."New value: +"Free-text search string. Case-insensitive substring match against name, category, description, and inspiration fields. Examples: \"terminal\", \"apple\", \"progress ring\", \"kanban\", \"vercel\", \"matrix\"."search_docs2 fields changedInput schema / properties / limit / descriptionPrevious value: -"Max results. Default: 8."New value: +"Maximum number of matches to return. Default: 8. Range 1-50. Use smaller values (3-5) when you already have a narrow query; use larger values (15-20) for exploratory scans across the whole docs site."Input schema / properties / query / descriptionPrevious value: -"Free-text query."New value: +"Free-text search query. Multiple words are ANDed with per-field weighting (title matches score highest). Examples: \"middleware onUploadComplete\", \"theming css variables\", \"presigned url\", \"migration uploadthing\"."v0.1.0get_byos_configget_componentget_docget_install_commandget_quickstartlist_componentslist_docsscaffold_providerscaffold_route_handlersearch_componentssearch_docsEvery tool has a clear, distinct purpose. There is no overlap between installation, scaffolding, component discovery, documentation, and BYOS configuration tools. An agent can easily select the right tool for each task.
All tools follow a consistent verb_noun pattern using underscores (e.g., get_install_command, scaffold_route_handler, search_components). No mixing of conventions, making it predictable and easy to understand.
With 11 tools, the set is well-scoped for its purpose—covering installation, scaffolding, component discovery, documentation, and BYOS configuration. No tool feels extraneous, and the count is manageable without being too thin.
The tool surface covers the full developer workflow: install, set up route handler and provider, get quickstart, discover and retrieve components, search and fetch documentation, and configure BYOS. There are no obvious gaps for the stated domain of setting up UploadKit.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Official MCP server for subfeed.app — the cloud for agents. 15+ tools for AI agents to register, build, and deploy other agents. Zero human required. Start here: subfeed.app/skill.md
Official MCP server for Lovable, the AI-powered full-stack app builder.
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/drumst0ck/uploadkit'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
