Skip to main content
Glama
chrischall

simplepractice-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

simplepractice_request_sign_in_link

Request a passwordless sign-in link emailed to a client's portal address. Confirm to trigger the email and access SimplePractice data without a password.

Instructions

Ask SimplePractice to email a sign-in link to a Client Portal address. The portal has no password — this is how you sign in. Sends a real email and is rate-limited per email address AND per IP, so it requires confirm:true. A success does not prove the address has an account: the API answers identically for unknown addresses by design.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
emailYesThe email address the Client Portal is registered to.
confirmNoMust be true to proceed. Without this, the tool returns a preview.
practiceNoThe practice whose portal to sign in to — the slug ("achievebalancetherapy"), the host, or the portal URL. Only needed when this server does not know the practice yet; signing in with an emailed link teaches it, and it then remembers.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.4.2
    • changedInput schema / properties / email / pattern
      Previous value: -"^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"New value: +"^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"
  2. Changed1 schema field changedv0.3.0
    • addedInput schema / properties / practice
      Added value: +{
+  "description": "The practice whose portal to sign in to — the slug (\"achievebalancetherapy\"), the host, or the portal URL. Only needed when this server does not know the practice yet; signing in with an emailed link teaches it, and it then remembers.",
+  "minLength": 1,
+  "type": "string"
+}
  3. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only indicate readOnlyHint=false and idempotentHint=false, but the description goes beyond by disclosing side effects: it sends a real email, is rate-limited per email and IP, requires confirm:true, and importantly, that a success does not confirm account existence. This is critical behavioral transparency given the API's identical response for unknown addresses. No contradiction with annotations.

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 concise (three sentences) with each sentence carrying unique value: explaining the sign-in mechanism, the side effects and requirements, and the critical caveat about unknown addresses. It is front-loaded with the core action and then essential conditions.

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's moderate complexity (3 parameters, no output schema, but significant behavioral side effects), the description fully covers what an agent needs: the action, the necessary confirm flag, the practice parameter's purpose, and the critical caveat about success not meaning account existence. The lack of an output schema is acceptable as the description implies a preview behavior and email sending.

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

Parameters3/5

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

The schema provides 100% coverage for all three parameters, each with detailed descriptions. The description adds context on the confirm parameter (must be true) and the practice parameter (optional, when the server is unaware), which is useful but not fully compensating for missing nuances like email format validation already in schema. Since schema coverage is high, baseline 3 is appropriate.

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's purpose: to request an email sign-in link for the Client Portalched, with a specific verb ('email'), resource ('sign-in link'), and the distinctive aspect that the portal has no password. It distinguishes itself from siblings like simplepractice_verify_sign_in_token by focusing on the initiation of the link, not verification.

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

Usage Guidelines5/5

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

Provides explicit when-to-use guidance: 'this is how you sign in' and explains the necessary confirm:true requirement for real email sending. It also clues the agent into the rate-limiting and confirmation necessity, which is critical for correct invocation, and indirectly signals when not to use it (e.g., when a sign-in token or PIN verification is needed).

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

Deploy Server

Other Tools