A
licenseA
qualityA
maintenanceEnables chatbots to interact with a global goals engine, allowing them to declare goals, manage branches, and evaluate outcomes through MCP tools.
12
1
MIT
GoalTrack
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., "@GoalTrackI drank 500ml of water, log it and check my streak"
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.
GoalTrack — Generic Daily Goal Tracker (MCP Server)
The problem it solves: most daily-goal tracking apps are built for one metric — a water app, a step counter, a screen-time limiter — even though the underlying pattern is identical: log amounts throughout the day, check them against a target, and track whether you're keeping a streak. GoalTrack lets an LLM (Claude, or any MCP client) manage any number of goals at once — water, steps, pages read, screen time, calories, whatever — and get timezone-correct progress and streaks for each.
What it does
Tool | Purpose |
| Create a goal (name, unit, target, direction, threshold, timezone) |
| Update any field on an existing goal |
| Soft-delete (default, keeps history) or hard-delete a goal |
| List all goals with today's progress inline |
| Log an amount against a goal |
| Fix a mislogged entry's amount |
| Remove a logged entry |
| Today's total vs target for one goal, with % complete |
| Daily totals + met/missed status over the last N days |
| Current streak + longest streak for a goal |
Plus a goaltrack://goal-templates resource (a small library of common goal
presets an LLM can suggest — Water, Steps, Screen Time, etc.) and a
daily_encouragement_prompt prompt template that asks the assistant to
write a short, warm nudge about today's progress.
Direction: at_least vs at_most
Not every goal wants "more" — screen time and calorie limits want you to
stay under a number. Every goal has a direction:
at_least— met iftoday_total >= target * (threshold_pct / 100)(e.g. water: hit 90%+ of 2500ml)at_most— met iftoday_total <= target * (1 + (100 - threshold_pct) / 100)(e.g. screen time: stay within 10% over a 120min cap when threshold_pct=90)
threshold_pct always means "how strict is this" — it just bends in the
direction that matches the goal.
Related MCP server: helm-personal-os
The interesting engineering bit
Two things had to be designed carefully, same spirit as SubTrack's calendar-arithmetic problem:
What counts as "today"? Every logged entry computes and stores a
local_datefrom the goal's own IANA timezone at log time (compute_local_date()), not server time. If a goal's timezone is changed later, past entries keep their originallocal_date— history is never silently rewritten.Streaks.
compute_streaks()walks backward day-by-day from yesterday (today is deliberately excluded — an in-progress day should never break a streak just because it isn't finished yet) until it hits a day that didn't meet the goal, for the current streak. Longest streak is found by scanning every day from the goal's first-ever entry forward and tracking the longest run of met days.
Why the tools are async def
Every tool here is async def, and all SQLite access goes through
aiosqlite instead of the stdlib sqlite3, for the same reason as the
reference project this was modeled after:
FastMCP thread-offloads plain
deftools automatically, so a sync version wouldn't literally freeze under light load.But
async def+ a blocking driver inside it is worse than staying sync — FastMCP does not thread-offloadasync deftools, so a blocking DB call would stall every other concurrent request on the event loop.So: go
async defand use a genuinely async driver all the way down. This composes cleanly if more awaitable I/O (HTTP calls, etc.) gets added later, and doesn't burn a worker thread per in-flight DB call.The one exception:
goal_templates.jsonis read with plain sync I/O — it's a few hundred bytes, read rarely, not worth anaiofilesdependency.
Project structure
goaltrack-mcp/
├── server.py # the whole server — module-level `mcp` object
├── client_test.py # quick manual smoke-test client
├── pyproject.toml # project metadata + deps (managed by uv)
├── uv.lock # locked, reproducible dependency versions
├── .python-version # pins the Python version uv uses
├── .gitignore
└── README.mdgoal_templates.json and goaltrack.db are not committed —
server.py creates them automatically on first run (init_templates() /
init_db()). If you want a fixed template list to survive redeploys,
remove goal_templates.json from .gitignore and commit your edited copy.
Run it locally (uv)
No manual venv step needed — uv run creates and syncs .venv from
uv.lock automatically the first time you use it.
uv run server.py
# Starting MCP server 'GoalTrack' with transport 'http' on http://0.0.0.0:8000/mcpTest it with the included client:
uv run python client_test.pyIf you want to test with a stdio-based client (e.g. wiring this into
Claude Desktop for local use), run it via the FastMCP CLI, which overrides
the transport regardless of what's in __main__:
uv run fastmcp run server.py:mcp --transport stdioAdding or updating dependencies
Don't hand-edit pyproject.toml's dependency list — let uv manage it:
uv add some-package
uv add some-package --upgrade
uv lock --upgradeDeploy to FastMCP Cloud
Push this folder to a GitHub repo — commit
pyproject.tomlanduv.lock(don't commit.venv/).Sign in at fastmcp.cloud with GitHub and create a new project from the repo.
Set the entrypoint to
server.py:mcp.Deploy. You'll get a URL like
https://<project>.fastmcp.app/mcpthat any MCP client — including Claude, via a custom connector — can call.
A note on storage
This uses SQLite on local disk, which is not guaranteed to survive a
redeploy on most managed platforms. Once the tool logic feels solid, a good
next exercise is swapping sqlite3/aiosqlite for a hosted database
(Turso/libSQL, Postgres via asyncpg, Supabase) via os.getenv("DATABASE_URL").
Ideas to extend it
Add a
notify_if_at_risktool that checks all active goals late in the day and flags ones that are behind, usingdaily_encouragement_prompt(or a new nudge prompt) to draft the message.Add a
notescolumn onentriesfor context per log (e.g. "gym day").Add authentication (FastMCP supports bearer-token auth) and a
user_idcolumn once you're ready to make this a private, multi-user server.Add a
weekly_summarytool that aggregateshistory()output across all active goals into one digest.
Available Tools
10 toolsadd_goalAdd GoalC
Create a new daily goal to track.
direction: 'at_least' (hit at least the target, e.g. water/steps) or 'at_most' (stay at or under the target, e.g. screen time). threshold_pct: how strict 'met' is. For at_least, % of target required. For at_most, 100 = no slack, lower = more allowed slack. timezone_name: IANA tz string, e.g. 'Asia/Karachi', 'America/New_York'.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| unit | Yes | ||
| direction | No | at_least | |
| target_amount | Yes | ||
| threshold_pct | No | ||
| timezone_name | No | UTC |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. It explains parameter semantics but discloses nothing about behavior: no auth/permission requirements, no duplicate-handling or uniqueness rules, no reversibility or error behavior 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose leads, followed by tightly scoped parameter explanations with no filler sentences. The multi-line parameter listing is slightly unconventional in body text but each line earns its place.
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?
The output schema covers return values, so that need not be explained. However, for a 6-parameter creation tool with no annotations and no schema descriptions, the definition leaves required-parameter semantics and all behavioral context (duplicates, permissions, defaults interaction) unaddressed.
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?
With 0% schema description coverage, the description must compensate. It gives genuinely useful semantics for the ambiguous parameters (direction values, threshold_pct direction-dependent meaning, IANA timezone examples), but leaves the three required parameters name, unit, and target_amount completely undefined — notably 'unit' has no format or example.
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?
States a specific verb and resource ('Create a new daily goal to track') that separates it from edit_goal, delete_goal, and list_goals by the add/edit/delete/list verb distinction. It does not explicitly name a sibling or scope, but an agent can identify the operation without opening the schema.
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 when-to-use context, prerequisites, or alternatives are given. The description never says when to add a new goal versus editing an existing one, nor what happens if a goal with the same name already exists. Usage is only implied by the verb 'Create'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_entryDelete EntryC
Remove a logged entry entirely.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| entry_id | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.6/5.0
Behavior2/5
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 for a destructive operation. 'Entirely' hints at irreversibility, but it does not state whether the deletion is permanent, what happens to associated data (e.g., progress or streaks), or whether specific permissions are required. Critical safety context is missing.
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?
The description is a single, front-loaded sentence with no wasted words. It is appropriately brief for a one-parameter tool, though its brevity edges into under-specification rather than pure conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a destructive tool with no annotations, a one-parameter schema at 0% description coverage, and no usage guidance, the description is incomplete. While an output schema exists (so return values need not be explained), the description omits critical context like irreversibility and what 'entry_id' refers to.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema only says 'entry_id' is an integer with no explanation. The description does not mention the parameter at all, adding no meaning beyond the schema. With low coverage, the description should compensate but fails to do so.
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 states a specific verb ('Remove') and resource ('a logged entry'), and the adverb 'entirely' implies a hard delete as opposed to an edit. It distinguishes itself from edit_entry and log_entry by the removal action. However, it does not explicitly name or differentiate from sibling tools like delete_goal.
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?
There is no guidance on when to use this tool versus alternatives such as edit_entry or delete_goal. No conditions, prerequisites, or exclusions are provided. Usage is only implied by the verb 'Remove'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_goalDelete GoalA
Remove a goal. By default soft-deletes (active=0, history kept). Pass hard_delete=True to permanently remove the goal AND its entries.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| goal_id | Yes | ||
| hard_delete | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.9/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the default mutation is soft (active=0, history kept) and that hard_delete destroys both the goal and its entries. It omits permission requirements, reversibility of the soft delete, and any rate/confirmation behavior.
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?
Two sentences, zero waste, with the default behavior front-loaded ahead of the optional override. Every clause earns its place.
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?
An output schema exists so return values need not be described, and the destructive/soft-delete semantics are covered. For a mutation tool with no annotations, it is nearly complete, missing only permission/irreversibility caveats.
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?
Schema description coverage is 0%, so the description must compensate, and it does: hard_delete is explained with its default (false) and divergent effects, including the cascading entry deletion. goal_id is left self-evident by name/type.
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?
States a specific verb+resource ('Remove a goal') and immediately qualifies the scope with soft vs hard deletion. It does not, however, explicitly distinguish itself from the similarly named sibling delete_entry, leaving slight ambiguity about which resource is targeted.
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?
It implicitly tells the agent when to reach for hard_delete=True ('to permanently remove the goal AND its entries'), but gives no guidance on when to prefer soft delete over hard delete, nor any prerequisites or alternatives versus sibling delete tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
edit_entryEdit EntryC
Fix a mislogged entry's amount.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | ||
| entry_id | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.6/5.0
Behavior2/5
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 implies a mutation (fixing an amount) but does not disclose required permissions, reversibility, whether it overwrites the existing amount, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is front-loaded and free of fluff, but it is too terse for a two-parameter mutation tool with no annotations or schema descriptions. It is concise but under-specified, so the structure is fine but the size is inadequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, 0% schema coverage, and only a one-sentence description, critical context is missing: what happens on success, error cases, permissions, and parameter details. The output schema exists, so return values need not be described, but the description does not provide enough to use the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for both parameters. The description references 'amount' as the field to fix, implying it is the new value, but says nothing about entry_id or the format/constraints for either parameter. It partially compensates for amount but leaves entry_id completely undocumented.
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 states a specific action (fix/edit) and target (entry's amount), distinguishing it from siblings like log_entry and delete_entry by focusing on correcting an existing amount. It does not explicitly name alternatives, so it falls short of a 5.
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?
It implies usage when an entry's amount is mislogged, but provides no explicit when-to-use, prerequisites, or alternatives (e.g., delete_entry vs edit_entry). There is no guidance on how to choose between this and other entry tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
edit_goalEdit GoalB
Update any field on an existing goal. Only provided fields change.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| unit | No | ||
| goal_id | Yes | ||
| direction | No | ||
| target_amount | No | ||
| threshold_pct | No | ||
| timezone_name | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
B3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose one genuinely non-obvious trait: 'Only provided fields change' (PATCH semantics, unset fields are not cleared or nulled). That matters for an agent that might otherwise fear data loss. It says nothing about permissions, validation behavior on invalid direction/unit values, or reversibility, so the disclosure is real but incomplete.
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?
Two short sentences, zero filler, with the core action and its partial-update semantics front-loaded. Ideal density for the space available.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, but for a mutation tool with zero annotation coverage and 0% parameter documentation the description is far too thin. The absence of an enum on direction and the untyped semantics of target_amount/threshold_pct are exactly the gaps an agent cannot resolve from structured data alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 7 parameters, so the description must compensate and largely does not. 'Any field' gestures at a field set but names none of the six domain-specific fields (direction, target_amount, threshold_pct, timezone_name, unit, name), leaving their meaning, formats, and interdependencies (e.g., direction's allowed values, since the schema declares a bare string with no enum) undocumented anywhere.
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?
States a specific verb and resource ('Update any field on an existing goal'), which is clearly distinct from add_goal and delete_goal by its mutation scope. However, it never explicitly contrasts itself with the closest sibling, edit_entry, or acknowledges that it operates only on goals, not entries.
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 when-to-use guidance, prerequisites, or named alternatives appear. The phrase 'existing goal' weakly implies the goal must already exist and directs creation elsewhere, but nothing tells the agent when to prefer this over edit_entry or how to obtain a valid goal_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_progressGet ProgressB
Today's total vs target for one goal, with % complete.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| goal_id | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
B3.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only partly delivers: it discloses that the result is scoped to today and consists of total vs target plus a percentage. It does not state that this is a read-only operation or describe any failure behavior for an invalid goal_id.
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?
One short sentence, front-loaded with scope and result content, with no filler. Nothing needs trimming.
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?
The output schema means return values need not be explained, and the description covers what is measured and the time scope. However, ambiguity remains about what 'today' means relative to a timezone and what happens for a missing or unauthorized goal.
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 coverage is 0% and the single goal_id parameter is undocumented in the schema. The phrase 'for one goal' implies the parameter selects a single goal, which is minimal but the right scoping cue; no format or validity detail is added.
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?
States a specific resource and scope: today's total vs target for a single goal, plus % complete. It is distinguishable from streak_status and history, though it never names those siblings explicitly to reinforce the contrast.
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 indication of when to use this over streak_status or history, and no prerequisites or exclusions stated. The agent must infer the choice from the tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
historyHistoryB
Daily totals and met/not-met status for a goal over the last N days (including today, which is always shown as in-progress rather than met/failed).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| goal_id | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
B3.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden, and it does disclose one genuinely non-obvious behavior: today is always returned as in-progress rather than met/failed. It says nothing about read-only safety, ordering of the returned days, or limits on N — gaps that remain uncovered by any structured field.
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?
A single sentence, front-loaded with the returned data, with the parenthetical reserved for the one edge case that matters. Nothing is wasted, though the leading noun phrase asks the reader to infer that this is a read operation.
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?
An output schema exists, so return-shape explanation is rightly absent, and the description covers scope plus the today edge case. Still missing for a parameterized reporting tool: the default window length, any cap on 'days', and how it differs from get_progress and streak_status.
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 0% for both parameters, so the description must compensate. It clarifies that 'days' is the lookback window and that 'goal_id' scopes the report to a single goal, but it omits the default of 7 and any bounds or type expectations that the schema also leaves unstated.
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 names a specific resource and scope — daily totals plus met/not-met status for one goal over N days — which is concrete and distinguishable in kind from logging tools. It does not, however, explicitly contrast itself with the closest siblings get_progress and streak_status, so the agent must infer the boundary.
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?
Usage is only implied by 'over the last N days'; there is no statement of when to call this instead of get_progress or streak_status, and no prerequisites or exclusions. The agent is left to guess which of the three reporting tools answers a given question.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_goalsList GoalsB
List goals with today's progress inline for each.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| include_inactive | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
B3.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose one genuine behavioral trait — today's progress is embedded per goal rather than requiring a separate call — but says nothing about whether the operation is read-only, how inactive goals are handled, or result volume/ordering.
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, front-loaded sentence with no filler. The most important distinguishing detail (inline progress) is stated immediately.
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?
An output schema exists, so return structure needn't be explained. However, for a listing tool with one undocumented filter parameter, the omission of include_inactive semantics leaves a real gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description never mentions the sole parameter, 'include_inactive'. The agent gets no guidance on what toggling it returns, so the description fails to compensate for the schema gap.
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?
States a specific verb and resource ('List goals') plus a meaningful qualifier — progress for today is returned inline with each goal. That inline-progress detail implicitly distinguishes it from siblings like get_progress and history, though no sibling is named.
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?
There is no statement of when to call this versus get_progress, history, or streak_status, and no prerequisites or exclusions. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
log_entryLog EntryB
Log an amount against a goal. logged_at is an ISO-8601 UTC datetime string (e.g. '2026-09-11T14:30:00Z'); defaults to now if omitted.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | ||
| goal_id | Yes | ||
| logged_at | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
B3.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it usefully discloses that an omitted logged_at defaults to now. However, it says nothing about validation (must the goal exist? can amount be negative?), permissions, idempotency, or error behavior 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler, with the core action front-loaded and the parameter detail following. Every clause earns its place.
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?
An output schema exists so return values needn't be explained, but for a 3-parameter mutation tool with no annotations and 0% schema coverage, the description is thin on preconditions and effects. It is usable but leaves real gaps.
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 0%, so the description must compensate. It does well for logged_at, giving the format, a concrete example, and omit-default behavior, but goal_id and amount are left with no semantics beyond their obvious names.
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 states a specific verb+resource ('Log an amount against a goal'), so an agent knows this records a progress entry rather than creating or editing a goal. It does not distinguish itself explicitly from edit_entry or delete_entry, which are the closest siblings.
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?
There is no when-to-use guidance and no alternatives named. An agent must infer that log_entry is for creating new entries while edit_entry/delete_entry handle existing ones; the description never says so.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
streak_statusStreak StatusB
Current and longest streak for a goal (streaks measured in days met).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| goal_id | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
B3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral load; 'status' implies a read, and the parenthetical clarifies the measurement unit (days met), which helps interpret the result. It still omits failure behavior (e.g., missing goal) or any permission/pagination context.
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?
A single short sentence that front-loads what the tool returns. Efficient, though the parenthetical definition could be folded in slightly more cleanly.
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?
An output schema exists, so return values need not be described. However, for a tool sitting among get_progress, history, and list_goals, the definition gives no routing signal about when this is the right one to call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter goal_id has 0% schema description coverage, and the description only obliquely refers to 'a goal'. It does not clarify whether the id is an internal integer reference, how to obtain it, or what happens with an invalid id.
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?
Names a specific resource (streak) and its scope (current and longest) for a goal, which is clear enough to act on. It does not explicitly distinguish itself from siblings like get_progress or history, so it falls short of 5.
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 when-to-use guidance and no mention of alternatives such as get_progress or history. The agent must infer the context entirely from the name.
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.
10 tool updates
v0.1.0- First observed
add_goal - First observed
delete_entry - First observed
delete_goal - First observed
edit_entry - First observed
edit_goal - First observed
get_progress - First observed
history - First observed
list_goals - First observed
log_entry - First observed
streak_status
TDQS
A3.5/5.0
Scored across 10 tools
Disambiguation5/5
Each tool targets a clearly distinct operation: goal CRUD, entry logging/editing/deleting, and progress/history/streak retrieval. Although list_goals includes today's progress inline, it clearly differs in scope from get_progress, which focuses on a single goal. No two tools appear interchangeable.
Naming Consistency4/5
All names use snake_case consistently, and most follow a verb_noun pattern (add_goal, edit_goal, log_entry, get_progress). Minor deviation: history and streak_status are noun-only, but they remain readable and unambiguous.
Tool Count5/5
With 10 tools, the set is well-scoped for a goal-tracking server. Each tool covers a necessary operation in the goal/entry lifecycle, and there is no redundant or filler tool.
Completeness5/5
The surface covers full CRUD for both goals and entries, plus derived analytics like progress, history, and streaks. No obvious gaps remain for the stated daily-goal tracking purpose.
Maintenance
ActivityMaintained
ResponsivenessNo issues
Related MCP Connectors
Durable, user-controlled goals and governed plans for AI agents.
- ManiloOAuthapp.manilo
Log, query, and edit expenses, budgets, and accounts in Manilo from any MCP-compatible AI assistant.
- mcpOAuthnet.todoist
Official Todoist MCP server for AI assistants to manage tasks, projects, and workflows.
Read and edit GA4, Search Console and Google Tag Manager from any MCP client. 29 tools.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceProvides MCP tools to read and update a local-first personal OS for goals, tasks, habits, food, workouts, and check-ins. Enables assistants to manage daily life data and interact with an evidence-grounded AI coach.MIT
- AlicenseNot gradedqualityBmaintenanceEnables authenticated MCP clients to manage projects, tasks, habits, and daily capacity through tool calls.7 npmISC
- AlicenseAqualityCmaintenanceEnables AI assistants to manage goals, tasks, weekly schedules, time tracking, reports, notes, and journal entries on a GoalSlot account through MCP tools.18MIT