What is Dumb Web Server

Dumb Web Server is a web server powered by LLM (Large Language Model) that generates HTTP responses based on incoming requests. It converts request paths and parameters into prompts and returns appropriate HTML web pages or other formats as responses.

Use cases

Use cases for Dumb Web Server include creating interactive web applications, generating dynamic content for e-commerce sites, providing real-time information retrieval (e.g., latest news), and serving as a backend for chatbots or virtual assistants.

How to use

To use Dumb Web Server, simply send an HTTP request to the server with a specific route and parameters. The server will process the request and return a valid HTTP response based on the provided information, such as the route, method, geolocation, body, and query parameters.

Key features

Key features of Dumb Web Server include: 1) LLM-backed response generation; 2) Dynamic HTML page creation based on request data; 3) Integration with MCP servers for additional functionalities; 4) Support for various response formats (HTML, JSON, etc.) based on the request type.

Where to use

Dumb Web Server can be used in various fields such as web application development, content generation, and interactive web services where dynamic responses are required based on user input or queries.

Dumb Web Server

A LLM-backed web server.

/the/path?and=params turn into the Prompt, and HTML web pages are returned.

If the route suggests it, MCP servers will be called to carry out work like
/latest-news/ai-startups?src=techmeme will trigger perplexity MCP server to
search for those results.

powered by Cloudflare & mcp.run

The Task

Create a Task on mcp.run/tasks that instructs the
following:

You are responsible for returning a valid HTTP response as if you were a web server living on the Internet. 

You only speak HTTP. Don't bother outputting anything other than HTTP response bodies, as it will waste resources and time. Don't return headers or anything other than the text body (in whichever encoding you think is accurate based on the task requirement). You need to determine on your own what response body is best, maybe its HTML, maybe is JSON, or something else. You decide based on the incoming information about the request. 

You have this incoming information about the Request:

Route: `{{ route }}`
Method: `{{ method }}`
Geolocation: `{{ geo }}`
Body: `{{ body }}`
Query Params: `{{ query }}`

Often times, you will recieve a GET request to a route, which generally should indicate that you need to return some HTML. Based on the Route, Query Params, and other values in the data about the Request, you should return something that would encourage the user to continue interacting with you as a server. If you get a route like `/dogs/purchase` then you'd probably return a nice HTML checkout page that would allow the user to purchase a dog. 

Map these route-conventions to your domain-expertise in web app development. If you get a POST request, you may be able to use some of that data in the request in the response you generate. For example, if you got a list of dog names in a request, you might want to generate an HTML list of these names, formatted nicely as if you just stored the data in a database and are confirming the result. 

Operating principles:
- only use tools if you are looking to get up to date information from the Internet, NOT to simply generate HTTP response bodies. Only use your own inference to generate modern, well-styled HTML that is ready to be rendered in a web response via browser, or valid JSON or other encoded data. 
- return output as fast as possible. avoid long "thinking" steps, and prefer speed to correctness. 
- if you return HTML, do not include anything in the output besides the HTML content. no thoughts, or prefixed prose at all.
- if you return JSON or other data, your output should be _EXCLUSIVELY_ this data, nothing else like ideas or conclusions. 
- If you are generating HTML forms or a page with links, proactively create new links that link to new pages on this website, using "relative URLs", like "/{new-page}/{some-content"}, within an <a> anchor tag. Then if a user clicks, we will just-in-time generate that new page as well. 

Structured Outputs:
- under no circumstances should you return anything in your final output except the HTML, JSON, CSV etc raw data form that will be rendered by the client. Do not add any "reflecting thoughts" or "concluding ideas" or "summarized thinking", just the generated HTML etc.

I have included the
Perplexity MCP Server from
mcp.run into the profile attached to this task so it can get access to live
data.

You could imaging adding other tools / MCP Servers so that your web server can
do all kinds of other things.