Support for MCP discovery

[IanMayo]

Hi, I've had a few weeks working on a very similar capability to FuncToWeb :-)

My work has been to provide a packaging method which takes a folder of python functions, and creates a REST interface for each one. During the packaging, it also indexes them, so that a tools/list end-point can provide a list of tool names, descriptions, and expectations - with the intention that an LLM Supervisor can treat this as an MCP server, and choose the best tool for a task. Feel free to have a play here: https://toolvault-main.fly.dev/ui/

I'm pretty sure this could apply to FuncToWeb, particularly if the run applies a long array of functions. My packaging process is fairly expensive, so I pre-cache it all, but I'm FuncToWeb could do it on the fly.

I'm happy to share my thoughts / what I've learned so far.

[offerrall]

Hi @IanMayo! Thanks for sharing your work, toolvault looks really interesting!

You're absolutely right - func_to_web already creates REST endpoints internally for form submission (each function gets a POST endpoint), but what you're suggesting is much more useful: exposing those endpoints in a discoverable way.

Currently, the endpoints are just used for the web UI to communicate with the backend, but I really like your idea of having a /tools/list endpoint that returns metadata about all available functions (names, parameters, types, descriptions, etc.). This would make func_to_web useful not just for humans via the web interface, but also for LLMs/agents that need to discover and call functions programmatically.

I think the two approaches complement each other nicely:

• func_to_web: Human-friendly visual interface (forms, validation, file uploads)
• Your approach: Machine-readable API for LLM integration (MCP, discovery endpoints)

Right now I'm adding new features daily and have a couple of things on my plate, but I'll definitely keep this in mind for future development. Of course, you're more than welcome to implement it yourself or help out if you'd like - contributions are always appreciated!

[offerrall]

Hey @IanMayo!

I found some time to properly evaluate your suggestion and I've been testing out an implementation. Here's what I'm working on:

What I'm testing:

An automatic /tools/list endpoint that would be created when calling run(). It would leverage the existing analyze() function that already extracts parameter metadata, so it mostly reuses code that's already there.

Example response:

[{
  "name": "create_account",
  "displayName": "Create Account",
  "description": "Create account with special input types",
  "endpoint": "/submit",
  "uiPath": "/",
  "parameters": {
    "email": {
      "type": "str",
      "required": true,
      "optional": false,
      "constraints": {
        "pattern": "^[^@]+@[^@]+\\.[^@]+$"
      }
    },
    "favorite_color": {
      "type": "str",
      "required": false,
      "optional": false,
      "default": "#3b82f6",
      "constraints": {
        "pattern": "^#(?:[0-9a-fA-F]{3}){1,2}$"
      }
    },
    "secondary_color": {
      "type": "str",
      "required": false,
      "optional": true,
      "default": "#10b981",
      "constraints": {
        "pattern": "^#(?:[0-9a-fA-F]{3}){1,2}$"
      }
    },
    "tertiary_color": {
      "type": "str",
      "required": false,
      "optional": true,
      "constraints": {
        "pattern": "^#(?:[0-9a-fA-F]{3}){1,2}$"
      }
    }
  },
  "method": "POST"
}]

What it would include:

• Function names, descriptions (from docstrings)
• Parameter types, required/optional status
• Default values (properly serialized for date/time)
• Constraints (min/max, length, patterns from Pydantic Fields)
• Endpoint paths for execution

Execution flow:
An LLM supervisor would:

1. GET /tools/list to discover functions
2. POST /submit (or /{function_name}/submit for multiple functions) with multipart/form-data

The endpoints would use multipart/form-data since func_to_web supports file uploads natively.

Question:

Would this be sufficient for your MCP use case?

Before I finalize and merge it tomorrow, I want to make sure I'm not missing anything important:

• Should I include HTML input types in the schema ("inputType": "color", "inputType": "file", etc.)?
• Do you need example request payloads for each tool?
• Any specific MCP protocol requirements I should implement?

Would love to hear if this covers what you had in mind or if there's something crucial I should add before pushing it!

[IanMayo]

One convention for expressing parameter types is to use JSON schema. I also read that LLM supervisors benefit from seeing example calls. Then, if the parameters don't quite match the supervisor can have a go at converting it. Lastly, it's probably worth researching current MCP recommendations. I recall you can indicate if an end point represents a tool, a resource, or a service.

[IanMayo]

Hello @offerrall - I hope you've had success with your approach. I don't know if you are working in vs-code or not, but if you are then you should be able to register your FuncToweb URL as an MCP, and see how CoPilot gets on with handling tasks for you - handing off tasks to FuncToWeb when relevant. When I was playing with it CoPilot was quite effective at re-processing/translating the data it knew about into the form required by the MCP tool.

[offerrall]

Hey @IanMayo!
I've been focused on core features that I felt were more immediately necessary (dark mode, file handling improvements, etc.), and I have to be honest: I'm not very familiar with MCP yet. However, after reading your comments and doing some initial research, I can definitely see the value in making func-to-web LLM-friendly.
The /tools/list endpoint with proper JSON Schema formatting seems like a natural evolution of what func-to-web already does - it's just exposing the function metadata in a standardized way that agents can understand.
I'm planning to look into this more seriously in the coming weeks. If everything goes well, I'll work on implementing a proper MCP-compatible endpoint in an upcoming version. I want to make sure I understand the protocol properly before diving in, so I can do it right rather than rush something half-baked.
In the meantime, if you have any specific resources or documentation you found particularly helpful when implementing this in toolvault, I'd love to take a look. And of course, if you feel like experimenting with a prototype yourself, PRs are always welcome!
Thanks again for bringing this to my attention - it's definitely on my radar now.

[IanMayo]

In this week's Python Weekly I was introduced to FastMCP. It's an architecture for creating python MCPs. There appears to be a pretty large overlap with your work. It may be possible for FastMCP to host your funcs - and FuncToWeb becomes a UI wrapper around a FastMCP server - including existing FastMCP server instances.

If I look really, really hard into the horizon, I think I can just about see a buy-out of FuncToWeb ;-)