Skip to main content
Glama
brilliantdirectories

brilliant-directories-mcp

Official

createMembershipPlan

Launch a new membership tier by creating a subscription plan. Set pricing, visibility, and billing for paid, free, or claim profiles.

Instructions

Create a membership plan - Create a new membershipplan record. Writes live data.

Use when: launching a new plan tier. Rare - usually configured in BD admin UI. Check profile_type carefully: paid, free, or claim - changing later affects billing and visibility.

Required: subscription_name, profile_type.

Pre-check before create: BD does NOT enforce uniqueness on subscription_name. Duplicate plan names confuse admins at signup-form configuration, billing reports, and member migration. Do a server-side filter-find: listMembershipPlans property=subscription_name property_value=<proposed> property_operator==. Zero rows = name free; >=1 row = taken. Do NOT paginate unfiltered lists - filtered lookup is one tiny response. If taken: reuse via updateMembershipPlan, OR ask the user, OR pick an alternate subscription_name and re-check. Never silently create a duplicate.

Enums: payment_default: yearly, monthly.

Parameter interactions:

  • subscription_type - typically member for standard member plans

  • profile_type: paid, free, or claim - controls how profile visibility and billing work

  • monthly_amount / yearly_amount - price in the site's currency

  • sub_active=1 makes the plan available for new signups; sub_active=0 grandfathers existing members only

  • searchable=1 makes members on this plan findable in public search

See also: updateMembershipPlan (modify existing).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
subscription_nameYes
subscription_typeNoInternal role identifier - distinct from `profile_type`. Default `"member"` (applied when omitted). Valid values NOT publicly documented by BD. **Omit on create** unless BD staff or admin UI gave you an authoritative value. For plan monetization model (paid/free/claim-listing) use `profile_type`, NOT this field.member
profile_typeYesPlan monetization model. Documented values: `paid`, `free`, `claim`. **BD does NOT validate server-side** — values outside this set are stored verbatim with undefined render behavior (live observed: `"individual"` accepted on prior writes). Stick to documented values.
monthly_amountNo
yearly_amountNo
sub_activeNoPlan availability for NEW signups: - `1` = active (plan appears on public signup pages; new members can join) - `0` = inactive (plan hidden from new-signup flows; existing members on this plan keep it — grandfather behavior) Use this to retire a plan cleanly. Do NOT hack the signup widget markup to hide a plan.
searchableNoWhether members on this plan appear in public member search results. `1`=visible in search, `0`=hidden. Use this to hide a membership tier from public listings without deactivating billing.
search_priorityNoSearch-result display priority (integer). **Lower number = higher in results.** NOT a 0/1 boolean - numeric value determines ordering. - `0` = highest priority (top of public search results) - `1`, `2`, `3`, ... = progressively lower Use `0` for featured/premium tiers that must appear first. Higher numbers for standard/budget tiers. No upper bound.
payment_defaultNo
subscription_filenameNoOptional URL slug for this plan's public page. Must be site-wide unique — duplicates cause URL routing conflicts. Pre-check with 5 filtered `list*` calls (each `property_value=<proposed>&property_operator==`): `listMembershipPlans`+`subscription_filename`, `listTopCategories`+`filename`, `listSubCategories`+`filename`, `listWebPages`+`filename`, `listUsers`+`filename`. Any hit = taken. Safe to leave blank.
custom_checkout_urlNoOptional custom checkout URL for this plan. Stored in `users_meta` (`database=subscription_types`, `key=custom_checkout_url`); BD auto-routes extra non-direct-column fields to users_meta on create. Must be unique across plans. Pre-check: `listUserMeta(database="subscription_types", key="custom_checkout_url")` then client-filter for any row whose `value` matches yours. Any hit = taken. Safe to leave blank.
Behavior5/5

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

Discloses behavioral traits beyond annotations: 'Writes live data', no server-side uniqueness enforcement, no validation on `profile_type`, and explains `sub_active` grandfather behavior. 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.

Conciseness4/5

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

Well-structured with sections and front-loaded purpose, but slightly verbose; every sentence adds value, though could be marginally tightened.

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 11 parameters and no output schema, the description covers purpose, prerequisites, pre-checks, parameter interactions, and alternatives comprehensively, leaving little ambiguity for an AI agent.

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

Parameters5/5

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

Adds significant meaning beyond input schema: explains `subscription_type` usage, `profile_type` monetization model, pre-checks for `subscription_name`, `subscription_filename`, `custom_checkout_url`, and clarifies `search_priority` ordering. Schema coverage is 64%, and description compensates thoroughly.

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 action ('Create a membership plan') and resource ('membershipplan record'), and distinguishes from sibling tool 'updateMembershipPlan' via 'See also:'.

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 ('launching a new plan tier'), states it's rare, gives a detailed pre-check procedure, and warns against duplicate creation, directing to 'updateMembershipPlan' as alternative.

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

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/brilliantdirectories/brilliant-directories-mcp'

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