Claude Prompt Guide MCP

How to draw an ERD by talking to Claude over MCP. Copy the examples below as they are, or adapt them.

You need a working MCP connection first. See the MCP setup guide for how to connect. Once connected, try asking Claude Code "is the yourerd MCP connected?".

Creating entities

A single entity

"Create a user entity"

A User entity is created with a default id (PK) column.

"Create a User entity with the logical name 'Member'."

An entity with physical name User and logical name Member is created.

Several entities at once

"Create User, Order and Product entities"

All three are created, each with a default PK.

"Create every entity an online store ERD needs — User, Product, Order, OrderItem, Delivery and Category"

Six entities are created in order.

Renaming an entity

"Rename the User entity to Member"

"Change the Order entity's logical name to 'Order details'"

Adding / editing columns

Adding basic columns

"Add username, email and password columns to the User entity"

Three VARCHAR columns are added.

"Add name (VARCHAR 200), price (DECIMAL), stock (INT) and created_at (DATETIME) columns to the Product entity"

The columns are added with the types and sizes you gave.

Including logical names

"Add these columns to the User entity:
- username (User name) VARCHAR(50)
- email (Email) VARCHAR(200) UNIQUE
- phone (Mobile number) VARCHAR(20)
- created_at (Signed up at) DATETIME"

Specifying constraints

"Add status (Order status) VARCHAR(20) NOT NULL and ordered_at (Ordered at) DATETIME NOT NULL to the Order entity"

"Change the price column on Product to DECIMAL(12,2) and make it NOT NULL"

Setting the PK

"Rename the User entity's id column to user_id and keep it as the PK"

⚠️ Do not delete PK columns. Deleting a PK that a relationship references as an FK leaves the FK column dangling. To replace a PK, delete the relationship first, change the PK, then recreate the relationship.

Relationships

1:N non-identifying (the most common)

"Connect User and Order as 1:N — one user can have many orders"

A user_id FK is generated automatically on the Order entity.

"Connect Category and Product as a 1:N non-identifying relationship"

1:N identifying (the child includes the parent PK)

"Connect Order and OrderItem as a 1:N identifying relationship — an OrderItem cannot exist without its Order"

OrderItem's FK (order_id) becomes part of its composite PK.

1:1 relationships

"Connect User and UserProfile as 1:1"

"Connect Order and Payment as a 1:1 identifying relationship — a payment cannot exist without an order"

Several relationships at once

"Set up these relationships:
- User → Order (1:N non-identifying)
- Order → OrderItem (1:N identifying)
- Product → OrderItem (1:N non-identifying)"

Changing a relationship type

"Make the User-Order relationship identifying"

"Change the Order-OrderItem relationship to non-identifying"

Identifying vs non-identifying — how to choose:
• Identifying: the child record is meaningless without its parent (order items, payment history, …)
• Non-identifying: the child can also stand on its own (post-author, product-category, …)

Deleting

"Delete the Address entity"

The entity is removed along with any FK columns referencing it.

"Remove the User-Address relationship"

The relationship and its auto-generated FK column are removed.

"Delete the description column from the Product entity"

Scenario — online store ERD

Ask for the whole thing up front and Claude designs the entire structure.

"Build an online store ERD with this structure:

Entities:
- User (Member): id, username(User name), email(Email), phone(Mobile), created_at(Signed up at)
- Product: id, name(Product name), price(Price) DECIMAL, stock(Stock) INT, category_id FK
- Category: id, name(Category name), parent_id(Parent category)
- Order: id, user_id FK, status(Order status), total(Total amount) DECIMAL, ordered_at(Ordered at)
- OrderItem: order_id FK+PK, product_id FK+PK, qty(Quantity) INT, price(Unit price) DECIMAL
- Delivery: id, order_id FK, address(Shipping address), status(Delivery status), shipped_at(Shipped at)

Relationships:
- Category → Product (1:N non-identifying)
- User → Order (1:N non-identifying)
- Order → OrderItem (1:N identifying)
- Product → OrderItem (1:N non-identifying)
- Order → Delivery (1:1)"

Building it step by step

Step 1 — the skeleton

"Create User, Product, Order and OrderItem entities"

Step 2 — fill in columns

"Add email, password and created_at columns to User"

"Add name, price (DECIMAL) and stock (INT) to Product"

Step 3 — connect them

"Set up User→Order as 1:N and Order→OrderItem as 1:N identifying"

Step 4 — ask for a review

"List the entities and the relationship structure in the current diagram"

"Tell me if any columns are missing or if there are normalization problems"

Scenario — blog / community

"Build a blog ERD:

- User: id, nickname(Nickname), email(Email), created_at(Signed up at)
- Post: id, user_id FK, title(Title), content(Body) TEXT, published_at(Published at)
- Comment: id, post_id FK, user_id FK, content(Body), created_at(Written at)
- Tag: id, name(Tag name) UNIQUE
- PostTag: post_id FK+PK, tag_id FK+PK

Relationships:
- User → Post (1:N non-identifying)
- Post → Comment (1:N identifying)
- User → Comment (1:N non-identifying)
- Post → PostTag (1:N identifying)
- Tag → PostTag (1:N non-identifying)"

Expressing N:M relationships: YourERD does not support N:M directly. Create a junction entity (PostTag, OrderItem, …) and connect it with two 1:N relationships. If you tell Claude "connect Post and Tag as N:M", it creates the junction table for you.

Scenario — HR / org management

"Build an HR management ERD:

- Department: id, name(Department name), manager_id(Department head) FK nullable
- Employee: id, dept_id FK, name(Name), email(Email), hire_date(Hire date), salary(Salary) DECIMAL
- Position: id, name(Position name), level(Level) INT
- EmployeePosition (position history): id, emp_id FK, pos_id FK, assigned_at(Assigned at), ended_at(Ended at) nullable

Relationships:
- Department → Employee (1:N non-identifying)
- Employee → Department (1:1 non-identifying, manager_id — separate from the self reference)
- Position → EmployeePosition (1:N non-identifying)
- Employee → EmployeePosition (1:N non-identifying)"

Scenario — recursion / hierarchies

YourERD supports recursive relationships that connect an entity to itself.

Simple recursion (parent-child)

"Create a Category entity and give it a 1:N non-identifying recursive relationship to itself — a parent-category / child-category hierarchy"

A parent_id FK is added to Category and a self-referencing loop is drawn.

"Add a manager self-reference to the Employee entity — one employee can have several reports"

"Add a parent_comment_id self-reference to the Comment entity so it supports threaded replies (optional participation, nullable)"

Unbounded hierarchies (nested paths)

"Build a folder hierarchy ERD:
- Folder: id, name(Folder name), owner_id FK, parent_id(Parent folder) self-referencing FK nullable
- File: id, folder_id FK, name(File name), size(Size) BIGINT, created_at

Relationships: User → Folder (1:N), Folder → Folder (1:N recursive), Folder → File (1:N)"

Writing effective prompts

✅ What works well

Give both the physical name and the logical name

State the data type (VARCHAR, INT, DECIMAL…)

Be explicit about direction and kind ("1:N non-identifying")

Bundle several steps into one request

Explain the domain ("cannot exist without an order")

⚠️ Watch out for

Split N:M into a junction entity

Never delete an FK/PK column directly

Delete the relationship before renaming a PK

Ask explicitly: "save this diagram"

Checking the current state

"What entities are in the diagram right now?"

"Show me the columns on the User entity"

"Which entities are related to Order?"

Asking it to save

"Save what we've done to the database"

"Save it as a new diagram called 'Store v2'"

Listing and switching diagrams

"Show me my diagrams"

"Open the 'Blog ERD' diagram"

Data type cheat sheet

Use these names when you tell Claude a type and it will map them exactly.

Type	Use for	How to say it to Claude
`INT`	Integers (counts, quantities, indexes)	"INT", "integer", "a whole number"
`BIGINT`	Large integers (file sizes, timestamps)	"BIGINT", "a big number"
`VARCHAR(n)`	Variable-length strings	"VARCHAR(100)", "a string up to 100 characters"
`CHAR(n)`	Fixed length (codes, phone numbers)	"CHAR(10)", "exactly 10 characters"
`TEXT`	Long text (body copy, descriptions)	"TEXT", "a long string", "body"
`DECIMAL(p,s)`	Exact decimals (money, rates)	"DECIMAL(12,2)", "an amount", "a price"
`FLOAT`	Floating point (coordinates, statistics)	"FLOAT", "a real number"
`DATETIME`	Date and time	"DATETIME", "a timestamp"
`DATE`	Date only	"DATE", "a date"
`BOOLEAN`	True / false	"BOOLEAN", "bool", "true/false"
`UUID`	Unique identifiers (stored as CHAR(36))	"UUID"
`JSON`	Unstructured data	"JSON", "metadata"