goalslot-mcp
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| goalslot_get_contextA | READ ONLY. Call this first, before any other GoalSlot tool, in every session. It returns the facts the other tools require and that you must not guess: the signed-in user, the plan limits and how much of each is already used, the category VALUE strings that create_goal and manage_schedule_block require, the labels, the timezone, today's date in that timezone, the current Monday-first week window, and any timer already running. Do not assume today's date from your own sense of time, and do not invent a category value. Both come from here. Cheap and side-effect free. Call it again after a long conversation rather than relying on a stale copy. |
| goalslot_list_goalsA | READ ONLY. Lists the user's goals with target hours, hours already logged, progress and deadline. This is the tool that answers "what am I working on" and "am I behind". loggedHours is accumulated by time entries, so it moves whenever log_time is called with a goalId. Returns ids you must reuse verbatim when calling create_task, log_time or manage_schedule_block. |
| goalslot_get_goalA | READ ONLY. Full detail for a single goal, optionally with the user's own written reflections on it. Use this when the conversation is about one specific goal. For "how are all my goals doing", call list_goals instead, which is one request rather than many. |
| goalslot_list_tasksA | READ ONLY. Lists tasks, optionally filtered by status, goal, schedule block or day of week. Statuses are BACKLOG, TODO, DOING, DONE. Results are capped by limit (default 50) so a large backlog cannot flood the conversation; the response says whether it was truncated. dayOfWeek here is Sunday-first (0 = Sunday), which is not the Monday-first ordering that weekly reports use. |
| goalslot_get_scheduleA | READ ONLY. Returns the user's weekly schedule template, grouped by day and sorted by start time. The GoalSlot schedule is a REPEATING WEEKLY TEMPLATE, not a calendar of dated events. A block on Tuesday 09:00-12:00 happens every Tuesday. There is no way to schedule something for one specific date. Times are wall-clock HH:mm with no date and no timezone. dayOfWeek is Sunday-first: 0 = Sunday through 6 = Saturday. Call this before proposing any new block, so you can see which windows are already taken. |
| goalslot_list_time_entriesA | READ ONLY. Returns the individual time entries the user logged over a window, with a total. This is the raw record of what was tracked. For aggregates, comparisons and per-goal rollups use get_report instead, which is one call rather than summing these yourself. Every duration is returned as durationMinutes (whole minutes, authoritative) and durationHours (a float for display only, never send it back). The response always echoes the resolved date range, so check it matches what the user meant before quoting numbers. |
| goalslot_get_reportA | READ ONLY. The single reporting tool. Pick a view; the tool routes to the right report and normalizes the answer. Views: "day_total" is minutes per day, the best default for "how did my week go". "summary" with groupBy goal or category is the per-goal rollup. "detailed" lists every entry grouped by day. "day_by_task" is per day broken down by task. "schedule" compares hours PLANNED in the weekly template against hours actually LOGGED, which is the only way to tell "I never allocated time" apart from "I allocated it and did not honour it". "goals_progress" and "dashboard" are account-wide snapshots that ignore the date range. "weekly" and "monthly" are convenience windows. The response always echoes the resolved date range. Quote that range to the user rather than saying "this week", and never state a number that did not come back from a tool. All durations are minutes. Percentages are already computed; do not recompute them. |
| goalslot_search_notesA | READ ONLY. Finds notes by a substring of their title or body, or fetches one note by id. Notes are a tree, so every result carries its full path such as "Work / Meetings / Standup". Bodies are stored as HTML and are converted to markdown here, then truncated to maxChars, so long notes come back readable rather than as a wall of tags. With no query this lists the user's notes without their bodies, which is the cheap way to see what exists before pulling one. This server cannot create, edit, delete or share notes. Say so rather than looking for another tool. |
| goalslot_get_journalA | READ ONLY. Returns the user's written journal and their daily check-ins over a window, merged by date. A journal entry is free-written prose plus optional mood and energy. A check-in is the structured version: mood, energy and focus each 1 to 5, plus short "what worked" and "what blocked me" notes. This is what answers "how did my week feel", as opposed to get_report which answers "where did my hours go". Read both when the user asks how a week went. Journal bodies are stored as HTML and converted to markdown here. Quote the user's own words rather than paraphrasing them. |
| goalslot_create_goalA | WRITES. Creates a new goal on the user's account. category must be a value string from get_context.categories[].value, not a display name. targetHours is the one field measured in HOURS; everything else in this server is minutes. Creating a goal counts against the plan limit reported by get_context. If the account is at its limit this returns PLAN_LIMIT, so check the limit before calling rather than after. Confirm the title, category and target with the user before calling. Do not invent goals from an offhand remark. |
| goalslot_update_goalA | WRITES. Updates fields on an existing goal, including its status. There is deliberately no way to set loggedHours here. Logged hours are accumulated from time entries; to change them, add or correct a time entry with log_time. There is no archived status. PAUSED is how the user shelves a goal without deleting it. Deleting a goal is not available as a tool at all; tell the user to run the CLI if they want one gone. Only send the fields that should change. |
| goalslot_create_taskA | WRITES. Creates a task, optionally attached to a goal and to a weekly schedule block. estimatedMinutes is in MINUTES. Creating a task does not log any time; completing it with update_task does. Prefer attaching a goalId when the task clearly serves one, because that is what makes reports and goal progress meaningful later. |
| goalslot_update_taskA | WRITES. One tool for the whole task lifecycle, selected by action. action "update" edits fields. action "complete" marks the task done AND creates a time entry for actualMinutes, which also increases the linked goal's logged hours; it counts against the per-day task limit. action "restore" reopens a completed task. actualMinutes is required for complete and is in whole MINUTES. Never guess it: ask the user how long the task actually took. |
| goalslot_log_timeA | WRITES. Records time the user already spent. This is the workhorse tool for catching up on untracked work. durationMinutes is in whole MINUTES: an hour and a half is 90. date is a calendar date in the user's timezone, taken from get_context.today, never guessed. When goalId is set this ALSO increases that goal's logged hours. That is usually what the user wants, but it means a wrong goalId quietly corrupts goal progress, so confirm the goal before logging. Never invent a duration. If the user did not say how long something took, ask. Restate the minutes back in hours when you confirm, so a units mistake is visible. Entries count against the per-day task limit on free plans. Use dryRun true to show a batch to the user before committing it. |
| goalslot_start_timerA | WRITES. Starts the shared GoalSlot timer for this account. The same timer the user sees in the web and mobile apps, not a private one. Only one timer can run at a time. If one is already running this returns TIMER_ALREADY_RUNNING with what it is tracking and how long it has been going. Do not pass takeOver to get past that on your own: takeOver DISCARDS the running session and its elapsed time is lost with no time entry written. Show the user what is running and let them choose to stop it or replace it. Attach goalId when the work belongs to a goal, so stopping the timer credits that goal. |
| goalslot_stop_timerA | WRITES. Stops the running timer and converts it into a time entry, or discards it. Stopping is atomic and credits the linked goal, so the goal's logged hours go up by the elapsed minutes. Duration is floored at 1 minute and capped at 12 hours: a session left open overnight writes 12 hours, not the real elapsed time, and the response says so via "capped". discard true writes nothing at all and the elapsed time is lost. Only use it when the user says the timer was started by mistake. Attribution fields sent here override whatever the timer was started with. |
| goalslot_manage_schedule_blockA | WRITES. Creates, updates or deletes one block in the weekly schedule template. The GoalSlot schedule is a REPEATING WEEKLY TEMPLATE, not a calendar of dated events. A block on Tuesday 09:00-12:00 happens every Tuesday. There is no way to schedule something for one specific date. Adding a block therefore changes every future week, not one date. Say that back to the user before you commit a plan. Overlapping an existing block is rejected with SCHEDULE_CONFLICT. On a conflict, re-read that day with get_schedule and shift your proposal. Never delete the incumbent block to make room without asking. Use dryRun true to validate a whole proposed week and show it to the user before writing anything. Blocks count against the plan limit in get_context, so stop one short of it rather than erroring into it. action "delete" removes a single block. There is no way to clear the whole schedule from this server, deliberately. |
| goalslot_write_journalA | WRITES. Saves the user's journal entry and daily check-in for one date. Both are upserts keyed by date. IMPORTANT: mode "replace" (the default) REPLACES that day's whole journal body. Use mode "append" to add to what is already there. If the day may already have content and the user did not ask you to overwrite it, append. content is markdown and is converted to the HTML the GoalSlot editor stores. Write in the user's voice, using their words, not a summary of them. focus, worked and blocked are part of the check-in, and the check-in requires mood, energy and focus together. Supplying only some of the three is rejected rather than guessed at. Never invent a mood, an energy level or a reflection the user did not express. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ZeeshanAdilButt/goalslot-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server