Skip to main content
Glama
rkirkendall

Medplum MCP Server

by rkirkendall

createPractitioner

Add a new medical practitioner to the Medplum MCP Server by providing the required given name and family name.

Instructions

Creates a new medical practitioner. Requires given name and family name.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
familyNameYesThe practitioner's family (last) name.
givenNameYesThe practitioner's given (first) name.

Implementation Reference

  • The handler function that implements the core logic for creating a FHIR Practitioner resource using Medplum client. Handles input validation, backward compatibility for field names, constructs the resource, and calls createResource.
    export async function createPractitioner(args: CreatePractitionerArgs): Promise<Practitioner> {
      await ensureAuthenticated();
    
      // Handle backward compatibility
      let family = args.family;
      let given = args.given;
      
      if (args.familyName && !family) {
        family = args.familyName;
      }
      if (args.givenName && (!given || given.length === 0)) {
        given = [args.givenName];
      }
    
      if (!family) {
        throw new Error('Family name is required to create a practitioner.');
      }
      if (!given || given.length === 0) {
        throw new Error('At least one given name is required to create a practitioner.');
      }
    
      const practitionerResource: Practitioner = {
        resourceType: 'Practitioner',
        name: [{
          family: family,
          given: given,
        }],
        active: true,
      };
    
      // Handle identifier (now an array)
      if (args.identifier && args.identifier.length > 0) {
        practitionerResource.identifier = args.identifier;
      }
    
      // Handle telecom directly if provided
      if (args.telecom && args.telecom.length > 0) {
        practitionerResource.telecom = args.telecom;
      }
    
      // Handle other fields
      if (args.gender) {
        practitionerResource.gender = args.gender;
      }
      if (args.birthDate) {
        practitionerResource.birthDate = args.birthDate;
      }
      if (args.qualification) {
        practitionerResource.qualification = [{ code: { text: args.qualification } }];
      }
    
      // Allow setting active status on create
      if (typeof args.active === 'boolean') {
        practitionerResource.active = args.active;
      } else {
        practitionerResource.active = true; // Default to true if not specified
      }
    
      return medplum.createResource<Practitioner>(practitionerResource);
    }
  • TypeScript interface defining the input arguments for the createPractitioner handler, including optional fields for FHIR Practitioner properties and backward compatibility.
    export interface CreatePractitionerArgs {
      family?: string;
      given?: string[]; 
      gender?: 'male' | 'female' | 'other' | 'unknown';
      birthDate?: string;
      // phone?: string; // Deprecate in favor of telecom array
      // email?: string; // Deprecate in favor of telecom array
      telecom?: ContactPoint[]; // Added for FHIR alignment and test compatibility
      qualification?: string;
      identifier?: Identifier[];
      active?: boolean; // Allow setting active status on create
      // Backward compatibility fields
      givenName?: string;
      familyName?: string;
    }
  • MCP protocol input schema for the createPractitioner tool, defining required givenName and familyName parameters.
    {
      name: "createPractitioner",
      description: "Creates a new medical practitioner. Requires given name and family name.",
      inputSchema: {
        type: "object",
        properties: {
          givenName: {
            type: "string",
            description: "The practitioner's given (first) name.",
          },
          familyName: {
            type: "string",
            description: "The practitioner's family (last) name.",
          },
        },
        required: ["givenName", "familyName"],
      },
    },
  • src/index.ts:950-988 (registration)
    Maps the tool name 'createPractitioner' to its handler function for execution in the MCP callTool request handler.
    const toolMapping: Record<string, (...args: any[]) => Promise<any>> = {
      createPatient,
      getPatientById, 
      updatePatient,
      searchPatients,
      searchPractitionersByName,
      createPractitioner,
      getPractitionerById,
      updatePractitioner,
      searchPractitioners,
      createOrganization,
      getOrganizationById,
      updateOrganization,
      searchOrganizations,
      createEncounter,
      getEncounterById,
      updateEncounter,
      searchEncounters,
      createObservation,
      getObservationById,
      updateObservation,
      searchObservations,
      createMedicationRequest,
      getMedicationRequestById,
      updateMedicationRequest,
      searchMedicationRequests,
      createMedication,
      getMedicationById,
      searchMedications,
      createEpisodeOfCare,
      getEpisodeOfCareById,
      updateEpisodeOfCare,
      searchEpisodesOfCare,
      createCondition,
      getConditionById,
      updateCondition,
      searchConditions,
      generalFhirSearch,
    };
  • src/index.ts:14-19 (registration)
    Imports the createPractitioner handler from practitionerUtils.ts for use in the MCP server.
      searchPractitionersByName,
      createPractitioner,
      getPractitionerById,
      updatePractitioner,
      searchPractitioners,
    } from './tools/practitionerUtils.js';
Behavior2/5

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

With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states 'Creates' (implying a write operation) and mentions required parameters, but lacks details on permissions, side effects, error handling, or response format. This is inadequate for a mutation tool with zero annotation coverage.

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

Conciseness4/5

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

The description is brief and front-loaded with the core purpose. Both sentences are relevant, though it could be more structured (e.g., separating purpose from requirements). There's no unnecessary verbiage, making it efficient.

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

Completeness2/5

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

For a creation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens upon success (e.g., returns a practitioner ID), error conditions, or system constraints. Given the complexity of creating a medical practitioner, more context is needed.

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 description mentions 'Requires given name and family name,' which aligns with the two required parameters in the schema. Since schema description coverage is 100%, the baseline is 3, and the description adds no additional semantic context beyond what the schema already provides.

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

Purpose4/5

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

The description clearly states the action ('Creates') and resource ('new medical practitioner'), making the purpose immediately understandable. It distinguishes from sibling tools by specifying the practitioner resource type, though it doesn't explicitly contrast with other 'create' tools like createPatient or createOrganization.

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

Usage Guidelines2/5

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 alternatives. It doesn't mention prerequisites (like authentication), differentiate from similar creation tools (e.g., createPatient), or indicate when not to use it (e.g., for updating existing practitioners).

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

Install Server

Other Tools

Related Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/rkirkendall/medplum-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server