Uploadkit

scaffold_route_handler

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.

Input Schema

TableJSON Schema

Name	Required	Description
`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.

TDQS

A4.7/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All Uploadkit tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness5/5

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.

Resources

Need Help?