# Noemic (remote · noemic.app)

Someone to talk to, for your user: coaches, mentors, accountability partners. First session free.

- Trust score: 67/100 (medium)
- Change this week: +4
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-03

## Components

- remote · `noemic.app`: 67/100 (this document), [markdown](https://verifymcp.io/servers/app-noemic-noemic/noemic.md), [page](https://verifymcp.io/servers/app-noemic-noemic/noemic)

## Channel facts

- Endpoint: `https://noemic.app/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `0.1.0`

## 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-08-03.

- **Endpoint Security**: 57/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation not fully verified: no authorisation is required to call this server, and 47 tool(s) never declared a destructiveHint. The MCP spec treats an absent hint as destructive by default, so we cannot call this surface safe.
  - 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.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 82/100
  - 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 6132 tokens (~122/item across 50 items; 47 tools + 3 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 27/100
  - Stability observed for 8 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 85/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 54% of tool parameters carry a description.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.
  - Supports UI / widget rendering.

## Install

### Claude

```bash
claude mcp add --transport http app-noemic-noemic https://noemic.app/mcp
```

### Codex

```toml
[mcp_servers.app-noemic-noemic]
url = "https://noemic.app/mcp"
```

### opencode

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

### OpenClaw

```bash
openclaw mcp add app-noemic-noemic --url https://noemic.app/mcp --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  app-noemic-noemic:
    url: "https://noemic.app/mcp"
```

### Other

```json
{
  "mcpServers": {
    "app-noemic-noemic": {
      "type": "http",
      "url": "https://noemic.app/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-08-03 (score 67, +1)

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

### 2026-08-01 (score 66, +1)

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

### 2026-07-31 (score 65, 0)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-30 (score 65, 0)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-29 (score 65, +1)

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

### 2026-07-28 (score 64, +1)

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

### 2026-07-27 (score 63, 0)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-26 (score 63)

First indexed and scored.

## MCP tools (47)

### `get_started` (~56 tokens)

Orient a first-time user

Call this FIRST when a user has just connected or is unsure what Noemic is. The embedded panel presents marketplace context but has no action buttons. Present the four paths through Claude's native tappable choices; do not repeat the panel information.

### `begin_sign_in` (~63 tokens)

Open secure Noemic sign-in

Call only when the user is ready for an identity-bearing action. Returns a secure noemic.app URL where they log in or create an account and approve this conversation. Show only signInUrl; keep requestId and pollSecret private. Never ask for credentials in chat.

### `finish_sign_in` (~67 tokens)

Finish secure Noemic sign-in

After the user chooses 'I've signed in', exchange the private requestId and pollSecret from begin_sign_in. Pending means they have not approved yet; complete returns the private sessionToken. Never expose either secret.

Input parameters:

- `pollSecret` (string, required)
- `requestId` (string, required)

### `logout` (~65 tokens)

End a session

Invalidate a sessionToken (e.g. on a shared device). After this the token no longer works and you must login again.

Input parameters:

- `sessionToken` (string, required): The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user.

### `match_me` (~81 tokens)

Find people for a need (server pre-ranker)

PRIVATE fallback pre-ranker when list_people is too large for context. Returns at most three candidates as working material and NEVER renders a panel. Read silently, then call show_people with 1-3 selected IDs. Do not narrate ranking or results.

Input parameters:

- `limit` (integer)
- `need` (string, required): Plain-language description of what the user needs

### `list_people` (~172 tokens)

Read candidates privately

PRIMARY PRIVATE DISCOVERY: first decide which formal factual constraints follow from the user's request, pass only those filters, then read every returned story and corpus silently. This tool NEVER renders to the user. Select 1-3 people and call show_people with the same filters. Never narrate the scan, count, filtering, or rejected profiles.

Input parameters:

- `availableNow` (boolean): Only people bookable this minute via book_now
- `freeFirstSession` (boolean): Only people who do (true) / don't (false) offer a free first session
- `hasOpeningWithinDays` (integer): Only people with an open slot (or live presence) within N days
- `maxHourlyRateDollars` (number): Highest acceptable hourly rate in US dollars (e.g. 25 or 12.5)

### `show_people` (~88 tokens)

Show a clean shortlist

THE ONLY user-visible shortlist. After silently reading list_people or match_me, pass 1-3 selected profile IDs plus the formal filters you actually applied. The panel displays one person at a time with local name selectors. Then render one Claude-native choice per person and one escape choice; no prose comparison or duplicate profile text.

Input parameters:

- `filters` (object)
- `profileIds` (array, required)

### `get_person` (~30 tokens)

Get one person

Full profile (story + corpus) for one person by profile id.

Input parameters:

- `profileId` (string, required)

### `get_availability` (~34 tokens)

Get open session slots

Open (unbooked, future) slots for a person, soonest first.

Input parameters:

- `profileId` (string, required)

### `book_session` (~107 tokens)

Book a session

Book an open slot with a person. Pricing is automatic: first-ever session on the platform is free; otherwise an available session credit auto-redeems; otherwise the pro's self-set rate is charged. The result states what was paid — tell the user.

Input parameters:

- `profileId` (string, required)
- `sessionToken` (string, required): The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user.
- `slotId` (string, required)

### `book_now` (~113 tokens)

Start a session right now

Instant session with someone whose availableNow is true: the booking starts immediately and the result carries the roomUrl — send the user straight in. Same pricing as book_session (free first session where offered, then credits, then the prorated rate — state the price first). Default 30 minutes.

Input parameters:

- `minutes` (integer)
- `profileId` (string, required)
- `sessionToken` (string, required): The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user.

### `set_available_now` (~166 tokens)

Set the pro's instant-session status

Pro-side presence has TWO parts: this controllable status (open/closed) AND recent activity — a pro shows as available-now only while their status is open AND they've been active in the last 15 minutes (their dashboard heartbeats while open; calling this tool also counts as activity). So: open it when the pro is genuinely at their desk, and if they stay only agent-side, re-call it within every 15 minutes to stay live. Available-now pros rank higher for urgent needs and are bookable via book_now.

Input parameters:

- `open` (boolean, required): true = open to instant sessions right now; false = closed
- `sessionToken` (string, required): The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user.

### `complete_session` (~81 tokens)

Mark a session completed

Call after a session actually happened. The PRO earns a session credit they can spend as a client (the loop that keeps Noemic alive) and their quality record grows.

Input parameters:

- `bookingId` (string, required)
- `sessionToken` (string, required): The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user.

### `cancel_booking` (~69 tokens)

Cancel a booking

Cancel a confirmed booking: any charge is refunded, a redeemed credit is returned, and the slot reopens.

Input parameters:

- `bookingId` (string, required)
- `sessionToken` (string, required): The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user.

### `my_bookings` (~52 tokens)

The user's bookings

Bookings as client and as pro, soonest first.

Input parameters:

- `sessionToken` (string, required): The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user.

### `become_available` (~327 tokens)

Put the user on the marketplace

Create the user's profile so others can book them. Draft everything from your conversation — their words, their experiences, what they'd be good at being in someone's corner for — and confirm with them before calling. No credentials needed, no review queue: the only qualification is being human. Rate is self-set (0 or omitted = free/credits-only; they earn a credit per session they run either way). Include availability if they told you when they're free.

Input parameters:

- `availability` (array): Initial open slots; endsAt defaults to one hour after startsAt
- `corpus` (string): Everything else worth knowing, unbounded — written for agents to read. Details, specifics, boundaries, availability quirks.
- `createdVia` (string): Use in_session_commit when this profile was born from a commitment made during a session/conversation
- `displayName` (string, required)
- `headline` (string, required): One line in their voice — specific and human, never a job title or category
- `hourlyRateDollars` (number): Self-set hourly rate in US dollars (e.g. 25 or 12.5)
- `publish` (boolean): Default false = PREVIEW ONLY (nothing created; returns the rendered profile + quality notes). Set true only after the user approved the preview.
- `sessionToken` (string, required): The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user.
- `story` (string, required): Their narrative, first person: who they are, what they've lived, why someone would want them in their corner

### `my_profile` (~85 tokens)

The user's own status on Noemic

Status probe: does the user have a profile, what's missing to make it bookable, plus credits, upcoming sessions, and active commitments at a glance. Call this before assuming anything about the user's state — cheaper than asking them.

Input parameters:

- `sessionToken` (string, required): The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user.

### `add_availability` (~66 tokens)

Add open slots

Add open session slots to the user's profile. endsAt defaults to one hour after startsAt.

Input parameters:

- `sessionToken` (string, required): The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user.
- `slots` (array, required)

### `add_to_my_corpus` (~95 tokens)

Append to the user's corpus

Append text to the user's agent-readable corpus (with their consent). Anything that would help future matching: new experiences, what a session with them is like, boundaries, wins from sessions they ran. Append-only and date-stamped.

Input parameters:

- `sessionToken` (string, required): The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user.
- `text` (string, required)

### `update_my_profile` (~121 tokens)

Update the user's profile

Update display name, headline, story, rate, or listing/visibility flags.

Input parameters:

- `displayName` (string)
- `headline` (string)
- `hourlyRateDollars` (number): New hourly rate in US dollars (e.g. 25 or 12.5)
- `isListed` (boolean)
- `offersSessions` (boolean)
- `sessionToken` (string, required): The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user.
- `story` (string)

### `create_commitment` (~215 tokens)

Put money on a commitment

The user stakes real money on doing a specific thing by a deadline. Succeed → refunded; fail → forfeited. Make the title concrete and checkable ('run 3x this week', not 'exercise more'). Follow up with the user before the deadline. Server-enforced cap: at most $500 of active stakes per user; the result reports remaining headroom.

Input parameters:

- `deadline` (string, required): Deadline as ISO 8601 with timezone offset, e.g. 2026-07-15T18:00:00-07:00
- `details` (string)
- `sessionToken` (string, required): The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user.
- `stakeDollars` (number, required): Stake in US dollars (e.g. 25 or 12.5)
- `title` (string, required)
- `witnessConnectionId` (string): Stake it in front of their person: the connection whose other side sees this commitment

### `resolve_commitment` (~91 tokens)

Resolve a commitment

Resolve an active commitment: succeeded → stake refunded; failed → stake forfeited. Self-report — ask the user directly and record their answer honestly.

Input parameters:

- `commitmentId` (string, required)
- `note` (string)
- `sessionToken` (string, required): The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user.
- `succeeded` (boolean, required)

### `my_commitments` (~59 tokens)

The user's commitments

All commitments with status and deadlines (active first). Check for approaching deadlines worth nudging about.

Input parameters:

- `sessionToken` (string, required): The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user.

### `session_transcript` (~126 tokens)

Read a session's transcript

The consent-gated transcript of a session in the platform room. Participants only. During a LIVE session, poll with sinceMs set to the atMs of the last segment you saw (only newer segments return). Use it to supervise: understand where the conversation is, then send_cue when one would help.

Input parameters:

- `bookingId` (string, required)
- `sessionToken` (string, required): The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user.
- `sinceMs` (integer): Only return segments after this atMs offset

### `send_cue` (~126 tokens)

Whisper a cue to the pro mid-session

Pro-only, during a live session. The cue appears quietly in the pro's room panel — the client never sees it. Discipline: ONE short cue (max 25 words), specific to what was actually said — a question worth asking, a dropped thread, a reminder to listen, a concrete next step. Silence is fine; never send generic advice.

Input parameters:

- `bookingId` (string, required)
- `sessionToken` (string, required): The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user.
- `text` (string, required)

### `write_debrief` (~151 tokens)

Write the pro's post-session debrief

Pro-only, after a session. Read the full transcript first (session_transcript), then write honestly and specifically, referencing actual moments: strengths = 2-3 things that worked; growth = the single most important thing to do differently and where it mattered; drill = one concrete exercise before the next session. One debrief per session; it feeds the pro's quality record and their my_coaching history.

Input parameters:

- `bookingId` (string, required)
- `drill` (string, required)
- `growth` (string, required)
- `sessionToken` (string, required): The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user.
- `strengths` (string, required)

### `session_debrief` (~98 tokens)

The AI debrief for a session the user ran

After a session ends, the pro gets a private AI debrief (what worked, what to change, a drill to practice). Pro-only: the email must be the session's pro. Use it to help your user prepare for their next session.

Input parameters:

- `bookingId` (string, required)
- `sessionToken` (string, required): The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user.

### `my_coaching` (~86 tokens)

The user's coaching development record

All AI debriefs from sessions the user ran as the pro, newest first — their private improvement record. Read it before their next session and coach them on the recurring growth themes. This is how someone new gets good fast.

Input parameters:

- `sessionToken` (string, required): The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user.

### `file_brief` (~127 tokens)

File what the user needs

The demand side is a filed document, not a search: privately write a few real sentences (situation, what kind of person would help, desired cadence) and let it stand anonymously, converging as people join. Never paste or read the draft back to the user. Returns today's candidates as private working material; select up to three and call show_people. Check my_briefs on later visits.

Input parameters:

- `need` (string, required)
- `sessionToken` (string, required): The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user.

### `my_briefs` (~71 tokens)

The user's briefs, freshly matched

All briefs with matching re-run against today's marketplace plus any intros received. Call when your user returns — new people may have joined since the brief was filed.

Input parameters:

- `sessionToken` (string, required): The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user.

### `open_briefs` (~59 tokens)

What people are waiting for

Open briefs, anonymous (the need, never the person). For the supply side: show a pro what demand exists, or a hesitant would-be pro that people are already waiting for someone like them. Reach toward one with send_intro(briefId).

### `close_brief` (~61 tokens)

Close a brief

Close an open brief (found someone, or the need passed).

Input parameters:

- `briefId` (string, required)
- `sessionToken` (string, required): The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user.

### `send_intro` (~128 tokens)

Reach toward someone

Send a short real intro through the platform (no emails exposed). Two directions: profileId — your user reaching toward a person whose story fits; briefId — your user (who has a profile) reaching toward an open need. Acceptance creates a connection.

Input parameters:

- `briefId` (string)
- `message` (string, required): A couple of sentences in the user's voice — why this person, why now
- `profileId` (string)
- `sessionToken` (string, required): The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user.

### `my_intros` (~52 tokens)

Intros waiting for the user's answer

Pending intros addressed to the user. Respond with respond_intro.

Input parameters:

- `sessionToken` (string, required): The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user.

### `respond_intro` (~96 tokens)

Accept or decline an intro

Accepting creates the CONNECTION — the standing relationship where messages, sessions, artifacts, and witnessed commitments live. If your user is the client side, immediately port_context so their person knows exactly what is going on.

Input parameters:

- `accept` (boolean, required)
- `introId` (string, required)
- `sessionToken` (string, required): The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user.

### `port_context` (~126 tokens)

Port the context into a connection

Client-side only, with the user's consent: write the full situation into the connection — what is going on, history, what has been tried, what they want — so their person starts knowing everything. Replaces the intake interview. Update it as things evolve; the pro and their agent read it.

Input parameters:

- `connectionId` (string, required)
- `context` (string, required): The situation, in full — written for their person to read
- `sessionToken` (string, required): The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user.

### `my_connections` (~63 tokens)

The user's standing relationships

Every connection: who, context brief, last message, active witnessed commitments. The relationships you are responsible for keeping alive.

Input parameters:

- `sessionToken` (string, required): The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user.

### `send_message` (~79 tokens)

Send a message in a connection

Async relay between the two people (agents deliver both ways). The daily two-line check-in lives here — cadence beats duration.

Input parameters:

- `connectionId` (string, required)
- `sessionToken` (string, required): The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user.
- `text` (string, required)

### `check_messages` (~68 tokens)

Unread messages across all connections

The heartbeat: call whenever your user shows up. Returns unread messages from all their connections (marked delivered). Relay them in the person's own words.

Input parameters:

- `sessionToken` (string, required): The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user.

### `create_artifact` (~149 tokens)

Design an exercise

Pro-side: design an interactive exercise ONCE (thought record, weekly review, values check — see coaching_playbook topic artifact_patterns). The script is instructions a client's agent follows to run it conversationally. Public artifacts join the shared library.

Input parameters:

- `description` (string, required): What it is for and when to assign it
- `isPublic` (boolean): Default true — public artifacts join the shared library
- `script` (string, required): Facilitator instructions the client's agent follows, ending with what to post back
- `sessionToken` (string, required): The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user.
- `title` (string, required)

### `artifact_library` (~59 tokens)

The shared exercise library

Public artifacts from all pros, ranked by real adoption. Search in plain language ('procrastination', 'reframing', 'weekly accountability'). Assign any of them — assigning from the library is how good exercises spread.

Input parameters:

- `search` (string)

### `my_artifacts` (~50 tokens)

The pro's own artifacts

Artifacts this pro designed, with adoption counts.

Input parameters:

- `sessionToken` (string, required): The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user.

### `assign_artifact` (~115 tokens)

Assign an exercise into a connection

Pro-side: assign an artifact (yours or from the library) to a client, with an optional note. Best moment: as a session lands, one artifact at a time. The client's agent administers it and the result comes back into the connection.

Input parameters:

- `artifactId` (string, required)
- `connectionId` (string, required)
- `note` (string)
- `sessionToken` (string, required): The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user.

### `my_assignments` (~76 tokens)

Exercises waiting for the user

Client-side: pending exercises assigned by the user's people. Run each script conversationally at a good moment — you are the facilitator — then complete_assignment with the substance of what emerged.

Input parameters:

- `sessionToken` (string, required): The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user.

### `complete_assignment` (~86 tokens)

Post an exercise result back

After administering an assigned exercise: post back what the script asked for. The result lands in the connection where their person (and their person's agent) sees it.

Input parameters:

- `assignmentId` (string, required)
- `result` (string, required)
- `sessionToken` (string, required): The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user.

### `coaching_playbook` (~76 tokens)

Evidence-based coaching practice

The curriculum you coach your pro with: active_listening, powerful_questions, cbt_basics, motivational_interviewing, accountability_structures, session_structure, boundaries_and_referral, artifact_patterns. No topic returns the index. Ground your cues, debriefs, and artifact designs in this.

Input parameters:

- `topic` (string)

### `my_credits` (~62 tokens)

The user's session credits

Unredeemed session credits (earned by running sessions). They auto-redeem on the next paid booking.

Input parameters:

- `sessionToken` (string, required): The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user.

## Diagnostics

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

## Score history

- 2026-08-03: 67
- 2026-08-02: 66
- 2026-08-01: 66
- 2026-07-31: 65
- 2026-07-30: 65
- 2026-07-29: 65
- 2026-07-28: 64
- 2026-07-27: 63
- 2026-07-26: 63

## Links

- Remote endpoint: https://noemic.app/mcp
- Repository: https://github.com/MorganFisher2007/Noemic
- Website: https://noemic.app/
- Changelog RSS feed: https://verifymcp.io/servers/app-noemic-noemic/noemic/changelog.xml
- Changelog JSON feed: https://verifymcp.io/servers/app-noemic-noemic/noemic/changelog.json
- HTML version of this page: https://verifymcp.io/servers/app-noemic-noemic/noemic