Back to Browse

Heart Api MCP Server

by Kit G
Developer ToolsLow Risk10.0MCP RegistryRemote
Free

Server data from the Official MCP Registry

Your Heart workout log: workouts, records, templates, programs. Holds no health data.

About

Your Heart workout log: workouts, records, templates, programs. Holds no health data.

Remote endpoints: streamable-http: https://mcp.heart-of.me

Security Report

10.0
Low Risk10.0Low Risk

Valid MCP server (1 strong, 0 medium validity signals). No known CVEs in dependencies. Imported from the Official MCP Registry.

Endpoint verified · Requires authentication · 1 issue found

Security scores are indicators to help you make informed decisions, not guarantees. Always review permissions before connecting any MCP server.

Permissions Found in Source Code

Found by scanning the linked source code. This listing connects to a hosted endpoint, so none of this runs on your machine: it describes what the server software does where it is hosted.

file_system

Applies to the server that hosts this plugin, not to your machine.

HTTP Network Access

Connects to external APIs or services over the internet.

How to Connect

Remote Plugin

No local installation needed. Your AI client connects to the remote endpoint directly.

Add this to your MCP configuration to connect:

{
  "mcpServers": {
    "me-heart-of-heart": {
      "url": "https://mcp.heart-of.me"
    }
  }
}

Documentation

View on GitHub

From the project's GitHub README.

Heart of Yours

Backend for the Heart of Yours fitness app. Dart server on AWS Lambda behind API Gateway, Postgres via Supabase, all CDN/storage on AWS.

Repository layout

heart-go/
├── api/                       # Dart server (Lambda entrypoint)
├── shared/
│   ├── heart_models/          # Data classes + service interfaces (used by api + the Flutter client)
│   └── heart_aws/             # Boto3-shaped AWS clients (S3, SQS, SNS, Scheduler) on aws_signature_v4
├── database/
│   ├── migrations/            # Forward-only SQL migrations
│   ├── tests/                 # pgtap suite — public/{tables,functions}, archive/...
│   └── test_utils/            # Test helpers (builders + JSON validators)
├── firebase/                  # Python Lambda: FCM push + Firebase auth cleanup (uv workspace member)
├── assets/                    # Python Lambda: exercise media processing pipeline (uv workspace member)
├── infrastructure/            # Terraform stacks (api, assets, cdn, content, firebase, monitoring)
│                              # + environments/{dev,prod} — see infrastructure/README.md
├── content/                   # Exercise library YAML + schema + sample templates JSON, synced to CDN
├── scripts/                   # Migration runner, db test runner, library sync/validation
├── site/                      # Static marketing/legal pages
├── docs/                      # Dated design docs; handoff.md is the definition of done, style.md the house style
├── agents/                    # Autonomous agent launchers + guard hook (see agents/README.md)
└── .github/workflows/         # CI: deploy-api, deploy-assets, deploy-firebase, exercise-library
                               # (each split into a reusable workflow + dev/prod wrappers)

Per-component docs:

Stack

LayerTech
Server runtimeDart 3.10 + relic, compiled to native + Lambda Web Adapter
StoragePostgres (Supabase), no ORM — raw SQL
Object storage / CDNS3 + CloudFront
AuthFirebase OIDC token verification
AsyncEventBridge S3-rules → SQS → /events (Lambda routes events back to itself)
Scheduled jobsEventBridge Scheduler → SQS → /events
Side servicesPython 3.13 Lambdas in a uv workspace: firebase/ (push, auth cleanup), assets/ (media)
IaCTerraform (with Supabase provider)
CI/CDGitHub Actions, OIDC role for AWS
TestsDart test + mockito for app code, pgtap for the database, pytest for the Python services

Local development

make bootstrap   # dart pub get + mocks for all packages, uv sync, git hooks
make db-up       # containerized Postgres 17 + pgtap (skip if you run a native one)
make test        # the full matrix: Dart x3, migrations + pgtap, pytest x3
make lint        # dart analyze x3 + ruff

Each suite can also run individually — make test-dart / test-db / test-python, or the underlying commands directly (see the Makefile and per-component READMEs).

The api package can be run locally against any Postgres + AWS profile — see api/README.md.

Deployment

Every workflow family is a reusable workflow plus thin -dev / -prod wrappers. Dev ships from main pushes. Prod: api and exercise-library ship from v* tags; assets and firebase prod deploys are currently manual (workflow_dispatch). Pull requests run the test jobs only — the deploy jobs are gated on the event type.

deploy-api.yml (api/shared/database changes):

  1. Lint, format check, analyze
  2. Dart tests across all three packages
  3. Database tests: ephemeral Postgres + pgtap via scripts/db_tests.sh, then the full api suite (including db-tagged integration tests) with a coverage floor
  4. Apply unapplied migrations to Supabase
  5. Build Lambda binary, update function, smoke-test /version

deploy-firebase.yml / deploy-assets.yml (Python changes): pytest, then package and update the function code.

exercise-library.yml (content changes): validate the library YAML against its JSON schema plus the sync parser, then sync exercises + translations to Postgres (guarded against mass-archiving).

Conventions

  • Migrations are forward-only. No down migrations. Wrong schema → write a new migration that fixes it.
  • No comments unless the WHY is non-obvious — naming carries the WHAT.
  • Single source of truth for shapes. Anything the client sees lives in heart_models; server-only types stay in api/lib/models.
  • Boto3-shaped AWS package — generic, no domain knowledge in heart_aws.

Licence

The server and everything else in this repository is under the GNU AGPL v3.0. The shared packages (shared/heart_models, shared/heart_aws, shared/heart_design) are under the Apache License 2.0, and the exercise library and other content in content/ under CC BY 4.0. The name and logo aren't covered by any of them. NOTICE has the full map, including what in the repository isn't ours. The reasons are in docs/2026-10-24.licence.md.

Contributing

Contributions come in under the licence of the directory they change (inbound = outbound): AGPL for the server, Apache-2.0 for the shared packages, CC BY 4.0 for content/. Opening a pull request means you agree to that and that the work is yours to give. There is no CLA.

Reviews

No reviews yet

Be the first to review this server!