Why
Currently, the server relies on static environment variables for Kintone authentication. This ties the running process to a single Kintone environment.
I want to deploy this MCP server as a shared, stateless gateway (e.g., on AWS AgentCoreRuntime). To achieve this, the server needs to support Streamable HTTP for remote connectivity. Furthermore, to be truly useful in a shared environment, it must support dynamic authentication, allowing the client to specify which Kintone environment to access per session, rather than being hardcoded at startup.
What
I have two requests to enable a stateless architecture:
-
Streamable HTTP Support:
Please implement Streamable HTTP transport.
-
Dynamic Connection Switching:
Please allow Kintone credentials (Base URL, API Token, etc.) to be passed dynamically from the client, instead of relying solely on startup environment variables.
For example, accepting these values via HTTP Headers (e.g., X-Kintone-Base-Url, X-Kintone-Api-Token) or within the Initialization Options of the MCP protocol would be ideal. This would allow a single MCP server instance to route requests to different Kintone environments dynamically.
Why
Currently, the server relies on static environment variables for Kintone authentication. This ties the running process to a single Kintone environment.
I want to deploy this MCP server as a shared, stateless gateway (e.g., on AWS AgentCoreRuntime). To achieve this, the server needs to support Streamable HTTP for remote connectivity. Furthermore, to be truly useful in a shared environment, it must support dynamic authentication, allowing the client to specify which Kintone environment to access per session, rather than being hardcoded at startup.
What
I have two requests to enable a stateless architecture:
Streamable HTTP Support:
Please implement Streamable HTTP transport.
Dynamic Connection Switching:
Please allow Kintone credentials (Base URL, API Token, etc.) to be passed dynamically from the client, instead of relying solely on startup environment variables.
For example, accepting these values via HTTP Headers (e.g., X-Kintone-Base-Url, X-Kintone-Api-Token) or within the Initialization Options of the MCP protocol would be ideal. This would allow a single MCP server instance to route requests to different Kintone environments dynamically.