Skip to main content
Glama
diarmind

kanpla-mcp

by diarmind
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

kanpla-mcp

An unofficial read-only Model Context Protocol server that lets an agent log in to Kanpla under your account and read the canteen menu.

It wraps the internal frontend API that the app.kanpla.io web app itself uses: Firebase (Google Identity Toolkit) for auth, then a single load/frontend call for the offers. Your credentials stay inside the server's environment — the agent only ever sees tool results (menu items), never your e-mail, password, or Firebase key.

⚠️ Disclaimer. This talks to an undocumented internal API (/api/internal/…), not Kanpla's official partner API. It can break without notice if Kanpla changes their frontend, and it is not endorsed by Kanpla. Use at your own risk, for your own account only.

Features

  • 🔐 Credentials and Firebase key live in server env, never in the model's context.

  • ♻️ Token is cached and auto-refreshed (Firebase idTokens expire ~1h) — the agent never handles tokens.

  • 📅 Menu for today or any specific date, with allergens.

  • 🚫 Read-only by design. No ordering, no payments, no account mutations.

Related MCP server: MANIT ERP MCP Server

Requirements

  • Node.js ≥ 18 (uses global fetch)

  • A Kanpla account you can log in to with e-mail + password

  • Three account-specific values (see Getting your values)

Installation

Install from npm:

npm install -g @diarmind/kanpla-mcp
# or run without installing:
npx @diarmind/kanpla-mcp

(The installed command is kanpla-mcp.)

Or build from source (uses pnpm via Corepack and Vite):

git clone https://github.com/diarmind/kanpla-mcp.git
cd kanpla-mcp
corepack enable
pnpm install
pnpm build

Configuration

All configuration is via environment variables. Create a .env (loaded by the server on startup) or export them in your MCP client config.

Variable

Required

Default

Description

KANPLA_FIREBASE_API_KEY

Yes

—

Public Firebase client key (AIza…). See below.

KANPLA_EMAIL

Yes

—

Your Kanpla login e-mail.

KANPLA_PASSWORD

Yes

—

Your Kanpla password.

KANPLA_MODULE_ID

No*

—

Canteen/module id. Optional if you use list_modules to discover it first.

KANPLA_BASE

No

https://app.kanpla.io

Might differ for regional accounts.

KANPLA_LANGUAGE

No

en

Language code for menu text (e.g. en, da, nb).

* KANPLA_MODULE_ID is not required to start the server, but get_today_menu / get_menu_for_date need a module id — either from this variable or passed as a tool argument.

Getting your values

Open app.kanpla.io, launch browser DevTools → Network, and log in.

  • KANPLA_FIREBASE_API_KEY — find the request to identitytoolkit.googleapis.com/…signInWithPassword. The key is the AIza… string in its URL (?key=AIza…) or in the x-goog-api-key request header. It is a public client key, not a secret.

  • KANPLA_MODULE_ID — the key under offers in the load/frontend response, or run the list_modules tool once and copy the id.

Running

Standalone (stdio)

node dist/index.js

The server speaks MCP over stdio. It's meant to be launched by an MCP client, not used interactively.

With an MCP client (e.g. Claude Desktop)

Add to your client's MCP servers config:

{
  "mcpServers": {
    "kanpla": {
      "command": "node",
      "args": ["/absolute/path/to/kanpla-mcp/dist/index.js"],
      "env": {
        "KANPLA_FIREBASE_API_KEY": "AIza...",
        "KANPLA_EMAIL": "you@example.com",
        "KANPLA_PASSWORD": "your-password",
        "KANPLA_MODULE_ID": "your-module-id",
        "KANPLA_BASE": "https://app.kanpla.io",
        "KANPLA_LANGUAGE": "en"
      }
    }
  }
}

Keep this config file readable only by you — it contains your password.

Dev mode

pnpm dev     # tsx watch, reloads on change

MCP tools

All tools are read-only.

get_today_menu

Returns the available menu items for today.

Arguments

Name

Type

Required

Description

moduleId

string

No

Overrides KANPLA_MODULE_ID for this call.

Returns — array of:

{
  "name": "Chicken breast",
  "description": "Served with hummus, roast harissa potatoes & roasted vegetables",
  "allergens": ["sesame", "milk"],
  "category": "Main dish",
  "date": "2026-07-13"
}

category is the section the dish belongs to (e.g. Main dish, Soup, Drinks).

Empty array means no dishes that day (weekend / closed / wrong module).

get_menu_for_date

Menu for a specific day.

Arguments

Name

Type

Required

Description

date

string

Yes

ISO date, YYYY-MM-DD.

moduleId

string

No

Overrides KANPLA_MODULE_ID for this call.

Returns — same shape as get_today_menu.

list_modules

Lists the canteens/modules available to your account, so you can find your moduleId.

Arguments — none.

Returns — array of:

{ "moduleId": "abc123", "name": "HQ Canteen" }

How it works

1. Firebase login
   POST identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?key=<API_KEY>
   { email, password, returnSecureToken: true }  ->  idToken, localId

2. (on expiry) refresh
   POST securetoken.googleapis.com/v1/token?key=<API_KEY>
   grant_type=refresh_token  ->  new idToken

3. Load offers
   POST <BASE>/api/internal/load/frontend
   headers: authorization: Bearer <idToken>, kanpla-app-env: PROD,
            kanpla-auth-provider: GAuth, origin: <BASE>   # origin is required
   { userId: localId, url: "app", language }  ->  offers[moduleId].items + modules[]

4. For each item (a category) look at item.dates{<unixSeconds>} whose key falls in
   the target UTC day, keep entries with available !== false and a populated
   .menu, then expose { name, description, allergens, category, date } — where
   allergens are the true-valued top-level keys of menu.allergens.

Module display names come from the top-level modules[] list; offers is keyed by moduleId and carries no name. origin must be sent or the backend responds 500 {"message":"Invalid URL"}.

The idToken is cached in memory and refreshed automatically; nothing is persisted to disk.

Project layout

kanpla-mcp/
├─ src/
│  ├─ index.ts          # MCP server entry (stdio transport, tool registration)
│  ├─ kanpla.ts         # Kanpla client: login, token cache, load/frontend
│  ├─ auth.ts           # Firebase signInWithPassword + securetoken refresh
│  ├─ menu.ts           # date filtering, item -> menu mapping
│  └─ config.ts         # env parsing/validation (zod)
├─ dist/                # bundled output (pnpm build)
├─ package.json
├─ tsconfig.json
├─ vite.config.ts
└─ README.md

Scripts

Command

Description

pnpm build

Bundle to dist/ with Vite.

pnpm dev

Watch mode via tsx.

pnpm typecheck

Type-check with tsc --noEmit.

pnpm start

Run the built server (dist/index.js).

Security notes

  • Your password and Firebase key are read from env only; they are never returned by any tool and never enter the agent's context.

  • The Firebase API key is a public client key — safe to store, but treat the config file as sensitive because it also holds your password.

  • Restrict file permissions on any .env or client config: chmod 600.

Limitations

  • Depends on an undocumented internal endpoint; may break on Kanpla frontend changes.

  • Not affiliated with or supported by Kanpla ApS.

  • Read-only: ordering and payments are intentionally out of scope.

License

MIT

Available Tools

3 tools
get_menu_for_dateGet menu for a dateB

Returns the available Kanpla menu items for a specific date.

ParametersJSON Schema
NameRequiredDescriptionDefault
dateYesISO date, YYYY-MM-DD.
moduleIdNoCanteen/module id. Overrides KANPLA_MODULE_ID for this call.

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears full responsibility. It only states 'returns', indicating a read operation, but lacks details on side effects, authentication needs, or any other behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence with no wasted words, front-loading the core functionality.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple getter with 2 params and no output schema, the description is minimally adequate but lacks information about response format or edge cases (e.g., no menu for a date).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the schema; it does not elaborate on date format or moduleId usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (returns), resource (Kanpla menu items), and specificity (specific date). However, it does not differentiate from the sibling tool 'get_today_menu', which likely serves a similar purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives like 'get_today_menu' or 'list_modules'. The agent must infer usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_today_menuGet today's menuA

Returns the available Kanpla menu items for today.

ParametersJSON Schema
NameRequiredDescriptionDefault
moduleIdNoCanteen/module id. Overrides KANPLA_MODULE_ID for this call.

TDQS

A3.5/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description should disclose behavioral traits like data freshness, permissions, or side effects. It only states the basic function with no additional context about how the tool behaves (e.g., caching, rate limits, or availability). Minimal transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with no fluff, but could be more structured (e.g., 'Returns today's Kanpla menu items. Optionally specify moduleId.'). Still efficient and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one optional parameter and no output schema, the description is sufficiently complete. It conveys the core function and scope. However, mentioning that moduleId override is optional would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with a clear description for moduleId. The tool description does not add new parameter information beyond the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool returns available Kanpla menu items for today. The verb 'returns' and resource 'menu items' are specific, and the scope 'for today' distinguishes it from get_menu_for_date (other dates) and list_modules (module listing).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage for retrieving today's menu, but no explicit guidance on when to use this tool versus siblings (e.g., 'Use this for today, get_menu_for_date for other dates'). The description relies on naming conventions rather than providing explicit context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_modulesList modulesA

Lists the canteens/modules available to your account, so you can find your moduleId.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It states it lists available modules, suggesting a read-only operation. No side effects or constraints are mentioned, which is adequate for this simple list tool. Could provide more detail on authentication or empty results, but not required.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence that is succinct and informative. No unnecessary words, and the purpose is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters, no output schema, and simple purpose, the description is complete. It tells what the tool does and why you'd use it, fitting the context perfectly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 0 parameters with 100% coverage. The description adds no parameter info because none exist. This is appropriate, and the description implicitly confirms no inputs needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists canteens/modules to find your moduleId. The verb 'lists' and resource 'canteens/modules' are specific. It distinguishes from siblings like 'get_menu_for_date' by focusing on listing available modules rather than retrieving menus.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage: use this to get your moduleId before using other tools that require it. However, it does not explicitly state when not to use or mention alternatives, but given the simplicity, this is sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv0.1.0
    • First observedget_menu_for_date
    • First observedget_today_menu
    • First observedlist_modules
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.3/5.0

Scored across 3 tools

Disambiguation3/5

The tools get_menu_for_date and get_today_menu have overlapping purposes, as both return menu items. The descriptions distinguish them by date specificity, but an agent could still be confused about which to use. list_modules is distinct.

Naming Consistency4/5

Tool names follow a verb_noun pattern with snake_case (get_menu_for_date, get_today_menu, list_modules). The mix of 'get' and 'list' verbs is minor, and overall the naming is predictable.

Tool Count3/5

With only 3 tools, the server feels under-scoped for a menu system. While it covers basic retrieval, additional tools for date ranges or module-specific menus would justify the count.

Completeness2/5

The tool surface lacks critical operations beyond retrieval, such as searching, filtering by module, or updating menu items. An agent cannot perform common tasks like getting menus for a week, which leaves significant gaps.

Maintenance

ActivityStale
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers