createMemberSubCategoryLink

Link a service to a user - Create a new Member ↔ Sub Category link with optional metadata. Writes live data.

Links an existing member (user_id) to an existing Sub Category (service_id) with per-link metadata (pricing, specialty). This is the richer alternative to setting users_data.services CSV via updateUser - use this when you need per-link data.

Use when: the simpler users_data.services CSV isn't rich enough - you need per-link avg_price, specialty=1, or num_completed. For plain "tag this member with this sub-cat" use updateUser with services=<service_id> instead.

Required: user_id, service_id.

Pre-check before create (PAIR uniqueness): BD does NOT enforce uniqueness on the (user_id, service_id) pair in rel_services. Linking the same member to the same Sub Category twice produces two rel_services rows, double-counts the member in that Sub Category's listing widgets, and leaves per-link metadata (specialty/avg_price) ambiguous - which row wins? Filter-find pattern (single-field server filter + client-side intersect - the server does not yet honor array-syntax multi-condition filters): call listMemberSubCategoryLinks property=user_id property_value=<proposed user_id> property_operator== to narrow to all rel_services rows for that member, then CLIENT-SIDE filter to rows where service_id=<proposed service_id>. Zero results after client-side step = link free; >=1 = already linked. If the link already exists: update it via updateMemberSubCategoryLink (e.g. to set specialty=1 or avg_price), OR skip the create (idempotent). Never silently double-link the same member to the same Sub Category.

Parameter guidance:

• user_id - member (from listUsers / searchUsers)

• service_id - Sub Category (from listSubCategories)

• avg_price - decimal, the member's price for this service

• specialty - 0 or 1 flags this Sub Category as a specialty offering on the member's profile

• num_completed - counter of jobs/projects completed in this Sub Category

• date - YYYYMMDDHHmmss timestamp

See also: updateUser with services="<csv>" (simpler, no per-link metadata), listSubCategories, getMemberSubCategoryLink.

Writes live data: appears on the member's public profile immediately.

Returns: { status: "success", message: {...createdRecord} } with rel_id.

How a member gets classified on their public profile:

• users_data.profession_id -> points at a single Top Category (the member's primary classification; shown in URL slug)

• users_data.services -> CSV of Sub Category IDs the member is tagged with (multiple allowed; simpler than the join table)

• rel_services rows (Member ↔ Sub Category links) -> used when you need per-link metadata like avg_price, specialty, num_completed. Optional; most sites use just the CSV field.

Sub-sub-categories: createSubCategory with master_id=<parent service_id> creates a Sub Category nested under another Sub Category (a "sub-sub"). master_id=0 (default) means the Sub Category sits directly under a Top Category (the profession_id).

There is NO createProfession or createService tool in this MCP — those are BD's internal table names. Use createTopCategory / createSubCategory instead (BD's table-name → tool-name mapping is documented in Rule: Table to endpoint).