# AimYear (remote · mcp.aimyear.com)

Accountability partner in your agent: one yearly aim, one main step a day, a timer your agent runs.

- Trust score: 85/100 (high trust)
- Change this week: +3
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-11-05

## Components

- remote · `mcp.aimyear.com`: 85/100 (this document), [markdown](https://verifymcp.io/servers/yahhi-aimyear-mcp/mcp.md), [page](https://verifymcp.io/servers/yahhi-aimyear-mcp/mcp)

## Channel facts

- Endpoint: `https://mcp.aimyear.com/mcp`
- Transports: `streamable-http`
- Auth: `required`
- Version: `0.4.2`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-11-05.

- **Endpoint Security**: 89/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation is enforced on tool calls, advertised via RFC 9728 protected-resource metadata. Discovery is public, which costs nothing: no tool can be invoked without a token.
  - HTTPS is enforced; there's no plaintext access path.
  - HSTS check failed: the Strict-Transport-Security header is absent.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
  - The authorisation server offers only Dynamic Client Registration (RFC 7591), which MCP 2026-07-28 deprecated in favour of Client ID Metadata Documents.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 78/100
  - 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).
  - AI-judged instruction clarity (good).
  - Context-footprint check failed: tool/resource definitions use about 5970 tokens (~112/item across 53 items; 52 tools + 1 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 60/100
  - Stability observed for 18 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 84/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 52% of tool parameters carry a description.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - All 6 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.
  - An AI judge read all 54 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### How do I install the AimYear MCP server?

AimYear is a hosted endpoint at https://mcp.aimyear.com/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add --transport http yahhi-aimyear-mcp 'https://mcp.aimyear.com/mcp'
```

### Cursor

```json
{
  "mcpServers": {
    "yahhi-aimyear-mcp": {
      "url": "https://mcp.aimyear.com/mcp"
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "yahhi-aimyear-mcp": {
      "type": "http",
      "url": "https://mcp.aimyear.com/mcp"
    }
  }
}
```

### Codex

```toml
[mcp_servers.yahhi-aimyear-mcp]
url = "https://mcp.aimyear.com/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "yahhi-aimyear-mcp": {
      "type": "remote",
      "url": "https://mcp.aimyear.com/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add yahhi-aimyear-mcp --url 'https://mcp.aimyear.com/mcp' --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  yahhi-aimyear-mcp:
    url: "https://mcp.aimyear.com/mcp"
```

### Netclaw

```json
{
  "McpServers": {
    "yahhi-aimyear-mcp": {
      "Transport": "http",
      "Url": "https://mcp.aimyear.com/mcp"
    }
  }
}
```

### Vellum

```bash
assistant mcp add yahhi-aimyear-mcp -t streamable-http -u 'https://mcp.aimyear.com/mcp'
```

### Other

```json
{
  "mcpServers": {
    "yahhi-aimyear-mcp": {
      "type": "http",
      "url": "https://mcp.aimyear.com/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-11-05 (score 85, +1)

No change was recorded against any check on this day. Stability & Change Management went from 57 to 60. That category is still filling its 30-day observation window: 17 days of observed history at the previous scan, 18 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-11-03 (score 84, +1)

No change was recorded against any check on this day. Stability & Change Management went from 50 to 53. That category is still filling its 30-day observation window: 15 days of observed history at the previous scan, 16 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-11-01 (score 83, +1)

No change was recorded against any check on this day. Stability & Change Management went from 43 to 47. That category is still filling its 30-day observation window: 13 days of observed history at the previous scan, 14 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-31 (score 82, 0)

- [functional] Server version: 0.11.1 → 0.11.2

### 2026-10-29 (score 82, +1)

No change was recorded against any check on this day. Stability & Change Management went from 33 to 37. That category is still filling its 30-day observation window: 10 days of observed history at the previous scan, 11 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-27 (score 81, +1)

- [security] The server rewrote its instructions, which are the text every model session reads
- [security] New tool “set_tracks”, which the server declares destructive
- [security] Tool “edit_milestone” rewrote its description, which is the text the model reads
- [security] Tool “get_path” rewrote its description, which is the text the model reads
- [security] Tool “next_steps” rewrote its description, which is the text the model reads
- [security] Tool “set_milestones” rewrote its description, which is the text the model reads
- [functional] The server now declares the “resources” capability
- [functional] New prompt “aim”
- [functional] New resource “aim-skill”
- [functional] Server version: 0.9.0 → 0.11.1
- [cosmetic] “edit_milestone” added an optional parameter “trackId”

### 2026-10-25 (score 80, +1)

No change was recorded against any check on this day. Stability & Change Management went from 20 to 23. That category is still filling its 30-day observation window: 6 days of observed history at the previous scan, 7 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-23 (score 79, +1)

- [security] The server rewrote its instructions, which are the text every model session reads
- [security] New tool “delete_agent”, which the server declares destructive
- [security] New tool “delete_social_account”, which the server declares destructive
- [security] Tool “get_settings” rewrote its description, which is the text the model reads
- [security] Tool “set_settings” rewrote its description, which is the text the model reads
- [functional regression] Schema quality: 4795 → 5633
- [functional] Server version: 0.7.0 → 0.9.0
- [functional] New tool “add_post”
- [functional] New tool “add_social_account”
- [functional] New tool “get_insights”
- [functional] New tool “get_post_draft”
- [functional] New tool “list_agents”
- [functional] New tool “list_social_accounts”
- [cosmetic] “set_settings” added an optional parameter “post_to”

## MCP tools (52)

### `get_goal` (~50 tokens)

Get goal

The one yearly goal: kind (count or done), metric, starting value, current value, target, deadline, progress, levers (hard/comfortable) and other projects. Call first in most flows.

### `check_goal_draft` (~208 tokens)

Check goal draft

Check a goal that is not saved yet against the rubric (a countable metric with value today and target, or a done-or-not result you can check yes or no; deadline within 12 months; pace per week). Changes nothing. Returns problems[] and next_question: loop until problems is empty, then call set_goal. Prefer count; use done only when no honest number exists.

Input parameters:

- `baseline` (number): value today
- `deadline` (string): YYYY-MM-DD in the user's timezone
- `kind` (string): count (default): a number from baseline to target, e.g. "15 paying customers". done: a one-time result checked yes or no, e.g. "launch v2 in the stores"; no metric, baseline or target, progress is th…
- `metric` (string): the one number and its unit, e.g. "paying customers"
- `target` (number)
- `title` (string)

### `set_goal` (~185 tokens)

Set goal

Save the yearly goal, or replace it with the next one. Rejects with problems[] if the rubric fails. Keeps levers and projects. area is which of the five life areas the goal belongs to.

Input parameters:

- `area` (string): default money
- `baseline` (number): value today; required for kind count
- `deadline` (string, required): YYYY-MM-DD in the user's timezone
- `kind` (string): count (default): a number from baseline to target, e.g. "15 paying customers". done: a one-time result checked yes or no, e.g. "launch v2 in the stores"; no metric, baseline or target, progress is th…
- `metric` (string): required for kind count
- `target` (number): required for kind count
- `title` (string, required)
- `why` (string)

### `record_progress` (~127 tokens)

Record progress

Record the current value of the goal metric ("I now have 4 customers"), or of a countable milestone when milestoneId is given ("I have talked to 7 people"). For a done-or-not goal, 1 marks it done. One value per date: calling again for the same date corrects it. Says when the target is reached; a countable milestone that reaches its target is done.

Input parameters:

- `date` (string): YYYY-MM-DD in the user's timezone
- `milestoneId` (string): a countable milestone instead of the goal
- `value` (number, required)

### `set_levers` (~66 tokens)

Set levers

Replace the list of levers: the recurring kinds of goal work. At least one must be kind=hard (the work the user avoids). keywords/repos are hints for classifying sessions from their task text. Pass existing ids to keep them.

Input parameters:

- `levers` (array, required)

### `set_projects` (~73 tokens)

Set projects

Replace the list of other projects (paid work, other products, life routines), so their sessions count as other work or life, not goal work. Pass the whole list: leave one out to remove it, change its name or hints to edit it. Pass existing ids to keep them.

Input parameters:

- `projects` (array, required)

### `get_path` (~87 tokens)

Get path

Milestones with kind, progress (recorded value or steps done), pace (ahead/on_pace/behind) and their steps. With tracks: tracks[], each with its current_milestone_id (every track has its own current milestone); current_milestone_id is then the first open one in list order. Without tracks, current_milestone_id is the one to work on.

### `set_milestones` (~94 tokens)

Set milestones

Replace the list of ordered milestones under the goal (2–6, or up to 6 per track), each countable (metric and target) or measured by its steps, with a due date before the goal deadline; due dates in order within a track. Pass each existing id, or that milestone's steps are deleted. To change one milestone, use edit_milestone.

Input parameters:

- `milestones` (array, required)

### `set_tracks` (~114 tokens)

Set tracks

Replace the tracks of the path: 0 to 3 different ways to reach the same aim (e.g. two products that could each earn the target), each with its own milestones and current milestone. reach says how this track alone would reach the aim. milestoneIds puts those milestones into the track, in that order. An empty list makes the path one list again. Use tracks only when the user chooses to work on more than one way; never present one track as the wrong one.

Input parameters:

- `tracks` (array, required)

### `edit_milestone` (~182 tokens)

Edit milestone

Change one milestone: title, kind (count or steps), metric, target, due date, status or track. status=retired drops it without finishing; done or retired moves its track to the next milestone. Its steps are kept.

Input parameters:

- `due` (string): YYYY-MM-DD in the user's timezone
- `kind` (string): count: progress is a recorded value against target ("talk to 20 people"); steps: progress is steps done ("implement the onboarding flow"), no metric needed. Default: count when metric and target are…
- `metric` (string)
- `milestoneId` (string, required)
- `status` (string)
- `target` (number)
- `title` (string)
- `trackId` (string): move it to this track (set_tracks)

### `add_steps` (~138 tokens)

Add steps

Add concrete steps to a milestone. A step is an action that fits a few work blocks ("email 10 people from the waitlist"), not "do marketing". Abstract steps are rejected. Put a hard-lever step first; preparation only where it blocks it (warns otherwise).

Input parameters:

- `milestoneId` (string, required)
- `op_id` (string): for apps replaying queued requests: an id the app minted before its first attempt and reuses on retries, so the write is applied once and a retry gets the first answer back. Do not invent one; an age…
- `steps` (array, required)

### `edit_step` (~73 tokens)

Edit step

Change one step: title, status (todo/doing/done), order, lever, estimate.

Input parameters:

- `estimateMin` (integer)
- `leverId` (string)
- `order` (integer)
- `status` (string)
- `stepId` (string, required)
- `title` (string)

### `delete_step` (~23 tokens)

Delete step

Delete one step from the path.

Input parameters:

- `stepId` (string, required)

### `next_steps` (~49 tokens)

Next steps

Open steps of the current milestone (of every track, taken in turns, each step with its track), hard-lever steps first: the candidates for today's main step.

Input parameters:

- `count` (integer)

### `get_commitments` (~33 tokens)

Get commitments

Recurring weekly time: commitments (school runs, training, classes), overhead (sleep, meals) and focus windows.

### `set_commitments` (~56 tokens)

Set commitments

Replace the list of recurring weekly commitments. days are ISO weekdays 1=Mon..7=Sun; use timesPerWeek instead when there are no fixed days. Pass existing ids to keep them.

Input parameters:

- `commitments` (array, required)

### `get_capacity` (~40 tokens)

Get capacity

Weekly time budget out of 168 hours: overhead, hours committed per area, focus windows, and what is still unaccounted for. Nothing is assumed.

### `get_planning_context` (~67 tokens)

Get planning context

Everything needed to plan a day: goal and pace, next_steps, yesterday's summary and undone items, week balance, days since a hard lever. Defaults to tomorrow. The agent plans; then call set_plan.

Input parameters:

- `date` (string): YYYY-MM-DD in the user's timezone

### `get_plan` (~31 tokens)

Get plan

The plan for a day (default today).

Input parameters:

- `date` (string): YYYY-MM-DD in the user's timezone

### `set_plan` (~101 tokens)

Set plan

Replace the plan for a day. Exactly one item must have isMainStep=true (the step toward the goal), ideally linked by stepId from next_steps and on a hard lever. Warns when no item is on a hard lever. Other items: paid work, family, workout, etc. with their area. Items that stay keep their done state.

Input parameters:

- `date` (string): YYYY-MM-DD in the user's timezone
- `items` (array, required)

### `edit_plan_item` (~227 tokens)

Edit plan item

Change one plan item: mark it done or not done, rename it, change its estimate, area or links, or make it the main step. done=true also completes its linked path step. For a weekly routine, count says how many units this tick did (talked to 2 people today). For a routine, level minimum says only its bad-day minimum was done: it counts for the day, reported apart from full.

Input parameters:

- `area` (string)
- `count` (integer): units done in this tick, for a routine with perWeek; above 0 ticks it, 0 unticks it
- `date` (string): YYYY-MM-DD in the user's timezone
- `done` (boolean)
- `estimateMin` (integer)
- `isMainStep` (boolean)
- `itemId` (string, required)
- `level` (string): routines only; sets done unless done is given
- `leverId` (string)
- `projectId` (string)
- `stepId` (string)
- `title` (string)

### `get_routines` (~101 tokens)

Get routines

Routines: small steps that repeat on fixed weekdays, e.g. "talk with one person on Reddit", or that count up to a number a week, e.g. "talk to 5 people a week", each with an optional bad-day minimum. The server adds them to each matching day's plan, so every device and agent sees the same checks. With no routines yet, returns ready-made starters for the aim's area to offer as they are.

### `set_routines` (~153 tokens)

Set routines

Replace the list of routines: small steps that repeat on fixed weekdays. From today on, each one appears as a plan item on its days; tick it with edit_plan_item, skip it for one day with delete_plan_item. set_plan keeps them. days are ISO weekdays 1=Mon..7=Sun, default every day. perWeek makes it a weekly count: each tick adds its count (default 1), and once the week reaches perWeek it leaves the plan until Monday. Link it to the goal with leverId. minimum is the small version for a bad day ("read one thread" for "talk to one person"). Pass existing ids to keep them.

Input parameters:

- `routines` (array, required)

### `delete_plan_item` (~49 tokens)

Delete plan item

Remove one item from a day's plan. A routine item is skipped for that day only.

Input parameters:

- `date` (string): YYYY-MM-DD in the user's timezone
- `itemId` (string, required)

### `set_day_mode` (~58 tokens)

Set day mode

Tracking for a day: full (everything recorded, the default) or off (timer and reminders only, nothing stored, no plan required).

Input parameters:

- `date` (string): YYYY-MM-DD in the user's timezone
- `mode` (string, required)

### `get_now` (~38 tokens)

Get now

What is happening now: running sessions with attention shares, the timer, today's main step, today's minutes, the streak and a one-line nudge.

### `start_session` (~471 tokens)

Start session

Start a session of work and, if none is running, the timer. Returns a verdict: ok | stop | plan_first. On "stop" NO session is created: relay the message, ask the user; if they insist, call again with override=true. Several sessions may run at once (two terminals) and share attention by weight. Apps replaying a queued start pass op_id, their own session_id and start_at; an agent leaves all three out.

Input parameters:

- `area` (string): default work
- `direction` (string): up (default) counts elapsed time and runs until stopped, with a stand-up reminder every workMin; down is a fixed timebox, for a break
- `exclusive` (boolean): true: nothing else was happening then
- `itemId` (string): plan item id
- `leverId` (string)
- `minutes` (integer): length for a down timer, or the stand-up interval for an up timer
- `op_id` (string): for apps replaying queued requests: an id the app minted before its first attempt and reuses on retries, so the write is applied once and a retry gets the first answer back. Do not invent one; an age…
- `override` (boolean): true only after the user confirmed past a stop
- `projectId` (string)
- `session_id` (string): for apps: the session id the app minted itself. Create-if-absent: if a session with this id exists it is returned and nothing is created. An agent leaves it out; the server mints the id
- `start_at` (string): when the work began as ISO 8601 with offset, e.g. 2026-10-20T14:05:00+02:00. For apps delivering a request queued offline; an agent calling interactively leaves it out. Rejected before the session st…
- `stepId` (string): path step id
- `task` (string, required): what you are about to do, specific
- `weight` (number): attention weight vs other sessions at the same time, default 1
- `workplace` (string)

### `add_note` (~116 tokens)

Add note

Add a one-line note to a running session (this connection's, or session_id). May classify a session that was unclassified.

Input parameters:

- `note` (string, required)
- `op_id` (string): for apps replaying queued requests: an id the app minted before its first attempt and reuses on retries, so the write is applied once and a retry gets the first answer back. Do not invent one; an age…
- `session_id` (string): from get_now; required with op_id

### `split_attention` (~58 tokens)

Split attention

Set attention weights of the running sessions at once, e.g. {"abc": 0.7, "def": 0.3}. Applies to the whole session. For a finished session use edit_session.

Input parameters:

- `shares` (object, required)

### `stop_session` (~331 tokens)

Stop session

Stop a running session with a summary and outcome. Pass session_id from get_now; without it, only this connection's single running session is stopped, never another one. The timer keeps running for other sessions. outcome=done completes the linked plan item or path step. Without end_at or op_id it refuses a session that already ended: use edit_session for that. With end_at (apps delivering a stop queued offline) a second stop on the same session is merged, whatever order they arrive in: the earliest end wins, done wins over any other outcome, the first summary stays and a different later one goes to the notes; the answer says applied: ended | shortened | recorded.

Input parameters:

- `attention_share` (number): corrects the share in hindsight
- `end_at` (string): when the work ended as ISO 8601 with offset, e.g. 2026-10-20T14:05:00+02:00. For apps delivering a request queued offline; an agent calling interactively leaves it out. Rejected before the session st…
- `op_id` (string): for apps replaying queued requests: an id the app minted before its first attempt and reuses on retries, so the write is applied once and a retry gets the first answer back. Do not invent one; an age…
- `outcome` (string, required)
- `session_id` (string): from get_now; required with op_id or end_at
- `summary` (string, required)

### `stop_timer` (~81 tokens)

Stop timer

Stop the timer ("pause", "stop", "stand up") and every running session with it. There is no paused state: resuming starts a new session. Pass summary and outcome to save them on the sessions it closes, or call stop_session first. Returns the break length.

Input parameters:

- `outcome` (string): default partial
- `summary` (string)

### `add_session` (~265 tokens)

Add session

Add past time that was not timed: minutes (ending now, or at end), or start+end as HH:MM on date. For calls, children, workout, paid work, or work done away from the agent. Apps replaying a queued entry pass op_id, so a retry does not count the time twice.

Input parameters:

- `area` (string): default work
- `date` (string): YYYY-MM-DD in the user's timezone
- `end` (string): HH:MM local time
- `exclusive` (boolean): true: nothing else was happening then
- `itemId` (string): plan item id
- `leverId` (string)
- `minutes` (integer)
- `op_id` (string): for apps replaying queued requests: an id the app minted before its first attempt and reuses on retries, so the write is applied once and a retry gets the first answer back. Do not invent one; an age…
- `projectId` (string)
- `start` (string): HH:MM local time
- `stepId` (string): path step id
- `task` (string, required)
- `weight` (number): attention weight vs other sessions at the same time, default 1

### `edit_session` (~254 tokens)

Edit session

Fix a session, running or finished: start and end (HH:MM on date; an end before the start means it ran past midnight), task, area, project, lever, step, plan item, summary, outcome, attention share, weight. It is classified again after a change. Use it when a timer was forgotten or a session was labelled wrong.

Input parameters:

- `area` (string): default work
- `attention_share` (number): share of the session's wall time that was real attention
- `date` (string): local date of start and end; default the session's own date
- `end` (string): HH:MM local time
- `exclusive` (boolean): true: nothing else was happening then
- `itemId` (string): plan item id
- `leverId` (string)
- `outcome` (string)
- `projectId` (string)
- `session_id` (string, required)
- `start` (string): HH:MM local time
- `stepId` (string): path step id
- `summary` (string)
- `task` (string)
- `weight` (number): attention weight vs other sessions at the same time, default 1

### `delete_session` (~119 tokens)

Delete session

Delete a session, running or finished, so it no longer counts. Pass session_id from get_now or list_sessions; without it, only this connection's single running session is deleted, never another one.

Input parameters:

- `op_id` (string): for apps replaying queued requests: an id the app minted before its first attempt and reuses on retries, so the write is applied once and a retry gets the first answer back. Do not invent one; an age…
- `session_id` (string): required with op_id

### `list_sessions` (~74 tokens)

List sessions

Sessions in a date range (default the last 7 days), with ids, optionally filtered by area or project.

Input parameters:

- `area` (string)
- `from` (string): YYYY-MM-DD in the user's timezone
- `projectId` (string)
- `to` (string): YYYY-MM-DD in the user's timezone

### `find_gaps` (~48 tokens)

Find gaps

Untimed stretches of 20+ minutes between the first and last session of a day. Ask the user what happened there.

Input parameters:

- `date` (string): YYYY-MM-DD in the user's timezone

### `summarize_day` (~47 tokens)

Summarize day

Full summary of a day: wall and attention minutes per area, classification and lever, sessions, gaps, overlaps, overrides.

Input parameters:

- `date` (string): YYYY-MM-DD in the user's timezone

### `summarize_week` (~57 tokens)

Summarize week

A week, Monday to Sunday (to today for the current week): main-step days, goal share, hard share, area balance, overrides, streak, milestone pace.

Input parameters:

- `date` (string): any day of the week, default today

### `get_insights` (~139 tokens)

Get insights

Week (the last 7 days) or month (the last 30 days) ending on to (default today): minutes per day on the aim, other work and life; hard vs comfortable share of aim time; an hour × weekday heatmap of aim minutes (6:00–23:00, Mon–Sun) with its hard part and the peak; main-step days; and comebacks (active days after 2+ days away, over 90 days). Wall minutes of finished sessions, as the app shows them.

Input parameters:

- `range` (string): default week
- `to` (string): last day, default today

### `find_leaks` (~76 tokens)

Find leaks

Where time leaks: comfortable goal work while the main step waited, overrides, unplanned work, gaps, switching, missed main steps, days without a plan. Default the last 7 days.

Input parameters:

- `from` (string): YYYY-MM-DD in the user's timezone
- `to` (string): YYYY-MM-DD in the user's timezone

### `get_settings` (~32 tokens)

Get settings

Timezone, where reminders go (desktop or mobile), timer settings, and which networks get progress posts (post_to).

### `set_settings` (~150 tokens)

Set settings

Change any of: timezone (IANA name, e.g. Europe/Madrid; it sets where each day starts and ends), workplace for reminders, stand-up interval workMin, breakMin, longBreakEvery, longBreakMin, standup on/off, post_to (networks for progress posts).

Input parameters:

- `breakMin` (integer)
- `longBreakEvery` (integer)
- `longBreakMin` (integer)
- `post_to` (array): which connected networks get the day's progress post (the app sets it); [] for none
- `standup` (boolean)
- `timezone` (string)
- `workMin` (integer)
- `workplace` (string)

### `add_device` (~62 tokens)

Add device

Register a device token so server reminders (stand up, break over) can reach it. The phone app registers itself; use this for testing or a manual token.

Input parameters:

- `label` (string)
- `platform` (string, required)
- `token` (string, required)

### `list_devices` (~21 tokens)

List devices

Which devices can receive reminders, and when each was last seen.

### `delete_device` (~24 tokens)

Delete device

Remove a device so it stops receiving reminders.

Input parameters:

- `token` (string, required)

### `list_agents` (~51 tokens)

List agents

Agents connected to this AimYear account (Claude, ChatGPT, Claude Code, the AimYear app…): name, client_id, when it connected and when it was last active. current marks the one calling.

### `delete_agent` (~55 tokens)

Delete agent

Disconnect one agent: its sign-in for this account is deleted and it can no longer read or change anything until it connects again. Only on the user's explicit request. client_id from list_agents.

Input parameters:

- `client_id` (string, required)

### `add_social_account` (~167 tokens)

Add social account

Connect WIP (wip.co) or Bluesky so AimYear can post the day's progress there when the user says Post (Pro). WIP: api_key from wip.co settings. Bluesky: handle and an app password (Settings → Privacy and security → App passwords), never the account password. The login is checked, stored encrypted and never shown again. The app's connect screen usually calls this; if the user pastes a key into the chat, use it once and do not repeat it.

Input parameters:

- `api_key` (string): WIP only
- `app_password` (string): Bluesky only: xxxx-xxxx-xxxx-xxxx
- `handle` (string): Bluesky only, e.g. name.bsky.social
- `network` (string, required)

### `list_social_accounts` (~38 tokens)

List social accounts

Connected networks (handle, since when), which of them get progress posts, and whether the user has Pro. Never returns any key or password.

### `delete_social_account` (~31 tokens)

Delete social account

Disconnect a network and delete its saved login. Posts already made stay there.

Input parameters:

- `network` (string, required)

### `get_post_draft` (~97 tokens)

Get post draft

The day's progress post drafted from the record (aim and progress, main step done or not, minutes on the aim and on hard work, routines, comebacks), at most 300 characters, ending with aimyear.com; and per network whether it is ready, already posted, or skipped because the user already posted there that day. Posts nothing. Pro.

Input parameters:

- `date` (string): YYYY-MM-DD in the user's timezone

### `add_post` (~124 tokens)

Add post

Post the day's progress, only after the user explicitly said to post. text is the draft as the user edited it (default: the draft from get_post_draft). Goes to the networks chosen in settings, or the ones given. A network where the user already posted that day themselves is skipped. Each day goes to each network once: a retry never posts twice. Today or yesterday only. Pro.

Input parameters:

- `date` (string): YYYY-MM-DD in the user's timezone
- `networks` (array): default: the networks chosen in settings
- `text` (string)

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/yahhi-aimyear-mcp/mcp#diagnostics

## Score history

- 2026-11-05: 85
- 2026-11-04: 84
- 2026-11-03: 84
- 2026-11-02: 83
- 2026-11-01: 83
- 2026-10-31: 82
- 2026-10-30: 82
- 2026-10-29: 82
- 2026-10-28: 81
- 2026-10-27: 81
- 2026-10-26: 80
- 2026-10-25: 80
- 2026-10-24: 79
- 2026-10-23: 79
- 2026-10-22: 78
- 2026-10-21: 78
- 2026-10-20: 77
- 2026-10-19: 76
- 2026-10-18: 76

## Common questions

### What is the AimYear MCP server?

AimYear is an MCP server listed in the public MCP registry as io.github.Yahhi/aimyear-mcp. Accountability partner in your agent: one yearly aim, one main step a day, a timer your agent runs. This page covers its hosted endpoint (https://mcp.aimyear.com/mcp).

### Is the AimYear MCP server safe to use?

AimYear scores 85 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the AimYear MCP server expose?

AimYear exposes 52 tools: get_goal, check_goal_draft, set_goal, record_progress, set_levers, and 47 more. Their descriptions and schemas cost roughly 5,411 tokens of context every time the server is loaded.

### Does the AimYear MCP server require authentication?

Yes. AimYear asked us for credentials when we connected, so you will need to authorise it in your MCP client before it can do anything.

### Is the AimYear MCP server still maintained?

AimYear is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

## Links

- Remote endpoint: https://mcp.aimyear.com/mcp
- Repository: https://github.com/Yahhi/aimyear-mcp
- Website: https://aimyear.com/
- Changelog RSS feed: https://verifymcp.io/servers/yahhi-aimyear-mcp/mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/yahhi-aimyear-mcp/mcp.json
- HTML version of this page: https://verifymcp.io/servers/yahhi-aimyear-mcp/mcp