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.
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.
Average 4.7/5 across 12 of 12 tools scored.
Each tool targets a distinct resource and action: docs (list/search/get), components (list/search/get), scaffolding (route handler/provider), install, quickstart, BYOS config, and image transform. Even the most similar pairs (list_docs vs search_docs vs get_doc) have clear boundaries between enumerating, searching, and fetching a specific page.
All tools follow a consistent verb_noun snake_case pattern: get_*, list_*, search_*, scaffold_*, plus transform_image. The verbs are semantically grouped (list = enumerate, search = fuzzy find, get = fetch specific, scaffold = generate code), making the naming predictable and scannable.
With 12 tools, the server is well-scoped. It covers the full array of UploadKit integration tasks—docs discovery, component exploration, setup scaffolding, install commands, and image transformations—without unnecessary duplication or bloat.
The tool surface is highly complete for its purpose: agents can discover and fetch docs, search and inspect components, generate all necessary setup code (route handler, provider, install, BYOS), and create transformed image URLs. The only possible gap is upload management, but that is outside the server's stated integration-guidance scope, so no dead ends exist.
get_byos_configAInspectGenerate 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 carries full burden and exceeds expectations. It explicitly states 'Read-only, deterministic. No network calls, no secrets exposed' and clarifies that credentials are server-side. This discloses safety and side-effect behavior thoroughly.
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 a lead definition, a 'When to use' section, and a 'Returns' section. It is front-loaded with the primary function, and every sentence adds value without unnecessary padding.
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 single-parameter tool with no output schema and no annotations, the description covers purpose, usage triggers, return format (plain text with three sections), and behavioral traits (read-only, deterministic, no network). This is fully sufficient for an agent to select and invoke 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?
The input schema already provides 100% coverage with rich descriptions for each enum value (including recommendations like 'r2' = Cloudflare R2, zero egress fees). The description adds no additional parameter semantics beyond referencing 'a specific storage provider', so the baseline 3 applies.
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') and resource ('Bring-Your-Own-Storage (BYOS) configuration for an UploadKit Next.js handler'), and enumerates the output types (env vars, handler code, setup notes). This clearly distinguishes it from sibling tools like get_doc or list_components.
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?
A dedicated 'When to use' section explicitly explains the intended scenario (user wants own bucket instead of managed R2) and lists typical triggers (compliance, existing infra, vendor lock-in). It implies when not to use (managed storage) but does not name alternative tools, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_componentAInspectFetch 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?
With no annotations provided, the description carries the full burden. It discloses read-only, idempotent behavior, the exact JSON return shape, and the fallback suggestion message for unmatched names. This goes beyond minimal expectations, though it could mention explicit side-effect absence.
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 tightly written with a logical flow: purpose, when-to-use, return format, and error behavior. Every sentence earns its place 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?
This is a simple single-parameter read-only tool with no output schema, and the description covers all necessary context: what it returns, how to use it, error handling, and safety. No significant information 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?
The schema already provides thorough parameter details (case-sensitive, PascalCase, examples), and the description adds contextual guidance on sourcing the name from list_components or search_components. This enhances the parameter's meaning 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 states the tool fetches full metadata and a copy-pasteable React usage example for one specific UploadKit component. It distinguishes from sibling listing/searching tools by specifying 'one specific' and referencing how to obtain the exact name.
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: once the exact component name is known from list_components or search_components and a ready-to-paste example is needed. This clearly differentiates when to use 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.
get_docAInspectFetch 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?
With no annotations, the description carries the full burden. It explicitly discloses read-only and idempotent behavior, the exact return format, and the not-found message. It doesn't cover potential errors or network behaviors, but provides strong transparency for the expected use case.
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: what it does, when to use, and what it returns. It is concise, front-loaded, and contains no filler.
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 having no output schema, the description fully explains the return format and the not-found behavior. It also covers usage context and alternatives, making it complete for a simple docs-fetching 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 description for 'path' is already very detailed (100% coverage) with examples and formatting rules. The tool description itself does not add new parameter semantics beyond restating 'by its path' and the context in which to obtain the path, so the baseline of 3 applies.
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 the full markdown content of a single UploadKit docs page by path, including formatting details. This distinguishes it from sibling tools like search_docs and list_docs, making the purpose unambiguous.
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 to use it after search_docs identifies a relevant page, and advises preferring search_docs first. It also mentions the not-found fallback to list_docs, providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_install_commandAInspectReturn 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the tool's safety profile: 'Read-only, idempotent, never modifies anything.' It also specifies the return format (a plain-text shell command as a single string), which is essential behavioral context 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?
The description is concise and well-structured: each paragraph serves a distinct purpose (what it does, when to use, what it returns). It is front-loaded with the main verb and resource, and 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?
The tool is simple (2 optional params, no output schema), and the description covers both the return value and the operational context. It explains when and how to use the parameters (e.g., detecting package manager from lockfile) and explicitly states the read-only behavior, making it complete for an 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 description coverage is 100% for both parameters, with detailed explanations, examples, and enums. The description itself adds little beyond the schema, only repeating the package manager concept and providing an example command. Baseline 3 is appropriate when the schema carries the parameter semantics.
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 ('Return') and resource ('exact shell command to install UploadKit packages'), clearly distinguishing it from siblings that fetch components or docs. It also includes a concrete example command, leaving no ambiguity about the tool's function.
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 the tool ('before asking the user to add dependencies') and even provides detection guidance for package managers. It does not explicitly mention when-not-to-use or alternatives, but given that sibling tools are unrelated, the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_quickstartAInspectReturn 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?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It explicitly states 'Read-only, static content, idempotent' and specifies the return type ('plain-text markdown document'), which covers the key behavioral aspects. However, it doesn't mention any authentication/network requirements, though for static content retrieval this may not be critical.
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?
Each sentence earns its place: purpose in first sentence, usage guidance in second, return type and safety in third. The description is well-structured with 'When to use' and 'Returns' labels, making it easy to scan and parse.
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 static content tool with no parameters and no output schema, the description is fully complete. It covers what it does, when to use it, alternatives, return format, and behavioral traits. 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?
The input schema has zero parameters, so the baseline is 4 per the rubric. The description adds clear confirmation with 'Takes no parameters,' which is sufficient for parameter semantics since there is nothing to explain.
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 UploadKit quickstart walkthrough for Next.js, specifying content components (install, API key env, route handler, provider, first component, optional BYOS). It also distinguishes itself from siblings by explicitly referencing alternative tools for more targeted use cases.
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 explicit when-to-use cues: 'user is brand new to UploadKit and asks how do I get started?' and explicitly names alternative tools (scaffold_route_handler, scaffold_provider, get_install_command) for when a specific step is known. This is the gold standard for usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_componentsAInspectList 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 provided, the description carries the full transparency burden. It explicitly states 'Read-only, no side effects, idempotent' and also describes the return JSON structure, covering behavior and impact thoroughly.
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 three sentences: purpose, when-to-use, and return/behavior. It is front-loaded with the main action, every sentence has a distinct role, and there is no fluff or 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?
Despite lacking an output schema, the description explicitly states the return format. For a simple one-parameter list operation, it covers purpose, use context, side-effect profile, and return structure—fully sufficient 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?
The input schema provides 100% coverage with a detailed enum description for the optional category parameter. The description adds little beyond the schema (only a passing example of 'dropzone' variants), so it neither enhances nor detracts from the schema-provided semantics.
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 opens with a specific verb and resource: 'List every React upload component shipped by @uploadkitdev/react with its name, category, one-line description, and design inspiration.' This clearly distinguishes it from siblings like get_component (single component) and search_components (search vs. full list).
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' clause: 'before recommending or scaffolding any UploadKit component, to confirm the exact name exists and to pick the right variant.' This provides clear usage context but does not explicitly name alternatives or exclusions (e.g., when to prefer search_components).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_docsAInspectEnumerate 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 are provided, so the description carries full transparency burden. It explicitly states the tool is read-only, static at bundle time, and idempotent. It also discloses the return format ('JSON { count, generatedAt, pages: [...] }') and sorting behavior ('sorted alphabetically by path').
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 compact and well-organized with labeled sections ('When to use', 'Returns'). Every sentence adds value, and there is no redundant information. It is appropriately sized for the tool's simplicity.
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 no-parameter, read-only listing tool, the description is complete. It explains the return structure, sorting, and the tool's role in the broader docs workflow. No output schema exists, but the description compensates by detailing the JSON response. The sibling context shows it is one of several docs tools, and this description positions it appropriately.
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 tool has zero parameters, so schema coverage is 100% and there is nothing to document. The baseline for 0 params is 4, and the description adds no parameter details because none exist. It still provides context about the output fields (title, description, URL, path) which ties to what the function returns.
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 docs pages with specific fields (title, description, URL, path). It uses a precise verb 'enumerate' and resource, and explicitly differentiates from search_docs by stating when to prefer it.
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 this tool ('to discover what documentation exists before targeted searching, or to orient yourself around the shape of the docs site') and names an alternative ('Prefer search_docs when you already have a concrete question'). This is model guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scaffold_providerAInspectReturn 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?
With no annotations, the description fully discloses behavior: read-only, deterministic, idempotent, and the exact return format (plain-text string with a fenced tsx code block). It also clarifies that no parameters are needed and the endpoint path is fixed, providing transparency about internal assumptions.
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 yet complete, structured into clear sections (purpose, when to use, return format). Every sentence adds useful information with no redundancy or filler.
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 no parameters and no output schema, the description provides all necessary context: what it does, when to use it, what it returns, and its safety profile. It is fully self-contained and leaves no significant 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?
The tool has zero parameters, so the baseline is 4, but the description adds meaningful context by explaining why no parameters are needed: 'the endpoint path is always /api/uploadkit since that is what scaffold_route_handler produces.' This goes beyond the empty 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 states it returns a snippet wrapping the Next.js root layout with <UploadKitProvider> for React components to talk to the upload route handler. This is specific and distinguishes it from scaffold_route_handler, which generates the route handler itself.
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 explains the consequence of not using it ('UploadKit React components throw at runtime'). This gives clear context and implicitly excludes use before the route handler exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scaffold_route_handlerAInspectGenerate 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?
With no annotations provided, the description fully bears the burden of behavioral disclosure. It clearly states the tool is 'Read-only — generates text, never touches the filesystem itself', describes the return format (markdown string with code fence), and sets the expectation that the agent must write the file to disk. This is comprehensive 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?
The description is compact and well-structured: purpose in the first sentence, usage trigger in the second, return format and expected action in the third, and a clear read-only caveat in the fourth. Every sentence earns its place 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?
Despite the absence of an output schema and annotations, the description covers all necessary context: what the tool produces, how it should be used, what the agent must do with the result, and the tool's non-destructive nature. For a file-generation tool, 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 description coverage is 100%, so the baseline is 3. The tool description itself does not add parameter-specific meaning; the rich examples and defaults (e.g., routeName key, maxFileSize units) are already in the input schema. No additional value is contributed by the description beyond what the schema already provides.
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 opens with a precise verb and resource: 'Generate the complete file content for a Next.js App Router upload route handler', and lists concrete features (typed file router, handler export, correct path comment). It clearly distinguishes from sibling tools like scaffold_provider by naming the exact target file and framework context.
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 gives an explicit 'When to use' clause: when setting up UploadKit server-side in a Next.js App Router project and needing the route.ts file. It also tells the agent the exact path to write to and clarifies that the tool itself is read-only, leaving the file creation to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_componentsAInspectFuzzy-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?
No annotations are provided, so the description takes on the responsibility. It discloses 'Read-only, idempotent, case-insensitive' and specifies the exact JSON return format, providing solid transparency. Minor omissions like pagination or result limits are acceptable for a search 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 moderately long but well-structured with clear sections (core function, when to use, return format). It front-loads the purpose and uses whitespace effectively. A few redundant phrases could be trimmed, but overall efficient.
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?
Considering the lack of annotations and output schema, the description provides comprehensive context: purpose, usage guidance, return structure, and safety profile. It fully equips an agent to decide when and how to invoke the tool, including distinguishing from siblings.
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 value by introducing the fuzzy-search concept, the 'design inspiration' interpretation, and examples like 'apple' and 'vercel' that go beyond the schema examples. This elevates it above baseline.
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 'Fuzzy-search the UploadKit component catalog by any free-text keyword' and enumerates the fields searched (name, category, description, inspiration). It distinguishes from sibling list_components by explicitly positioning it as discovery-focused.
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?
Contains an explicit 'When to use' section with concrete example user queries and an explicit instruction to prefer this over list_components when the goal is discovery rather than enumeration. This directly addresses tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_docsAInspectFull-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". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and discloses key behaviors: 'Read-only. Bundled index (no network call) — results reflect docs at build time.' It also explains ranking logic ('Ranks matches by keyword frequency') and the return format with sorted order, going beyond a basic read/write hint.
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 organized into clear sections: scope, when to use, and return format. Every sentence adds value—no fluff. Despite moderate length, it remains focused and front-loaded with the core purpose, making it easy for an agent to quickly assess relevance.
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 thoroughly explains the return JSON structure with field names and sorting, plus metadata fields like query, count, and indexGeneratedAt. It covers use cases, behavior, limitations (build-time index), and parameter semantics, making it self-sufficient for an 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%, but the description adds valuable usage guidance: for limit it gives default, range, and context-specific advice ('Use smaller values (3-5) when you already have a narrow query; use larger values (15-20) for exploratory scans'); for query it explains ANDed multi-word behavior and per-field weighting with concrete examples. This significantly enriches schema definitions.
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 'Full-text search across every UploadKit docs page (88+ pages)' with a specific verb and resource, covering all docs. It distinguishes itself from siblings like search_components and get_doc by clearly scoping to docs pages and listing covered categories (getting-started, SDK reference, 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 provides a 'When to use' section: 'any question about UploadKit behaviour, configuration, or integration that the component tools do not answer — middleware, onUploadComplete callbacks, REST API endpoints...' This gives clear usage context and implies alternatives (component tools) without naming them directly, covering exclusions effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
transform_imageAInspectGenerate a CDN-cached image variant for a file stored in UploadKit Cloud. Requires a paid plan, a live API key in the MCP process environment as UPLOADKIT_API_KEY, and an image key returned by UploadKit. BYOS files are not supported. Use signed delivery for private or temporary content and public delivery for stable URLs in websites, apps, srcset, CSS, or stored application data. Explicit formats consume 1 transformation unit; auto consumes 3 units.
When to use: after an image is uploaded and the user wants a resized, cropped, optimized, or converted delivery URL. The returned URL is safe to send to browsers; the API key remains server-side.
Returns: JSON { url, expiresAt, delivery, transform, usage }. Has the side effect of reserving monthly transformation units for a new unique variant.
| Name | Required | Description | Default |
|---|---|---|---|
| fit | No | scale-down | |
| key | Yes | Exact UploadKit Cloud storage key returned by upload or listFiles. Not a public CDN URL. | |
| width | No | Output width in pixels. Width or height is required. | |
| format | No | auto | |
| height | No | Output height in pixels. Width or height is required. | |
| quality | No | ||
| delivery | No | signed expires and suits private content; public is stable and suits permanent public assets. | signed |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description shoulders full responsibility for behavioral disclosure. It covers prerequisites (paid plan, API key), side effects (reserves transformation units), cost implications (explicit vs auto consuming different units), and safety (API key remains server-side). This exceeds typical 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?
The description is well-structured with clear sections: purpose, prerequisites, delivery guidance, 'When to use', and return details. Every sentence provides distinct value—no redundancy or filler. It manages to be comprehensive without being 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 no annotations and no output schema, the description covers all essential context: auth requirements, usage constraints, return format, side effects, and safety. It also clarifies the 'key' parameter is not a public URL. This is complete for a tool of this complexity.
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 57%, with key, width, height, and delivery already described. The description adds valuable semantics for delivery (signed vs public usage) and format (unit consumption), but does not elaborate on fit or quality beyond their enum values. The added context partially compensates for the missing schema descriptions, but not fully.
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's function: 'Generate a CDN-cached image variant for a file stored in UploadKit Cloud.' It uses a specific verb ('Generate') and resource ('image variant'), and distinguishes itself from sibling tools like get_byos_config or scaffold_provider by focusing on image transformation.
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 usage context: 'When to use: after an image is uploaded and the user wants a resized, cropped, optimized, or converted delivery URL.' It also mentions exclusions (BYOS files are not supported) and differentiates between signed and public delivery based on use case, giving clear guidance on when to choose each.
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.
No comments yet. Be the first to start the discussion!
