Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@agentrava log my latest coding session and show me my achievement card"
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.
Strava, for agents. An MCP server that turns a finished coding session into a bragging card — route map, elevation profile, headline stats, badges, PRs.
Strava | Agentrava | Formula |
Distance | ground covered |
|
Elevation gain | the parts that hurt |
|
Moving time | session time, idle gaps excluded | gaps over 5 min are not counted |
Pace | minutes per km |
|
Cadence | tool calls per minute |
|
Suffer score | Effort, 0–100 | cadence, elevation, tokens and retries |
Calories | tokens burned | input + cache writes + output |
Economy | tokens per km |
|
— | API cost | priced per message at list rates, split by token class |
Every weight above is fitted to a sample of 36 real sessions, not guessed. Churn alone left the median session at 0.00 km — most sessions read and search far more than they write — which is why tool calls carry distance too. Effort lands at a median of 31 and only saturates for genuinely brutal sessions, and the badge curve below averages 3.1 badges per card.
The route map is generated deterministically from the activity id, so a card always redraws identically. Every error you recovered from draws as a loop on the map — the trace shows where you went in circles.
Related MCP server: Strava MCP Server
The inputs are all directly measured. The scales are invented — 100 lines = 1 km, 25 tool calls = 1 km, an error = 120 m — chosen so a median session lands near a plausible 4.4 km. That makes the numbers comparable between your own sessions, which is what PRs and the leaderboard rest on, and meaningless outside Agentrava.
Measured across 134 real sessions:
correlates most with | r | |
Distance | tool calls | 0.94 |
Distance | churn | 0.86 |
Distance | duration | 0.77 |
Elevation | errors recovered | 0.91 |
Elevation | files changed | 0.88 |
Raw tokens cannot rank efficiency. They correlate 0.72 with distance, so the number mostly says how big a session was. Dividing by distance gives Economy, which correlates 0.08 with distance — size-independent, and therefore actually comparable between sessions. Across 142 sessions it spans 83k/km at the tenth percentile to 435k/km at the ninetieth, a 5.3x spread. It measures token cost per unit of volume, not per unit of value: a session that finds the right answer in five calls scores badly on it. And Cursor records tokens for only 4% of sessions, so it is not comparable across tools.
So distance is essentially volume of activity — 69% of it comes from the tool-call term, not churn — and elevation is essentially friction, 58% of it from errors. Distance and elevation correlate 0.79 with each other: overlapping, but about a third of elevation is information distance doesn't carry. That's the part that separates a long easy session from a short brutal one.
log_activity — log a session, get the card back as an image. Everything is
optional; unreported fields count as zero.
get_profile — career totals, current streak, personal records, trophy case.
list_activities — the feed.
recap — one card for a whole period: totals, a day-by-day activity heatmap,
an hour-of-day histogram of when the work actually happened, trophy case, longest
streak, biggest session. Takes optional from / to / title.
leaderboard — rank sessions by distance, elevation, duration, effort, tokens or tool calls.
Earnable, not participation trophies:
Negative Splits deleted more than you wrote · Flawless no errors, no failed tests ·
Hill Repeats climbed out of it 3+ times · Marathon 1h+ · Ultra 3h+ ·
Sprint under 3 minutes with a diff · Yak Shave 30+ tool calls, barely a diff ·
All Green full suite, zero red · Furnace 500k+ tokens · Nocturnal logged 11pm–5am ·
Everest 3000m+ · 10K Club 10 km covered · Gran Fondo 40 km ·
Polyglot 3+ languages · Red Zone effort 90+ · Sightseeing all reading, no writing ·
Signed Off 10+ edits accepted, none sent back (Cursor only — 9% of sessions)
Measured frequency across those 36 sessions: Hill Repeats 47%, Marathon 44%,
Yak Shave 36%, Polyglot 31%, 10K Club 25%, Ultra 22%, Flawless 22%,
Nocturnal 19%, Red Zone 14%, Furnace 8%, Everest 8%.
Personal records only fire once there is something to beat, so the first activity never claims one.
hooks/session-log.mjs reads the Claude Code session transcript and logs the
activity from measured numbers, so nothing depends on the agent reporting
itself honestly. Install it by adding this to ~/.claude/settings.json:
{
"hooks": {
"Stop": [{
"hooks": [{
"type": "command",
"command": "node /path/to/agentrava/hooks/session-log.mjs",
"async": true,
"timeout": 30
}]
}]
}
}It runs on every Stop and upserts the same session's activity, so the entry
grows as the session grows and survives a session that is killed rather than
closed. Sessions under 8 tool calls or 2 minutes are ignored. async: true keeps
it off the critical path — a 42 MB transcript parses in about 0.6 s. Activity log
at ~/.agentrava/hook.log.
What it measures, and how:
Field | Source |
Tool calls |
|
Tokens |
|
Lines ± |
|
Files | Edit/Write paths, plus shell redirect / |
Errors recovered |
|
Moving time | consecutive timestamp gaps, each capped at 5 min |
Type | inferred from the shape of the session |
The hook fires on its own, but you can run the exact same code against any session — useful for backfilling, or when you want the card now:
npm run log # the most recently active session
node scripts/log-now.mjs --list # the 15 most recent, newest first
node scripts/log-now.mjs 9e22ccfa # one session by id prefix
node scripts/log-now.mjs ~/.claude/projects/<proj>/<id>.jsonlIt finds transcripts under ~/.claude/projects/, reads each session's own
recorded cwd, and upserts — so running it repeatedly on the same session
updates that one activity instead of stacking duplicates. It prints the log line
it wrote, or tells you the session fell under the 8 tool call / 2 minute floor.
Cache reads are excluded from tokens. Replayed context is not work done.
Including it put every session over 10M and made Furnace meaningless.
Shell writes are detected heuristically. Files written with cat > f <<EOF
leave no diff, so the paths are recovered from the command text (heredoc bodies
stripped first, or every > in generated HTML counts as a write). This is a
regex, and it is deliberately conservative: it misses writes rather than
inventing them. Line counts for those files are not recovered, so churn
still under-reports on shell-heavy sessions.
Type inference is a guess from files, churn and error count — not a claim about intent.
git clone <repo> ~/agentrava && cd ~/agentrava
npm run setup # add --cursor to also install the Cursor probescripts/install.mjs installs dependencies, registers the MCP server at user
scope, and merges the Stop hook into ~/.claude/settings.json. It is idempotent,
backs up every file it edits, and npm run setup -- --uninstall reverses all of
it (your activities and cards in ~/.agentrava are left alone).
Then restart Claude Code and run node scripts/backfill.mjs to log your history.
Any MCP client works — it speaks stdio:
{ "mcpServers": { "agentrava": { "command": "node", "args": ["/path/to/agentrava/src/index.js"] } } }Log every past session at once. Sorted by session start time, because personal records are judged against prior history — replaying out of order would award them to whichever session happened to be processed first.
node scripts/backfill.mjs --dry-run # report only, writes nothing
node scripts/backfill.mjs # log everything not yet logged
node scripts/backfill.mjs --force # recompute sessions already logged
node scripts/backfill.mjs --no-cards # skip PNG renderingIt walks ~/.claude/projects/ recursively — git-worktree sessions live several
levels deep — and skips anything under the tool-call / moving-time floor. Roughly
900 MB of transcripts takes about 25 seconds including card rendering.
Cursor is supported for logging, with real caveats. It stores chat in SQLite
(~/Library/Application Support/Cursor/User/globalStorage/state.vscdb) as one row
per message, keyed bubbleId:<conversationId>:<bubbleId>.
node scripts/cursor-backfill.mjs --dry-run # report only
node scripts/cursor-backfill.mjs # log every Cursor conversationThe whole database is read in one grouped pass (~60 s for 287 conversations).
Per-conversation LIKE 'bubbleId:<id>:%' queries are each a full scan of a
multi-GB table and time out; don't reintroduce them.
Measured across 287 real conversations (266 with 8+ tool calls):
signal | coverage | usable |
tool calls | 266/266 | ✅ |
moving time | 266/266 | ✅ |
files touched | 256/266 (96%) | ✅ |
errors | 129/266 (48%) | ✅ — a real |
tokens | 8/266 (3%) | ❌ reports 0 |
line churn | 7/266 (3%) | ❌ deliberately zeroed |
tokenCount exists in the schema but has been unpopulated since January 2026.
Churn is disabled on purpose. Cursor's main edit tool (edit_file_v2) stores the
whole new file body rather than a diff, so counting its lines scored one session
at 381 km off +27k "added" lines that were mostly unchanged text. A metric
present for 3% of sessions and inflated when present makes sessions
incomparable — so Cursor distance comes from tool calls alone.
Cursor also records something Claude Code does not: userDecision
(accepted / rejected) per edit. That is the closest thing to an outcome signal
in any transcript, and nothing on the card uses it yet.
Cursor has a stop hook with the same stdio-JSON contract as Claude Code, and its
payload carries conversation_id, transcript_path, workspace_roots and
status. hooks/cursor-probe.mjs records one real payload to
~/.agentrava/cursor-probe.jsonl; install it in ~/.cursor/hooks.json:
{ "version": 1, "hooks": { "stop": [{ "command": "node /path/to/agentrava/hooks/cursor-probe.mjs" }] } }Live auto-logging is not wired up yet: a full scan takes ~60 s, which is too slow to run on every turn. It needs either a cached scan or a targeted single-conversation query first.
The subtitle is your first prompt, and prompts name customers, vendors and internal projects. Path sanitising is not enough — check the text.
node scripts/privacy.mjs # list subtitles that look sensitive
node scripts/privacy.mjs --strip # blank just those
node scripts/privacy.mjs --strip-all # blank all, and stop recording themPer-card, before posting:
node scripts/card.mjs <session> --no-summary
node scripts/card.mjs <session> --summary "Chased a render bug for four hours"To never record one, put {"summaries": "off"} in ~/.agentrava/config.json
(or run --strip-all, which sets it for you). The detector flags company
suffixes and capitalised proper names; it will not catch everything — a
subtitle like "fix the checkout bug for acme" reads as clean. Cards are built to
be shared, so read the subtitle before you post one.
The athlete is you, not the model — Strava does not file your rides under the
bike. The model that did the work is gear, shown under the title with the client:
Claude Opus 5 · Cursor.
node scripts/whoami.mjs "Luka" # set the name on every card, past and future
node scripts/whoami.mjs # show the current oneset_athlete does the same from chat. Unset, cards read "Athlete", which is the
safe default for sharing. The model is measured, never assumed: Claude Code
records it per message, and Cursor records it for about a sixth of conversations
— the rest show only the client.
Cards name the client in the header — CURSOR · DEBUG, CLAUDE CODE · FEATURE.
Known ids: claude-code, claude, cursor, openai, codex, grok,
copilot, windsurf, zed; anything else renders as its own name.
No logo artwork ships with this repo. Those marks are trademarks of their owners, and bundling them into an MIT repo means redistributing brand assets that most brand guidelines restrict. Naming a product is ordinary nominative use; shipping its logo is not the same thing.
If you want logos on your own cards, put a file at
~/.agentrava/logos/<client>.svg (or .png, under 512 KB) and it is drawn
beside the name:
~/.agentrava/logos/cursor.svg
~/.agentrava/logos/claude-code.pngSourcing those files, and honouring each company's brand guidelines, is your call — which is why it is a local directory rather than a commit.
Claude Code records four token classes per message — input, output, cache write, cache read — so a session can be priced exactly, per message, at whatever model produced it. Rates are Anthropic list prices; cache writes bill at 1.25x input and cache reads at 0.1x.
This is not a bill. Claude Code on a subscription does not charge per token. The figure is what the session would have cost on the API at list price — useful for comparing sessions, useless as an invoice. Cursor records tokens for about 4% of sessions, so most Cursor cards show no cost at all.
The split is the interesting part. Across 136 priced sessions: 0.7M input, 48.5M output, 373M cache writes and 17.2 billion cache reads — 98% of all tokens are cache reads, which is why they dominate the cost even at a tenth of the input rate.
Strava lets you put your ride photo behind the route. So does this.
node scripts/card.mjs <session> --photo ~/me-in-a-hammock.jpg
node scripts/card.mjs <session> --photo chat # the image you just pasted
node scripts/card.mjs <session> --no-photo--photo chat needs no file. An image pasted into Claude Code never becomes a
file on disk — it is stored as base64 inside the session transcript — so this
recovers the most recent one, writes it to ~/.agentrava/photos/ named by
content hash, and uses that. snapshot and log_activity accept
photo: "chat" for the same reason: you can paste a picture and just ask.
The image fills the map panel, the route is drawn over it with a heavier outline,
and a bottom scrim keeps the elevation strip readable. jpg/png/gif/webp under
8 MB; it is embedded in the card, so the card stays a single self-contained file.
The path is remembered on the activity, so redraws keep it. log_activity takes
a photo argument too.
Activities live in ~/.agentrava/activities.json, cards in ~/.agentrava/cards/
as both PNG and SVG. Override the location with AGENTRAVA_HOME. Nothing leaves
the machine; there is no network call anywhere in this server.
PNG rasterisation uses @resvg/resvg-js. If it fails to install, the server still
runs and writes SVG only — the inline image is simply omitted.
npm run demo # render three contrasting sample cards
node scripts/e2e.js # drive the server over real MCP stdio
node scripts/rerender.js # redraw stored cards after changing card.js
node scripts/rerender.js --prune # also delete cards whose activity is gone
node scripts/recap.js # season recap over everything
node scripts/recap.js 2026-08-01 2026-08-31 # or a date range
# exercise the hook against a real transcript without touching your store
AGENTRAVA_HOME=/tmp/ar node hooks/session-log.mjs \
<<< '{"session_id":"test","transcript_path":"'"$HOME"'/.claude/projects/<proj>/<id>.jsonl","cwd":"'"$PWD"'"}'MIT — see LICENSE.
Career totals, current streak, personal records and the trophy case across every logged activity.
| Name | Required | Description | Default |
|---|---|---|---|
| athlete | No | Filter to one athlete. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry behavioral weight. It explains the scope ('across every logged activity') and the output categories, which gives some transparency about aggregation behavior. However, it does not clarify default behavior when the optional athlete parameter is omitted, response shape, permissions, or whether anything beyond reading occurs.
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, compact sentence with no filler. It front-loads the main output categories and closes with the important scope qualifier ('across every logged activity'). Every phrase contributes meaning.
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 simple tool with one optional parameter and no output schema, the description names the main content areas but leaves some gaps. The term 'trophy case' is not explained, and the behavior when athlete is omitted is not stated. Overall it is adeuate but not fully self-sufficient.
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%, and the schema already explains that athlete filters to one athlete. The tool description adds no detail about how the athlete filter interacts with 'every logged activity,' but because the schema is complete, a 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 clearly communicates that this tool returns an athlete profile built from career totals, current streak, personal records, and trophy case information. It does not use an explicit verb like 'retrieves' or 'returns,' but the tool name plus the resource content make the purpose clear. It is distinct from raw activity listing, though it doesn't explicitly contrast with sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to call this tool versus list_activities, recap, snapshot, or leaderboard. The description implies an aggregate/profile use case, but it never states exclusions, alternatives, or prerequisites such as needing a selected athlete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rank logged sessions by a metric: distance, elevation, duration, effort, tokens or tool_calls.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| metric | No |
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 states the ranking behavior but omits important details such as whether the call is read-only, the sorting direction, default limit behavior, or the shape of the returned leaderboard. This is insufficient for an unannotated 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 sentence that front-loads the core action and resource and lists the metric options without any filler. It is efficient and easy to scan.
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 no annotations and no output schema, the description is not complete enough for confident invocation. An agent is left without information about the return value format, default parameters, or how the ranking is ordered. The description covers only the basic function.
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 description lists the metric enum values, but these are already fully captured in the schema. It adds no explanation of what 'effort' means, and it says nothing about the 'limit' parameter. With 0% schema description coverage, the description fails to compensate for the missing parameter semantics.
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 ('Rank'), names the resource ('logged sessions'), and enumerates the valid metrics, making it easy for an agent to understand what the tool does. It clearly distinguishes this from sibling tools like list_activities or recap, which have different purposes.
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 provides no guidance on when to use this tool versus its siblings. It does not mention alternatives or scenarios where ranking would be inappropriate; the use case is only implicit in the name and the verb 'Rank'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The feed: recent logged sessions with their headline stats.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many, newest first. Default 10. | |
| athlete | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of explaining behavior. It says the tool returns recent logged sessions and headline stats, but does not state whether this is read-only, how results are ordered, whether pagination exists, or how the athlete parameter affects results.
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 and is front-loaded with the main purpose. It avoids bloat, though it may be too terse to compensate for missing paramdetails.
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?
There is no output schema, no annotations, and one parameter is undocumented. The description conveys only a high-level view of the result and does not mention filtering, ordering, or what 'headline stats' concretely includes. For a simple two-parameter read tool it is close but still has important gaps.
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 schema documents limit ('How many, newest first. Default 10.') but athlete is left undescribed in both schema and description. The description adds no parameter meaning, so the agent has insufficient info to correctly use the athlete parameter.
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 this tool returns 'recent logged sessions with their headline stats,' which identifies the resource and output focus. It is not a tautology and can be distinguished from siblings like log_activity, but it does not explicitly contrast with them.
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 about when to prefer this tool over siblings such as leaderboard or recap, and no mention of alternatives or exclusions. The intended use is only inferred from 'recent' and 'feed,' so the agent does not receive explicit selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finish a coding session and get a Strava-style achievement card back as an image. Report the session honestly — line churn becomes distance, files and recovered errors become elevation, and the card awards badges and personal records against your own history. Call this when the user asks you to brag, or at the end of a session worth remembering.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ISO timestamp. Defaults to now. | |
| repo | No | Repo or project name. | |
| type | No | What kind of session this was. Defaults to "feature". | |
| photo | No | Card background, with the route drawn over it — Strava-style. A local image path (jpg/png/gif/webp, under 8 MB), or "chat" to use the image the user most recently pasted into this conversation. Ask the user for one; do not invent a path. | |
| title | No | Optional. Left blank, it is auto-named Strava-style from the clock and type — "Morning Refactor", "Late Night Debug". | |
| tokens | No | Tokens burned, if you know it. | |
| athlete | No | Who did the work. Defaults to "Claude". | |
| summary | No | One line on what you actually did. Shown under the title. | |
| languages | No | Languages touched. | |
| tool_calls | No | How many tool calls you made. | |
| lines_added | No | Lines added. | |
| tests_failed | No | Tests that failed. | |
| tests_passed | No | Tests that passed. | |
| files_changed | No | Distinct files created or edited. | |
| lines_removed | No | Lines removed. | |
| duration_seconds | No | Wall-clock length of the session. | |
| errors_recovered | No | Times you hit an error and worked past it. These draw as loops on the route map — be honest, they are the best part. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden and does disclose key behavior: the output is an image card, metrics are mapped gamification-style, and honesty is required. It implies persistence through 'your own history' but does not explicitly state that an activity record is saved.
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?
Three sentences, front-loaded with the tool's purpose and output, followed by the trigger condition. The playful wording earns its place by reinforcing the Strava-style behavior without adding fluff.
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 output is described as an image card, schema documentation covers parameters, and trigger conditions are clear. It could be more complete by explicitly stating that the activity is persisted and what happens on return, but none of this is critical for selecting or invoking the 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?
The schema description coverage is 100%, so the schema already documents all 17 parameters. The description adds a helpful metaphor—line churn becomes distance, errors become elevation—but does not explain individual parameter details, which is acceptable given full schema 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?
States a specific action and result: finish a coding session and receive a Strava-style achievement card as an image. It distinguishes itself by promising the card, badges, and personal records, though it does not explicitly contrast with sibling tools.
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?
Gives clear call triggers: when the user asks to brag or at the end of a session worth remembering. It does not list excluded scenarios or alternative sibling tools, but the guidance is sufficiently clear for an agent to know when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One card summarising a whole period: totals, a day-by-day activity heatmap, an hour-of-day histogram of when the work actually happened, the trophy case, longest streak and biggest session. Defaults to everything logged.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | End date, YYYY-MM-DD. Omit for today. | |
| from | No | Start date, YYYY-MM-DD. Omit for the beginning. | |
| title | No | Headline. Defaults to "N Activities". | |
| athlete | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure, and it does reveal the output components and the default date range. However, it does not state whether the tool is read-only, whether it respects a selected athlete, or what happens when no data exists.
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 words, front-loaded with the core purpose and followed by concrete output details. It is appropriately sized for the tool's complexity.
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 reasonably complete for a non-mutating summary tool, listing the main content of the output card and the default scope. However, with no output schema and no annotations, it leaves the athlete parameter's role ambiguous and does not clarify whether 'everything logged' is global or scoped to the current athlete.
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 75%, and the schema already documents to, from, and title defaults. The description's 'Defaults to everything logged' reinforces the date-range semantics but adds no new meaning for the undocumented athlete parameter.
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 purpose: produce a single card summarizing a whole period with totals, a heatmap, an hour-of-day histogram, trophy case, longest streak, and biggest session. This distinguishes it from list_activities and log_activity, though it does not explicitly differentiate it from snapshot.
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 explicit guidance on when to use recap versus sibling tools like snapshot, leaderboard, or list_activities. It mentions a default scope ('Defaults to everything logged'), but this is a parameter behavior rather than usage routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the name shown on every card. The athlete is the person whose account this is — the model that did the work is recorded separately as gear. Applies to past cards too. Ask the user what they want; do not guess a name from their email or filesystem.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Display name, e.g. "Luka" or "Luka Pecavar". Max 40 characters. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does well: it discloses that the change applies to past cards too, and warns against guessing. It could add more about overwriting behavior or lack of reversibility, but the core behavioral implications are covered.
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?
Three sentences, each earning its place: the main effect, the athlete/gear distinction, and a necessary user-interaction safeguard. Information is front-loaded and there is no fluff.
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 simple one-parameter setter, the description covers what is set, the scope of the change, and how to obtain the value. It does not describe the return value or error behavior, but that is a minor gap for this mutating tool with no output schema.
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 schema already fully documents the single parameter including format and max length, so the baseline is 3. The description adds useful context about the name being shown on cards, but does not add new parameter-level meaning beyond the 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?
States a specific action ('Set') on a specific resource (the athlete name shown on every card), and clarifies that the athlete is the account owner, not the model/gear. This distinguishes it clearly from siblings like get_profile and list_activities.
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?
Gives explicit usage guidance: always ask the user for the name and never guess from email or filesystem. It does not explicitly name alternatives, but the guidance is clear enough for an agent to know when and how to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Log the session that is running right now and return its card — mid-session, without waiting for it to end. Numbers are measured from the transcript (tool calls, tokens, diffs, recovered errors, moving time), not reported by you, so prefer this over log_activity whenever the work happened in Claude Code. Safe to call repeatedly: it updates the same activity instead of adding duplicates. With no argument it guesses the current session (matching working directory, else most recently written) and names which it chose — check that before repeating the numbers.
| Name | Required | Description | Default |
|---|---|---|---|
| photo | No | Card background: a local image path, or "chat" to use the image the user most recently pasted into this conversation. | |
| session | No | Session id prefix. Omit for the session in progress. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden and does so thoroughly: numbers come from the transcript rather than the agent, repeated calls update rather than duplicate, and session guessing has a defined fallback with a named choice.
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?
Every sentence earns its place: core action first, then sourcing, then alternative preference, then idempotency, then default behavior. It is dense but not padded.
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 optional parameters and no output schema, the description covers the essential call-time decisions: when to use it, what it measures, repeat-safety, and default session selection. Nothing critical is left for the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by explaining the no-argument session-guessing behavior and warning the agent to check which session was chosen before repeating numbers.
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?
Opens with a specific verb and resource: 'Log the session that is running right now and return its card.' It also explicitly distances itself from log_activity, making the tool's scope and identity unambiguous.
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?
Gives a concrete selection rule: prefer this over log_activity when the work happened in Claude Code. It also clarifies when it is safe to call repeatedly and how the no-argument default behaves.
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. Dates show when Glama detected each change.
v0.1.0get_profileleaderboardlist_activitieslog_activityrecapset_athletesnapshotMost tools have clearly distinct roles: profile, feed, recap, leaderboard, and athlete naming are all unambiguous. The only real boundary issue is log_activity versus snapshot, which both log sessions and return cards, though snapshot's explicit preference for Claude Code work helps clarify the split.
The set mixes verb_noun names like log_activity, set_athlete, get_profile, and list_activities with bare nouns like snapshot, recap, and leaderboard, so there is no consistent pattern. All names are readable and lowercase, but the convention is not uniform enough to be considered mostly consistent.
Seven tools is well-scoped for a niche gamified activity tracker, and each tool covers a distinct part of logging, viewing, summarizing, and comparing activities. No tool feels redundant, and the count is appropriate for the server's purpose.
The core lifecycle is covered: log_activity and snapshot create activities, list_activities reads the feed, and profile, recap, and leaderboard provide aggregation and comparison. Minor gaps like no delete or update activity endpoint and no single-activity detail view are workable but not severe.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Turn Claude or ChatGPT into a cycling coach that plans your week, grades it, and adapts. Free beta.
Agent-first strength-training platform across iOS, Web & MCP: read & write workouts, PRs & plans.
Strava MCP tools for AI: athletes, activities, segments, clubs, routes. Powered by HAPI MCP server.
Garmin data in Claude: 135 tools — activities, sleep, HRV, training, workouts. Free, open source.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/lukisimi/agentrava'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
