Click on "Deploy 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., "@psyrotrack can you generate my monthly habit report?"
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.
Tagline: "PsyroTrack MCP - Notion ka Baap, Free for Lifetime"
PsyroTrack MCP is an advanced, privacy-first routine and habit tracking Model Context Protocol (MCP) Server created by Psyro8-t.
Your data belongs exclusively to YOU. No cloud, no databases, no shared repositories.
All tracker data is stored entirely on your own local machine inside your OS home directory:
~/.psyrotrack/data.json
Related MCP server: Expense Tracker MCP Server
Default Protocols: By default, you get Psyro8-t's legendary 10 protocols (Wake up 6am, 3hr code, etc.)
Customizable: Want your own routine? Just tell the AI to set up your custom protocols!
Stats & Trackers: Generate dynamic monthly reports and streak statistics natively inside Claude/Cursor.
You don't need to download any code. Just use the npx command to run it directly from GitHub!
Open your Claude desktop config file:
Mac: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Add the following to your config:
{
"mcpServers": {
"psyrotrack": {
"command": "npx",
"args": ["-y", "github:Psyro8-t/PsyroTrack-MCP"]
}
}
}Add a new protocol to track.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| time | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, placing the full burden on the description. It only states the action and target, not behavior on duplicate names, whether the protocol is persisted, or any side effects, which is inadequate for a mutation tool.
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 concise sentence with no wasted words, which is structurally clean. However, the brevity is so minimal that it contributes little beyond the tool name.
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 tool with no annotations and no output schema, the description is too sparse to fully support correct invocation. It omits context about duplicates, required and optional parameters, and expected behavior, leaving notable gaps for the 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?
Schema description coverage is 0%, and the description adds no meaning to the 'name' or especially 'time' parameters. The purpose statement does not compensate for the lack of parameter semantics, leaving the meaning of 'time' entirely unexplained.
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 action ('Add') and the resource ('protocol'), making the core purpose understandable. It differentiates from obvious opposites like remove_protocol but does not distinguish itself from set_protocols, leaving some ambiguity among siblings.
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 gives no guidance on when to choose add_protocol versus set_protocols, nor does it mention any preconditions or alternatives. A tool named set_protocols likely overlaps with adding, so this ambiguity is not addressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run this ON FIRST INSTALL. Ask user: 'Do you want to use default Psyro protocols or create your own?'. Use this tool to initialize the local tracker.
| Name | Required | Description | Default |
|---|---|---|---|
| useDefault | Yes | True to use Psyro8-t defaults | |
| customProtocols | No | List of custom protocols if useDefault is false |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears the full burden. It states the tool 'initializes the local tracker' but does not disclose side effects, state changes, permissions, idempotency, or return behavior. This is a significant gap for a mutation-like operation.
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?
Two sentences, front-loaded with the critical 'ON FIRST INSTALL' condition. Every word earns its place; no fluff or 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?
The description is adequate for a simple initialization call given the schema covers parameters, but it omits behavioral context such as what 'initialize' entails, whether it overwrites existing data, or what happens if already initialized. This leaves some uncertainty for the 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?
Schema description coverage is 100%, so both parameters are already documented. The tool description only paraphrases the choice between default and custom protocols without adding new semantic detail, meeting the baseline expectation for schema-rich coverage.
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's purpose: to initialize the local tracker, and explicitly conditions its use on 'ON FIRST INSTALL'. It distinguishes itself from siblings like set_protocols by being the setup step, though it does not name an alternative directly.
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?
Provides an explicit trigger condition ('Run this ON FIRST INSTALL') and a concrete instruction to ask the user about default vs custom protocols. This leaves no ambiguity about when and how to invoke the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a protocol by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosure. It simply says 'Remove' without stating whether the operation is permanent, whether it cascades to related data, or what it returns. For a destructive operation, this is a significant under-disclosure.
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 with no filler, front-loading the verb and resource. It is appropriately brief but sacrifices informational content for brevity.
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?
With a simple one-parameter delete operation, the core action is clear, but the description omits side effects, irreversibility, return value, and behavior on missing IDs. Given the destructive nature and lack of annotations, the tool definition is not fully complete for an agent to invoke confidently.
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 only parameter, id, is described only as 'by its ID,' which adds minimal meaning beyond the schema property name. It clarifies that the ID belongs to the protocol to remove, but does not specify the ID format, source, or error behavior if not found.
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 states a clear action ('Remove'), a resource ('protocol'), and the method ('by its ID'). It differentiates from sibling tools such as add_protocol and set_protocols, which add or replace rather than delete.
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 gives no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusion conditions. It is only an action statement, so the agent must infer that removal is appropriate when a protocol ID is available and cleanup is intended.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear all ticks and reset the tracker to factory settings.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | Yes |
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 states the action ('Clear all ticks and reset') but does not disclose that this is destructive, irreversible, or that it may affect user data or protocol settings. The required 'confirm' parameter implies a destructive operation, but the description does not explicitly warn about consequences.
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 concise sentence that is easy to parse and front-loads the main action. It is appropriately short, though it sacrifices important behavioral detail for brevity.
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 destructive reset tool with no annotations and no output schema, the description is incomplete. It does not explain the effect on related data (e.g., protocols, stats), the irreversibility, or the role of the 'confirm' parameter. An agent cannot fully assess the consequences of invoking this tool.
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 0%, and the description does not explain the 'confirm' parameter beyond the schema's boolean type. The description does not state that 'confirm' must be true to execute the reset, which is critical for safe invocation. The description adds no semantic value over the raw schema.
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 clear verb ('Clear all ticks and reset') and identifies the resource ('tracker'), making the tool's purpose understandable. It does not explicitly distinguish it from siblings like show_tracker or show_stats, but the destructive reset intent is evident.
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 provided on when to use this tool versus alternatives. The description does not mention that it is destructive, irreversible, or that it requires confirmation, nor does it reference any sibling tools. An agent is left to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replace all current protocols with a completely new list.
| Name | Required | Description | Default |
|---|---|---|---|
| protocols | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It does communicate the destructive overwrite semantics ('replace all current protocols'), which is the key behavioral trait. But it doesn't disclose side effects on protocol progress or tracking state, especially relevant given the sibling tick_protocol.
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?
A single front-loaded sentence with zero filler. Every word contributes to the meaning and the destructive scope is stated up front.
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?
Adequate for a simple one-parameter replacement operation, but with no annotations and no output schema it could disclose more: side effects on protocol progress/state, error behavior, or reversibility. The description covers the core intent but leaves operational consequences to inference.
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 0%, so the description must compensate for the undocumented protocols parameter. It adds the crucial meaning that the array is the complete replacement set, but it gives no semantics for the name or time fields beyond the schema's bare structural constraints.
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?
States a specific verb (replace), resource (protocols), and scope (all current ones). The phrase 'all current protocols' clearly distinguishes it from incremental siblings like add_protocol and remove_protocol without needing to open their schemas.
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 intended use case is implied: use this when you want a wholesale replacement rather than one-at-a-time edits via add_protocol/remove_protocol. However, no sibling alternatives are named and no when-not-to-use conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate and show streaks and completion percentages.
| Name | Required | Description | Default |
|---|---|---|---|
No 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 of behavioral disclosure. It says 'calculate and show', which suggests a read-only operation, but it does not explicitly state that there are no side effects, nor does it mention whether it requires certain preconditions or what happens if data is missing. Without this, the agent cannot predict the tool's behavior beyond the most obvious reading.
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, short sentence that front-loads the action and outputs. It is appropriately concise for a parameterless tool, though it could add a clause about scope or return values without becoming verbose. It earns a 4 because it is efficient but lacks some useful detail.
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 the tool has no output schema and no annotations, the description is the only source of context. It fails to explain what 'streaks' refer to (protocols? habits?), what the returned data looks like (percentages per what?), or how it relates to the sibling 'show_tracker'. An agent would likely need to inspect other tools or attempt calls to understand this tool's role.
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, so the schema is trivially complete (100% coverage). Per calibration, a 0-parameter tool gets a baseline of 4. The description does not need to add parameter semantics because there are none, and it does not attempt to invent any.
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 states a clear action ('calculate and show') and a specific output ('streaks and completion percentages'), so the agent knows what the tool does at a basic level. However, it does not differentiate itself from sibling 'show_tracker', which likely overlaps in purpose, so it misses the full 5.
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?
There is no guidance on when to use this tool versus alternatives like 'show_tracker' or 'reset_tracker'. The description implies it is for viewing streaks and percentages, but it does not mention prerequisites (e.g., initialized user, active protocols) or exclusions. This leaves the agent to guess when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the tracker progress for a specific month.
| Name | Required | Description | Default |
|---|---|---|---|
| month | Yes | YYYY-MM format |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. 'Show' implies a read-only action, but the description does not state return format, whether it depends on tick_protocol data, how progress is calculated, or whether any state is changed. This is a significant gap for a tool with no annotation safety hints.
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 with no wasted wordsament, and the core operation and scope are front-loaded. For a one-parameter getter, this is appropriately concise.
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 and the schema documents the only parameter, so calling it with a month string is straightforward. However, there is no output schema or annotations, and the description does not explain what 'progress' includes or what the response looks like, leaving ambiguity for an agent selecting and interpreting the result.
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 input schema already provides 100% coverage of the only parameter, including the 'YYYY-MM' format requirement. The description adds little beyond 'specific month', but with full schema coverage 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 ('Show') and identifies the resource ('tracker progress') with a clear scope ('for a specific month'). It is understandable on its own, though it does not explicitly distinguish itself from the sibling tool 'show_stats'.
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 provided about when to use this tool versus alternatives such as 'show_stats' or 'tick_protocol'. The description implies it should be used when monthly tracker progress is needed, but there are no exclusions, prerequisites, or explicit comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark a protocol as done (or toggle off) for a specific date (YYYY-MM-DD).
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | YYYY-MM-DD | |
| protocol_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that the action is a state change that can be toggled on/off, but it does not mention prerequisites (e.g., initialized user or existing protocol), idempotency, effects on stats, or return behavior.
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?
Single sentence, front-loaded with the action, and includes the date format in a compact phrase. No filler or repetition of structured schema content.
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 two-parameter toggle, the core operation is captured, but there is no return/output info and no guidance on prerequisites or failure cases. It is adequate but leaves gaps in what happens after the toggle.
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 only 50%; the description repeats the date format but lets protocol_id's meaning be inferred from the word 'protocol.' It does not explain that protocol_id should reference an existing protocol, nor does it define the expected format beyond generic string.
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 and resource ('Mark a protocol as done') and adds the 'toggle off' behavior plus the date scope. This is clearly distinct from siblings like add_protocol/set_protocols (setup) and show_tracker (read-only).
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?
There is no explicit guidance about when to use this tool versus alternatives such as add_protocol or set_protocols. The phrase 'Mark a protocol as done' implies the intended use for daily ticking, but no when-not-to-use conditions or alternative routing are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0add_protocolinit_userremove_protocolreset_trackerset_protocolsshow_statsshow_trackertick_protocolScored across 8 tools
Tools are mostly distinct: show_tracker and show_stats both display information but one is progress per month and the other is streaks/completion, which could be slightly confused. The protocol management tools (add/remove/set) and tick/reset are clearly separated.
Most tools follow a verb_noun pattern (show_tracker, show_stats, reset_tracker, add_protocol, remove_protocol, tick_protocol). init_user and set_protocols are also verb_noun, so the pattern is consistent, though init_user is more of a setup action than a resource operation.
8 tools is well-scoped for a personal tracking server: initialization, protocol management, ticking, and stats/reporting. Each tool serves a distinct function without redundancy.
The surface covers the core lifecycle: init, add/remove/replace protocols, tick, reset, and view progress/stats. A minor gap is the lack of an explicit way to view or edit a single protocol's details, but the set is otherwise complete for the domain.
N-of-1 health experiments in your AI assistant: Oura/RescueTime data, protocols, workouts.
Track, curate, and analyze data about your health, habits, and goals.
Persistent context for Claude. Your AI always knows your projects and next actions across sessions.
Opinionated sprint tracker. Read/update tickets, sprints, velocity from Claude/Cursor/Zed.
