Uploadkit
Server Details
Official MCP server for UploadKit, the file-uploads platform for developers. Gives Claude Code, Cursor, Windsurf, and Zed first-class knowledge of UploadKit's 40+ open-source React components, Next.js route handler scaffolding, wiring, BYOS (S3/R2/GCS/B2) configuration, and full-text search across 88+ docs pages. Runs locally via npx — no API key, no telemetry, no config.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.8/5 across 11 of 11 tools scored.
Every tool has a clearly distinct purpose: get, list, search, and scaffold variants target specific resources (components, docs, code snippets) with no overlap.
All tools follow a consistent verb_noun pattern (get_*, list_*, search_*, scaffold_*), with clear verbs for single fetch, enumeration, fuzzy search, and code generation.
The 11 tools cover the full scope of the server—installation, documentation, component discovery, scaffolding, and BYOS config—without being excessive or insufficient.
The tool set covers the entire user journey: getting started, installing, scaffolding, exploring components, reading docs, and configuring BYOS. No obvious gaps for the stated domain.
Available Tools
11 toolsget_byos_configAInspect
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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: returns plain-text string with three sections, read-only and deterministic, no network calls, no secrets exposed. This covers side effects, idempotency, and security implications.
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 a clear front-loaded purpose, followed by usage guidance and return details. Every sentence adds essential information without fluff.
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 parameter, no output schema), the description fully covers purpose, usage, behavior, and return format. It leaves no gaps for an agent to misunderstand or misuse the tool.
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 100% of parameters (provider enum). The description adds value by advising choice based on existing bucket location and including provider-specific notes in the enum descriptions, complementing the schema without redundancy.
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 'Generate Bring-Your-Own-Storage (BYOS) configuration for an UploadKit Next.js handler' with specific deliverables (environment variables, handler code, setup notes). It distinguishes from sibling tools like scaffold_provider by focusing on configuration generation for a specific handler.
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 a 'When to use' section that explains the tool is for users wanting their own cloud bucket instead of managed R2, citing compliance, existing infra, and avoiding vendor lock-in. It does not explicitly exclude sibling tools but provides clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_componentAInspect
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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states that the tool is 'Read-only, idempotent' and describes the return format and error behavior (suggestion message with 5 closest matches if name not found). This is good disclosure, though it does not mention auth or rate limits, which is acceptable for a simple fetch operation.
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 and well-structured. The first sentence states the core purpose, followed by usage guidelines and return details. Every sentence adds value, and there is no unnecessary repetition. It is front-loaded for quick understanding.
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 only one parameter and no output schema, the description adequately explains the return format (JSON with fields name, category, description, inspiration, usage) and error handling. It also notes the read-only, idempotent nature. This is sufficient for an agent to use the tool 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?
Schema coverage is 100% and the schema already provides detailed description including examples, case-sensitivity, and requirement. The tool description reinforces the context but does not add new semantic information beyond what is in the schema. Baseline 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 the tool fetches full metadata and a ready-to-paste React usage example for a specific UploadKit component. It distinguishes from siblings like list_components and search_components by specifying that it is used when the exact component name is already known.
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 says '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 provides clear context and references alternative tools, making it easy for the agent to decide when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_docAInspect
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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully discloses behavior: returns plain-text string with format, error handling for unknown paths, and states read-only/idempotent. Comprehensive.
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?
Concise, four sentences front-loaded with purpose, then usage, return format, and error case. 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?
Tool is simple with one parameter; description covers return format, error behavior, and usage context. Complete for agent decision-making without output schema.
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%, but description adds valuable context on path format (relative, no slash, no .mdx) and explains how to obtain valid paths from search_docs or list_docs. Significantly enhances 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 fetches full markdown content of a single UploadKit docs page by path, specifying title, description, source URL, and body. 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 advises using search_docs first, then get_doc on the top result, and mentions not-found message suggests list_docs. Lacks explicit 'when not to use' but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_install_commandAInspect
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 |
|---|---|---|---|
| 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. | |
| packageManager | No | Which package manager's syntax to output. Default: "pnpm". Pick the one the user's project actually uses — check their lockfile. | pnpm |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: read-only, idempotent, never modifies anything, and returns a plain-text shell command. This gives the agent complete confidence in the operation's side effects.
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?
Concise and well-structured: the first sentence states the primary purpose, the second provides usage guidance, and the third explains return format and behavioral traits. 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 no output schema, the description adequately explains return type and format. It covers purpose, parameter defaults, usage guidance, and behavioral transparency. For a simple tool with two well-documented parameters, this is fully complete.
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. Description adds value by explaining default behavior for omitted packages and how to scope installation, which goes beyond the schema descriptions.
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 it returns the exact shell command for installing UploadKit packages for a given package manager. Verb and resource are specific, and the context distinguishes it from sibling tools which are about config, components, docs, etc.
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 advises using it before asking users to add dependencies, with guidance on detecting package manager. While it doesn't list when not to use, it provides strong contextual cues and is well-scoped for its purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_quickstartAInspect
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 | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavioral traits: 'Takes no parameters. Read-only, static content, idempotent.' This covers safety, idempotency, and return format, exceeding minimal expectations.
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?
Highly concise: two short paragraphs front-load the purpose and usage guidelines. Every sentence adds value with no 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 zero parameters, no output schema, and no annotations, the description fully covers all relevant aspects: content, return type, usage context, and behavioral properties. Nothing essential is missing.
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?
There are zero parameters, so baseline is 4. Description adds no parameter information because 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?
The description clearly states it returns the complete UploadKit quickstart walkthrough for Next.js, specifying the content covered. It distinguishes from sibling tools by noting alternative tools for specific steps.
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 provides when-to-use criteria: when the user is brand new and asks to get started. It also states when to prefer other tools (scaffold_route_handler, scaffold_provider, get_install_command) for specific step needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_componentsAInspect
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). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description fully bears the burden. It explicitly states 'Read-only, no side effects, idempotent' and describes the return format in detail, leaving no ambiguity 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?
The description is well-organized with distinct sections for functionality, when to use, and return format. It is clear but could be slightly more concise; however, it is not verbose.
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 only one optional parameter and no output schema, the description provides complete information: purpose, usage, behavior, and return format. No gaps remain.
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% with detailed enum values. The description adds minimal extra meaning beyond the schema, but it does clarify that omitting the parameter returns all components. Since schema is rich, a 4 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 the tool lists React upload components with specific fields (name, category, description, inspiration). It distinguishes itself from sibling tools like search_components and get_component by being a full listing.
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: 'before recommending or scaffolding any UploadKit component' and gives a concrete example of picking the right variant. Provides clear context for its usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_docsAInspect
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 | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavior: read-only, static at bundle time, idempotent, sorted alphabetically, and returns a specific JSON structure, covering all relevant 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?
All sentences are essential, front-loaded with purpose, usage, and return format, with 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?
For a zero-parameter tool with no output schema or annotations, the description completely covers what the tool does, when to use, and what to expect, leaving 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?
With zero parameters, schema coverage is 100%, and the description adds value beyond schema by clarifying return structure and behavior, fully compensating for lack of parameters.
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 enumerates all available UploadKit docs pages with specific fields (title, description, URL, path), distinguishing it from sibling tools like search_docs by specifying its use case for discovery rather than targeted searching.
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 provides when to use (to discover documentation before targeted searching) and when not to (prefer search_docs for concrete questions), giving clear usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scaffold_providerAInspect
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 | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the tool is read-only, deterministic, idempotent, and explains the return format. It does not cover potential side effects or auth, but those are likely not relevant given the tool's nature.
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 5 sentences, each adding value. It front-loads the core action, then provides when-to-use, consequences of not using, and return format. 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 0 parameters, no output schema, and no annotations, the description covers all necessary context: purpose, usage timing, behavioral traits, and return format. It is complete for the tool's simplicity.
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, and schema coverage is 100%. The description justifies the lack of parameters by stating the endpoint path is always /api/uploadkit. Baseline for 0 params is 4, and the description meets it.
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 snippet for wrapping Next.js root layout with UploadKitProvider. It specifies the verb 'return', the resource 'snippet', and distinguishes from sibling tools by noting it is used after scaffold_route_handler.
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: right after scaffold_route_handler' and warns that without it, UploadKit React components throw at runtime. This leaves no ambiguity about when to invoke the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scaffold_route_handlerAInspect
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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explicitly states the tool is read-only ('never touches the filesystem'), returns a markdown-formatted code block, and requires manual file creation. This effectively communicates behavioral traits beyond the schema.
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?
Well-structured into three paragraphs: purpose, usage, return details. First sentence immediately conveys the main action. Each sentence adds value without redundancy, though a bit longer than strictly necessary.
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 tool with 4 parameters, no output schema, and no annotations, the description covers purpose, usage, parameter semantics, return format, and behavioral constraints. It is complete enough for an AI agent to 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?
Schema coverage is 100% with detailed descriptions. The description adds further value by providing concrete examples for each parameter (e.g., routeName: 'media', maxFileSize: '4MB', allowedTypes: ['image/*']), clarifying defaults, and explaining error responses (413, 415).
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 a specific verb ('Generate'), resource ('complete file content for a Next.js App Router upload route handler'), and scope ('typed file router, handler export, correct path comment'). It distinguishes from sibling tools like scaffold_provider and get_component by being uniquely for route handler scaffolding.
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: 'when the user is setting up UploadKit server-side in a Next.js App Router project'. Clearly implies the tool is for generating code only, not for other tasks. While it doesn't list alternative tools, the sibling context makes the differentiation obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_componentsAInspect
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". |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description declares 'Read-only, idempotent, case-insensitive' and specifies return format, fully covering behavioral traits beyond schema.
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?
Compact three-part structure: purpose, usage guidance, return format. Every sentence adds value, no 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?
For a simple search tool with one parameter and no output schema, the description fully specifies behavior, matching logic, and return structure, making it complete for agent 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 covers 100% of parameters, but description adds substantial value by explaining the fields searched (name, category, description, inspiration) and providing multiple examples, going well beyond schema 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 explicitly states 'Fuzzy-search the UploadKit component catalog by any free-text keyword' with concrete examples, and distinguishes from list_components by noting '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?
Provides clear guidance on when to use ('user describes vibe but doesn't know name') and specifically advises to prefer this over list_components for discovery, directly addressing sibling tool differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_docsAInspect
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 |
|---|---|---|---|
| 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. | |
| 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". |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals it is read-only, uses a bundled index (no network call), and results reflect docs at build time. It explains ranking by keyword frequency and return sorting. No annotations are present, so the description fully carries the burden, and it does so thoroughly without 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 well-structured with clear sections: purpose, ranking, usage guidance, return format, and behavioral notes. Every sentence adds unique information without redundancy. It is appropriately sized for the tool's complexity.
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, the description details the return format (JSON with fields). It covers search scope, ranking, bundling, and usage context. It explains the tool's limitations (build time index) and provides comprehensive guidance for effective use, making it fully complete for its 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?
Schema coverage is 100% with both parameters described. The description adds significant value: for 'query' it explains ANDing and per-field weighting with examples; for 'limit' it gives usage guidance (3-5 for narrow queries, 15-20 for exploratory scans) beyond the schema's default and range. This enriches the semantic understanding.
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 'Full-text search across every UploadKit docs page' and specifies the scope (88+ pages, covering multiple sections). It distinguishes itself from sibling tools by indicating it handles questions not answered by 'component tools', providing a clear verb+resource+scope.
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: any question about UploadKit behaviour, configuration, or integration that the component tools do not answer', implying to use component tools for specific tasks. It lists concrete examples (middleware, webhooks, etc.), providing clear guidance on when to select this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!