Tasteck Integrates AI Dispatch Tools in One Day

A B2B SaaS for Japan's night-leisure industry claims a rapid AI integration, turning a two-week OAuth sprint into a single day. This required navigating 12 distinct technical traps.

A founder building tasteck, a B2B SaaS for Japan's night-leisure industry, claims to have completed a two-week OAuth integration sprint in a single day. This rapid deployment enabled ChatGPT Plus to call tasteck's dispatch tools live within two days of a design post, streamlining cast shift management for approximately 100 venues.

Tasteck's AI Integration Strategy

tasteck serves the Japanese night-leisure industry, managing dispatch and cast shifts. The founder reports 8 years of operational data and approximately 100 live venues, providing a rich dataset for AI interaction. The strategic goal was to make tasteck "MCP-ready," enabling AI models like ChatGPT to directly interact with its core functionalities for enhanced operational efficiency. This involved exposing specific business logic as callable tools. Three primary read tools were shipped for AI consumption: list_available_drivers to identify staff free for immediate dispatch, list_cast_shifts to retrieve the day's full roster, and list_assignable_casts. The latter is a joined resolution, combining roster data with stage-name sets and shop match criteria, ensuring accurate assignment recommendations. Beyond these core tools, a specialized resolveBusinessDate(naturalText, company) helper was developed. This function processes natural language date inputs such as "today" or "tomorrow" and intelligently adjusts them based on each tenant's configured business-day boundary (e.g., day flips at 04:00 or 05:00, specified by Company.changeDateTime). This bespoke tool addresses a critical operational nuance in the night-leisure sector.

The One-Day OAuth Sprint

The founder claims an estimated two-week sprint for B2 OAuth implementation was completed in a single day, attributing this accelerated timeline to meticulous reading of the specification prior to any coding. The technical backbone for this integration involved wiring the @modelcontextprotocol/sdk into a NestJS controller. This setup utilized Server-Sent Events (SSE) for transport, where each SSE connection corresponds to a unique McpServer instance. These instances are company-scoped, and a session_id Map is employed for routing incoming POST /messages to the correct session. The OAuth flow itself was broken down into seven distinct steps, each with a corresponding commit ID provided by the founder. These steps included establishing the Protected Resource Metadata endpoint (RFC 9728, d6f05ff6), implementing the /authorize endpoint with a consent screen and PKCE start (107edbcb), and developing the /token endpoint for PKCE verification and JWT issuance (ffd0468c). Further steps involved creating an OAuthAccessTokenGuard (supporting RS256 + HS256 fallback for companyId / staffId extraction, f2c9bed4), setting up Streamable HTTP transport (SSE → POST /sse/:companyId for JSON-RPC, 3a28d92f), adding an undefined fallback for resolveBusinessDate, and finally, a QA redeploy culminating in a live ChatGPT demonstration.

Navigating 12 Integration Traps

The founder reports encountering 12 distinct traps between the successful issuance of OAuth tokens and ChatGPT's actual invocation of tasteck's tools. These issues were systematically identified and resolved through diligent QA logging. One significant trap was a discovery path mismatch. ChatGPT expected the /.well-known/oauth-protected-resource endpoint at the server root, while tasteck had published it under a versioned path (/v1/api/staff/mcp/...). This required adjusting the endpoint location to meet the AI protocol's expectations. A transport mismatch also posed a challenge. ChatGPT anticipated Streamable HTTP, specifically a direct POST to /sse with JSON-RPC payloads. tasteck initially utilized a legacy SSEServerTransport, leading to 404 errors in QA logs when ChatGPT attempted to connect. A "cache illusion" proved particularly time-consuming. ChatGPT would cache the state "this connector has no tools" even after server-side fixes were deployed. This required a full disconnection and reconnection through the OAuth flow to clear the cached state, leading to initial misdiagnosis as a server bug. The "guard mismatch" was deemed "the big one." This issue stemmed from the difference between OAuth tokens, which are signed with the OAuth secret, and the existing StaffJwtGuard, designed to validate the staff-login JWT. This required careful handling of token validation logic to ensure both security and interoperability with the AI protocol.

What We'd Change

The tasteck team's success with a rapid AI integration sprint is notable, but the specific context of their niche (Japanese night-leisure) and existing operational data plays a significant role. The custom resolveBusinessDate helper, for instance, addresses a specific domain requirement for handling business-day boundaries that might not be universally applicable. Founders in broader markets or with less specific time-based operations may find less direct utility in this particular tool's design. The claim of completing a two-week OAuth sprint in one day, while impressive, likely reflects a founder's deep familiarity with their codebase and the specific protocol. Replicating this timeline without similar internal knowledge or a pre-existing, well-structured API would be challenging. Most teams would still require dedicated time for specification review, implementation, and testing, even with a clear playbook. The "12 distinct traps" highlight common pitfalls in API integration, particularly with new protocols. While the specific solutions are tied to tasteck's NestJS stack and the Model Context Protocol SDK, the types of issues (discovery, transport, caching, authentication guards) are recurring. Founders should anticipate these categories of problems rather than expecting a seamless, trap-free integration, regardless of the protocol. The emphasis on careful spec reading is a universal lesson.

The tasteck case demonstrates that integrating AI tools into niche SaaS products can yield rapid operational benefits, particularly when leveraging existing, well-structured data. The detailed account of technical challenges and their resolutions provides a granular view of the work involved. For founders in specialized verticals, this approach signals a viable path to enhance existing products with AI-driven efficiencies, provided they are prepared for the specific technical hurdles of protocol integration.

The investor read

This signal indicates a growing trend of niche SaaS products integrating directly with AI models to enhance operational efficiency, rather than relying solely on generic AI APIs. The ability to expose specific business logic (like list_available_drivers or resolveBusinessDate) to large language models creates new avenues for automation and user interaction within specialized verticals. While tasteck operates in a specific Japanese night-leisure market, the underlying pattern of leveraging AI for dispatch and resource management is applicable across many service-based industries. Investors should note the potential for AI to drive efficiency gains in markets previously considered too small or complex for broad AI application. The detailed technical challenges suggest that while the opportunity is real, successful integration requires significant engineering rigor, making companies with strong technical teams and well-defined APIs more attractive.

Pull quote: “The founder reports encountering 12 distinct traps between the successful issuance of OAuth tokens and ChatGPT's actual invocation of tasteck's tools.”