Connects to Supabase as the backend database for storing and retrieving habit tracking data, including logging habits, retrieving daily status, streaks, and mission overview.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Zenith MCP Server log my cold shower habit for today"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A personal habit tracking MCP server built for an AuDHD + PDA brain.
Tracks the 6 daily non-negotiables of a 90-day mission — connected to Supabase. No UI. No friction. Just a tool your AI can call.
Tool | What it does |
| Log a habit as done today |
| Full dashboard of today's habits |
| Consecutive day streak for any habit |
| Full 90-day progress stats |
Related MCP server: notion-mcp
prayer_before_phone
cold_shower
box_breathing
pullup_gtg (multi-session, tracks reps)
a25_block
video_published
No negative habit tracking. Pink Elephant rule enforced.
# 1. Clone and install
git clone https://github.com/YOUR_USERNAME/zenith-mcp
cd zenith-mcp
uv sync
# 2. Add your credentials
cp .env.example .env
# Edit .env with your Supabase URL and secret key
# 3. Run the DB migration in Supabase SQL Editor
# (paste contents of setup_db.sql)
# 4. Run the server
uv run server.pyBuilt in public. AuDHD developer. Varna, Bulgaria.
Returns a full 90-day mission progress overview:
How many days have passed and remain
Which habits have the highest and lowest completion rates
Total pull-up GtG reps logged across the mission
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It clearly indicates a read-only operation via 'Returns' and details the exact computed metrics included. However, it does not explicitly state that the tool has no side effects or mention any prerequisites, which is acceptable for a simple getter but could be slightly more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and uses three concise bullet points to list key data points. Every sentence earns its place with no redundant fluff, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description fully communicates the tool's scope and value. It explains what the overview includes and contrasts implicitly with sibling tools, providing sufficient context for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has zero parameters, and the baseline for 0-param tools is 4. The description does not need to explain parameter syntax or meaning since there are none, and the schema coverage is trivially complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Returns a full 90-day mission progress overview' and enumerates specific content (days elapsed/remaining, habit completion rates, total GtG reps). This verb+resource phrasing distinguishes it from siblings like get_today_status and get_streak, which focus on narrower scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for mission-level progress reports rather than daily or streak-specific queries, but it does not explicitly state when to choose this over alternatives or provide exclusions. The context is inferable from the tool name and content list, but explicit guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the current consecutive-day streak for a specific habit.
| Name | Required | Description | Default |
|---|---|---|---|
| habit_name | Yes | The habit to check the streak for. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates a read-only operation via 'Returns' but does not disclose behavior for invalid habit names, missing logs, or timezone calculations. This is adequate for a simple getter but not rich in edge-case context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise, front-loaded sentence that states exactly what the tool does. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter fully documented in the schema and an output schema present. The description clearly identifies the purpose, making it sufficient for an agent to select and invoke correctly. No additional context is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the single parameter 'habit_name' fully described. The tool description adds no additional parameter semantics beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the current consecutive-day streak for a specific habit, using a specific verb ('Returns') and resource. It distinguishes this from sibling tools like log_habit, get_today_status, and get_mission_overview by focusing on the streak metric.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: use it when you need a habit's streak. However, there is no explicit guidance on when to prefer this over siblings, nor any exclusions or prerequisites. It is a simple, self-explanatory tool but lacks explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a full dashboard of which habits are done/not done today, today's pull-up GtG total reps, and mission day progress.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It is transparent about the today scope and the data returned, and 'Returns' implies a read-only operation. However, it does not disclose response format or potential error cases, though these may be covered by the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and resource ('Returns a full dashboard') and then enumerates the specific content. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, an existing output schema, and a simple read-only purpose, the description covers all necessary context. It names the three key data categories and the temporal scope, leaving no significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (vacuously). Per the rubric, a zero-parameter tool gets a baseline of 4. The description adds no parameter information because none exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: 'Returns a full dashboard' with specific components (habits done/not done, pull-up GtG reps, mission progress). This distinguishes it from siblings like log_habit (a write action) and get_streak (a single metric).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this versus alternatives, but the description implies it is the primary tool for a daily status overview. Lacks explicit exclusions or references to sibling tools, but the purpose is clear enough for an agent to infer typical usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark a habit as completed for today.
| Name | Required | Description | Default |
|---|---|---|---|
| habit_name | Yes | One of: prayer_before_phone, cold_shower, box_breathing, pullup_gtg, a25_block, video_published. | |
| pullup_reps | No | Only used when habit_name is 'pullup_gtg'. Log the reps for this GtG session (e.g. 3). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action but doesn't mention side effects like idempotency, overwriting previous logs, or the special behavior for pullup_gtg requiring rep counts. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler, achieving maximum efficiency. However, it omits important behavioral details that could be incorporated without much length, so it's concise but slightly under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This simple 2-param tool has no annotations and relies on the description for context. The description fails to address idempotency, validation errors, or the conditional nature of pullup_reps, rendering it incomplete for a safe mutation operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: both parameters have detailed descriptions, including enum-like values for habit_name and conditional use for pullup_reps. The tool description adds no semantic value beyond restating 'habit', so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Mark') and resource ('habit as completed for today'), making the tool's core function immediately clear. It also distinguishes itself from the sibling read-only tools (get_today_status, get_streak, get_mission_overview) which are all queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool vs alternatives, nor any context about habit validation, prerequisites, or when not to log. The sibling names imply read-only tools, but the description doesn't explicitly exclude or compare, leaving usage to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool serves a clearly distinct purpose: logging a completion, viewing today's dashboard, checking a specific habit's streak, and viewing overall mission progress. There is no overlap or ambiguity between them.
All tool names follow a consistent verb_noun pattern: log_habit, get_today_status, get_streak, get_mission_overview. The verbs are consistent ('log' and 'get'), and the nouns clearly describe the target.
With 4 tools, the set is concise and well-scoped for a habit-tracking mission server. Each tool covers a necessary interaction (log and three read views), and the count is within the ideal range.
The server covers core logging and status views, but lacks a way to list available habits or manage them (create/update/delete). An agent cannot discover valid habit names, which could cause failures when calling log_habit or get_streak.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for interacting with the Supabase platform
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Multi-tenant hosted MCP server for Oura Ring — 21 read-only tools, OAuth per user.
Official Todoist MCP server for AI assistants to manage tasks, projects, and workflows.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/antonatanasovalekseev-coder/zenith-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
