Have something to say?

Tell us how we could make the product more useful to you.

In Progress

Add MCP (Model Context Protocol) server support for AI agent integration

Summary Add native MCP (Model Context Protocol) support so AI assistants (Claude, and other MCP-compatible agents) can interact with OpnForm directly — creating and managing forms, reading submissions, and updating fields — without going through screen automation or hand-rolled API glue. Motivation MCP is becoming the standard way AI agents connect to external tools (Anthropic, and a growing list of SaaS products — Linear, Notion, Zapier, etc. — already ship first-party MCP servers). Right now, using OpnForm from an AI agent workflow means either: Scripting against the REST API manually per integration, or Driving the web UI via browser automation Both are brittle and have to be rebuilt per agent/tool. A first-party MCP server would let any MCP-compatible client (Claude Code, Claude Desktop, etc.) manage OpnForm forms and data as a native capability, out of the box. Proposed solution Ship an MCP server (either bundled with OpnForm or as a companion package) exposing tools such as: list_forms / get_form — read form structure and settings create_form / update_form — build or modify a form's fields programmatically list_submissions / get_submission — read response data delete_submission (gated/confirmable, since it's destructive) get_form_analytics — view counts, submission counts, completion rate Given OpnForm already has a documented REST API, the MCP server could largely be a thin wrapper that maps these tools onto existing API endpoints — auth via the same API tokens users already generate today. Example use cases "Create a customer feedback form with these 5 questions" — done conversationally, no dashboard clicking. An AI assistant summarizing new form submissions each morning as part of a briefing. Bulk-editing form field labels/options across multiple forms via natural language. Alternatives considered Public REST API (already exists) — usable, but requires per-integration custom code rather than working automatically with any MCP client. Happy to help test against a reference implementation if that's useful.

Andrew about 17 hours ago

1

💡 Feature Request

Allow "simple" OIDC setups for self-hosted instances

Hello! Is it possible to change the OIDC setup to be “normal”, as in: No domain restrictions (anyone can login using OIDC) No implicit routing to OIDC providers This would go towards the more common implementation of OIDC sign in, where the security layer is the OIDC provider, and not the application (with domain routing). This would also imply a change in the login screen, because you’d need to have, like most apps do, two login methods side-by-side — email/password and OIDC providers. With the option to disable password login, if the instance admin only wants OIDC login available. I am willing to help with a PR for this, if the team is open to it! :) Thanks!

Filipe Silva Medeiros about 1 month ago

2

💡 Feature Request

SMTP OAuth Authentication Support for Microsoft 365

I would like to request support for SMTP authentication via OAuth for Microsoft 365 accounts. Microsoft is gradually deprecating basic SMTP authentication (username and password) to improve security and better protect accounts from misuse. As a result, many organizations are required to switch to OAuth-based authentication for sending emails. Currently, I do not see an option to configure OAuth authentication for SMTP. Adding support for OAuth would allow users to continue sending emails from their custom domains through Microsoft 365 while complying with Microsoft's modern authentication requirements. This feature would help ensure long-term compatibility with Microsoft 365 and provide a more secure authentication method for email delivery.

Wedl about 2 months ago

1

💡 Feature Request