MCP Apps Starter Kit
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| render_budgetA | Render a visual budget breakdown with pie chart of spending categories, bar chart of budget vs actual, and surplus/deficit indicator. Pass categories as a JSON array of objects with name, budgeted, and actual fields. |
| render_comparisonA | Render a side-by-side comparison of products or options with pros, cons, ratings, and prices. Pass options as a JSON array. |
| render_trip_explorerA | Render an interactive destination comparison view where the user can explore 3-5 trip options side by side before committing to a detailed itinerary. Each destination MUST include: name, country, tagline, budget_estimate (low/high in the specified currency), distance_km (from source city), travel_options (object with mode keys like flight/train/drive/bus and duration string values e.g. {"flight":"2h 30m","train":"6h","drive":"8h"}), weather (object with temp_range string e.g. "22-32°C" and condition string e.g. "Sunny & humid"), best_months, highlights, travel_style tags, and image_emoji. The user can select up to 2 destinations to compare detailed itineraries side by side. Use this tool FIRST when a user asks about vacation/trip planning — let them compare destinations before calling render_trip for the detailed itinerary. |
| render_tripA | Render a day-by-day trip itinerary with time slots, locations, costs, and a budget tracker. The user can swap, remove, or comment on individual activities and send style preferences (e.g. 'make it more relaxed') back to Claude. Pass itinerary as a JSON array of day objects. Use the same currency as the trip explorer if the user came from there. |
| render_workoutA | Render an interactive workout plan with dark theme, summary metrics, expandable exercise cards with tips and video links, progress tracking, and history. Pass plan as a JSON array of week objects. IMPORTANT: Each exercise MUST include video_url with a real YouTube link to a proper form demonstration video. Also include estimated_calories, duration_minutes, and tips (array of form cue strings). |
| save_workout_logB | Save a completed workout session to the log file |
| get_workout_logA | Retrieve workout history from the log file |
| render_decision_matrixA | Render a weighted decision matrix comparing options across criteria with scores, heatmap coloring, and a best-pick recommendation. Pass options and criteria as JSON arrays. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Budget View | Interactive budget tracker with charts |
| Comparison View | Side-by-side product/option comparison |
| Trip Explorer View | Interactive destination comparison for trip planning |
| Trip Planner View | Day-by-day trip itinerary with budget |
| Workout Plan View | Weekly workout calendar with exercise details |
| Decision Matrix View | Weighted decision matrix with heatmap and rankings |
TDQS
Scored across 8 tools
Most tools target distinct domains (budget, comparison, trip, workout), but render_comparison and render_decision_matrix both compare options, and render_trip_explorer is also comparison-like. The detailed descriptions help clarify, but slight overlap exists.
All render tools follow the consistent verb_noun pattern (render_budget, render_trip, etc.), and the log tools use save_workout_log/get_workout_log. Naming is uniform, snake_case, and predictable.
With 8 tools, the count is well within the ideal range. Each tool appears purposeful, and there is no redundancy or bloat. The broad scope fits a 'starter kit' concept.
The set is a mix of render-only tools with no persistence except for workout logs (save/get). There are no update/delete operations for workout logs, and no data management for budget, comparisons, or trips. The domain is unclear, and lifecycle coverage is inconsistent.