-
-
Actual Task Desk interface: review model offers and a scope-bound quote before simulated approval.
Inspiration
A task can sound simple while its purchase plan stays vague. “Summarize this report” does not specify the input size, answer ceiling, model, service line or approved cost. If a user edits that scope after seeing a quote, an old “yes” should not approve a different job. We built a review loop that makes those assumptions visible before approval.
What it does
Task Desk is an independent simulated Alexa+ web experience backed by working MCP tools. A user chooses or describes a task, enters explicit input and output token ceilings, and sets an expected-cost budget for that one task. The server compares model-and-service-line offers, explains rejected offers, and creates a short-lived quote for a selected offer.
Every quote binds the reviewed task, token ceilings, model and line, budget, price mode, request revision, catalogue snapshot and expiry. Editing a draft withdraws the pending quote. The server refuses changed or expired approvals and recalculates the estimate before recording a receipt. Repeating the same approval returns the original receipt rather than creating another one. The receipt can be exported as JSON.
The included directory contains 94 model/line offers with the original capture time, source and SHA-256 content identifier. Standard snapshot mode refuses a directory older than 24 hours. Explicit Historical snapshot replay remains free and reproducible without disguising recorded prices as current prices.
How we built it
The browser uses the official @modelcontextprotocol/sdk Client and StreamableHTTPClientTransport. The Node server uses the official McpServer and StreamableHTTPServerTransport and negotiates protocol 2025-11-25. Six tools manage the workspace, task review, quote withdrawal, inspection, quote creation and simulated confirmation. Structured Zod validation and exact decimal rational arithmetic keep the pricing inputs explicit. Input and output token costs are rounded up independently. Zero-valued prices are never approvable.
The application keeps workspace state on the server and writes it atomically to a local file. Receipts survive restart; unapproved quotes are withdrawn on restart or browser reload. No API key, model inference, payment method or AWS service is required to reproduce the demo.
Challenges and verification
A fractional-rate regression showed why rounding the unit rate first can understate an estimate. We replaced that approach with decimal rational arithmetic and added a failing-before, passing-after test. The business suite covers budget boundaries, token capacity, stale and changed quotes, catalogue changes, workspace isolation, persistence and idempotency. An independent official SDK client verifies the handshake, tool discovery and calls, real-time expiry, empty HTTP 202 notification handling, HTTP 405 GET, bad-Origin 403 and invalid-protocol 400 responses.
What existed and what changed
The Sumplus brand and the earlier Model Desk pricing/catalogue project existed before this sprint. We reused and adapted its MIT-licensed pricing approach, model-plus-line identity and capacity constraints. The procurement review interface, server-owned task revisions and expiring quotes, immediate withdrawal on edits, explicit simulated approval, duplicate-safe receipts, persistent workspaces, official MCP SDK transport and browser client, historical replay, acceptance tests and this demo are the new work. This is a substantial workflow and transport addition, not a claim that all underlying pricing work is new.
What this prototype does not claim
The Alexa+ interface is simulated. It is a structured deterministic workflow, not an LLM conversation, voice assistant or officially deployed Alexa skill. No purchase, real reservation, model execution or payment occurs. The budget limits an estimated token cost for the specified workload; it is not an enforced live spending cap or a fee-inclusive invoice. Catalogue fit does not prove response quality, model identity or actual availability. A production purchasing integration would need authenticated users, payment authorization, complete billing estimates and provider-enforced execution limits.
What is next
The next engineering step is an authenticated execution adapter that preserves this reviewed scope through provider execution and settlement, with actual usage and all billable fees reconciled to the approval. That adapter is outside this prototype.
