Skip to main content
Glama
nries1

tend-mcp

by nries1
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

tend-mcp

An unofficial MCP (Model Context Protocol) server for Tend dental — not affiliated with, endorsed by, or supported by Tend. It talks to internal API endpoints their own web app calls, discovered via browser devtools, not a published/documented API. Expect it to break without notice if Tend changes their frontend.

Use at your own risk. This has not been reviewed against Tend's Terms of Service — read them yourself before running this, and be ready to stop if Tend objects. Each instance authenticates as one Tend account and only ever accesses that account's own data; it is not designed or intended to access any other patient's records.

Status

Real, verified against a live HAR capture (2026-08-01) of an actual login → pick studio → pick service → pick time → book flow, plus live-tested auth: list_studios, list_service_types (static reference data — see below), list_appointments, search_available_slots, book_appointment (confirmed live — the capture includes a real booking that got a real Dentrix external_id).

Auth is fully real now — two ways in. Tend authenticates via AWS Cognito behind their own thin proxy at identity.hellotend.com. You can use either:

  • TEND_PASSWORD — real email+password login (POST identity.hellotend.com/login, confirmed live), the same call the actual web app makes. No Cognito SRP dance needed client-side; Tend's backend handles that.

  • TEND_REFRESH_TOKEN — skips login, obtained by hand once from DevTools (see below).

Either way, TendClient keeps itself signed in automatically: sessions renew via Cognito's REFRESH_TOKEN_AUTH (Authorization: Bearer <idToken>, ~24h tokens — confirmed live), falling back to a fresh password login if a refresh token expires/gets revoked and TEND_PASSWORD is set.

Related MCP server: MotionMCP

Setup

npm install
cp .env.example .env   # fill in TEND_EMAIL and (TEND_PASSWORD or TEND_REFRESH_TOKEN)
npm run dev             # or: npm run build && npm start

Point an MCP client (Claude Desktop, etc.) at it by adding to its MCP config, e.g. Claude Desktop's claude_desktop_config.json:

{
  "mcpServers": {
    "tend": {
      "command": "node",
      "args": ["/absolute/path/to/tend-mcp/dist/index.js"],
      "env": { "TEND_EMAIL": "you@example.com", "TEND_PASSWORD": "..." }
    }
  }
}

Getting a refresh token (if not using TEND_PASSWORD)

  1. Log into hellotend.com in Chrome.

  2. Open DevTools → Application → Cookies → hellotend.com.

  3. Copy the value of the refreshToken cookie into TEND_REFRESH_TOKEN.

Both TEND_PASSWORD and TEND_REFRESH_TOKEN are standing credentials — treat them like a password, not an API key. A refresh token in particular can mint fresh sessions for a long time without re-entering anything. Never commit either, never paste either anywhere it might get logged — including into an AI chat. This isn't hypothetical: building this integration involved two real accidental exposures of live tokens into a chat session (once from a raw cookie paste, once from an incomplete redaction script missing token as a sensitive field name) — HAR "sanitization" and ad-hoc redaction scripts are not something to rely on. If you ever suspect either has leaked, log out of Tend everywhere / rotate your password.

Adding another endpoint

Log into hellotend.com, open DevTools → Network → Fetch/XHR, perform the action, and note the request. Then add a method to TendClient following the existing ones' shape (raw snake_case API fields mapped to a camelCase TS interface) and a corresponding tool in tools.ts.

If you export a HAR to work from: response bodies (not just headers) still contain real PII — redact personal fields (name, email, phone, insurance, DOB) out of them before sharing, and never share cookie/token values regardless of what the export tool does or doesn't strip automatically. .gitignore here already excludes *.har so it won't land in git.

Design constraints (please keep these)

  • One account per instance. No multi-tenant credential store, no server-side proxy holding multiple users' logins.

  • No anti-bot evasion. If Tend's login has MFA or bot-detection, surface it to the user (or fail loudly) rather than trying to automate around it.

  • No endpoints beyond what a real patient portal already exposes to that patient. Don't add anything that reaches into other patients' data.

  • STUDIOS/SERVICE_TYPES in tendClient.ts are a frozen snapshot, not live data. No stable API for them was found (see the comment above STUDIOS) — they'll silently go stale as Tend adds/closes studios or changes services. Worth periodically re-checking against a fresh capture rather than assuming they're current.

Available Tools

2 tools
book_appointmentBook a Tend appointmentA

Book an available appointment slot. Requires a slotId — look one up via a slot-search tool once one exists (not yet implemented).

ParametersJSON Schema
NameRequiredDescriptionDefault
slotIdYesThe slot ID to book, from an availability search.

TDQS

A3.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full responsibility for behavioral disclosure. It notes the dependency on a not-yet-implemented slot-search tool, but omits details such as whether booking is irreversible, requires authentication, or what happens on success/failure. This is insufficient for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no wasted words. The first sentence front-loads the main action, and the second provides a necessary prerequisite and caveat, maintaining optimal conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple single-parameter mutation tool with no annotations and no output schema, the description covers purpose and parameter source but lacks information about return values, error behavior, and post-conditions. It is adequate for basic selection but has notable gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a clear description of slotId. The tool description adds meaning by specifying that the slotId must be obtained from a slot-search tool and that this tool is not yet implemented, providing helpful context about the parameter's origin and current limitation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Book' and resource 'appointment slot', clearly distinguishing it from the sibling 'list_appointments'. It also states the key prerequisite (slotId), making the tool's purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the tool requires a slotId to be looked up via a slot-search tool, which sets clear context for when to use it. However, it does not explicitly mention exclusions like 'do not use for listing' or alternative tools, though the sibling's name implies the difference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_appointmentsList Tend appointmentsA

List the authenticated patient's upcoming Tend appointments.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of behavioral disclosure. It indicates a read-only list operation via 'List' and specifies the scope ('authenticated patient's upcoming'), which is sufficient for this simple tool. It does not mention pagination or ordering, but these are not critical for basic understanding.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that front-loads the verb 'List' and delivers all necessary information without any fluff. It is perfectly sized for the tool's simplicity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters, no output schema, and a clear sibling distinction, the description fully defines the tool's purpose and expected output. It states exactly which appointments are listed (upcoming, authenticated patient's), making it complete for its simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, and the schema coverage is 100% (empty schema). Per the rubric, 0 parameters sets a baseline of 4, and the description adds nothing about parameters because none exist.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists upcoming Tend appointments for the authenticated patient. The verb 'List' and resource 'appointments' are specific, and the scope is well-defined. It also naturally distinguishes from the sibling 'book_appointment' which performs a different action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for viewing upcoming appointments, which is clear context. However, it does not explicitly exclude alternative tools or state when not to use it, though the sibling 'book_appointment' is obviously a different operation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv0.1.0
    • First observedbook_appointment
    • First observedlist_appointments
Deploy Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: one lists appointments and the other books them. There is no overlap or ambiguity between them.

Naming Consistency5/5

Both tools follow a consistent verb_noun pattern (list_appointments, book_appointment). This is a clean, predictable naming convention.

Tool Count3/5

With only two tools, the server feels minimal for an appointment management context. However, it is not extremely over or under-scoped, so it lands in the borderline category.

Completeness1/5

The server is severely incomplete: booking requires a slot-search tool that does not exist, and there are no cancel, get, or update operations. This will cause agent failures.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers