RationalBloks

Create a new RationalBloks project from a JSON schema.

⚠️ CRITICAL RULES - READ BEFORE CREATING SCHEMA:

1. FLAT FORMAT (REQUIRED): ✅ CORRECT: {users: {email: {type: "string", max_length: 255}}} ❌ WRONG: {users: {fields: {email: {type: "string"}}}} DO NOT nest under 'fields' key!

2. FIELD TYPE REQUIREMENTS: • string: MUST have "max_length" (e.g., max_length: 255) • decimal: MUST have "precision" and "scale" (e.g., precision: 10, scale: 2) • datetime: Use "datetime" NOT "timestamp" • ALL fields: MUST have "type" property

3. AUTOMATIC FIELDS (DON'T define): • id (uuid, primary key) • created_at (datetime) • updated_at (datetime)

4. USER AUTHENTICATION: ❌ NEVER create "users", "customers", "employees" tables with email/password ✅ USE built-in app_users table

   Example: { "employee_profiles": { "user_id": {type: "uuid", foreign_key: "app_users.id", required: true}, "department": {type: "string", max_length: 100} } }

5. AUTHORIZATION: Add user_id → app_users.id to enable "only see your own data"

   Example: { "orders": { "user_id": {type: "uuid", foreign_key: "app_users.id"}, "total": {type: "decimal", precision: 10, scale: 2} } }

6. FIELD OPTIONS: • required: true/false • unique: true/false • default: any value • enum: ["val1", "val2"] • foreign_key: "table.id"

AVAILABLE TYPES: string, text, integer, decimal, boolean, uuid, date, datetime, json

WORKFLOW:

1. Use get_template_schemas FIRST to see valid examples

2. Create schema following ALL rules above

3. Call this tool

4. Monitor with get_job_status (2-5 min deployment)

After creation, use get_job_status with returned job_id to monitor deployment.

Delete a project (removes GitHub repo, K8s deployments, and database)

Promote staging to production (requires paid plan)

Deploy a project to the staging environment. This triggers: (1) Schema validation, (2) Docker image build, (3) GitHub commit, (4) Kubernetes deployment, (5) Database migrations. The operation is ASYNCHRONOUS - it returns immediately with a job_id. Use get_job_status with the job_id to monitor progress. Deployment typically takes 2-5 minutes depending on schema complexity. If deployment fails, check: (1) Schema format is FLAT (no 'fields' nesting), (2) Every field has a 'type' property, (3) Foreign keys reference existing tables, (4) No PostgreSQL reserved words in table/field names. Use get_project_info to see if the deployment succeeded.

Check the status of a deployment job. STATUS VALUES: pending (job queued), running (deployment in progress), completed (success), failed (deployment failed). TIMELINE: Typical deployment takes 2-5 minutes. If status is 'running' for >10 minutes, check get_project_info for detailed pod status. If status is 'failed', use get_project_info to see deployment errors and check schema format (must be FLAT, no 'fields' nesting).

Get detailed information about a specific project

Get detailed project info including deployment status and resource usage. DEPLOYMENT STATUS: Running (healthy), Pending (starting), CrashLoopBackOff (init container failed - usually schema format error), ImagePullBackOff (image build failed). TROUBLESHOOTING: If status is CrashLoopBackOff, the schema is likely in wrong format (nested 'fields' key or missing 'type' properties). Use get_schema to review current schema. If replicas show 0/2, the init container (migration runner) is failing. This is almost always a schema format issue.

Get resource usage metrics (CPU, memory) for a project

Get the JSON schema definition of a project in FLAT format. Returns the schema structure where each table name maps directly to field definitions. This is the same format required for create_project and update_schema. USE CASES: Review current schema before making updates, copy schema as template for new projects, verify schema structure after deployment, learn the correct schema format by example. The returned schema will be in FLAT format: {table_name: {field_name: {type, properties}}}

Get the schema as it was at a specific version/commit

Get your subscription tier, limits, and usage

Get pre-built template schemas for common use cases. ⭐ USE THIS FIRST when creating a new project! Templates show the CORRECT schema format with: proper FLAT structure (no 'fields' nesting), every field has a 'type' property, foreign key relationships configured correctly, best practices for field naming and types. Available templates: E-commerce (products, orders, customers), Team collaboration (projects, tasks, users), General purpose templates. You can use these templates directly with create_project or modify them for your needs. TIP: Study these templates to understand the correct schema format before creating custom schemas.

Get information about the authenticated user

Get the deployment and version history (git commits) for a project. Shows all schema changes with commit SHA, timestamp, and message. USE CASES: Review what changed between deployments, find the last working version before issues started, get commit SHA for rollback_project.

List all your RationalBloks projects with their status and URLs

Rename a project (changes display name, not project_code)

Rollback a project to a previous version. ⚠️ WARNING: This reverts schema AND code to the specified commit. Database data is NOT rolled back. Use get_version_history to find the commit SHA of the version you want to rollback to. After rollback, use get_job_status to monitor the redeployment. Rollback is useful when a schema change breaks deployment.

Update a project's schema (saves to database, does NOT deploy).

⚠️ CRITICAL: Follow ALL rules from create_project: • FLAT format (no 'fields' nesting) • string: MUST have max_length • decimal: MUST have precision + scale • Use "datetime" NOT "timestamp" • DON'T define: id, created_at, updated_at • NEVER create users/customers/employees tables (use app_users)

⚠️ MIGRATION RULES: • New fields MUST be "required": false OR have "default" value • Cannot add required field without default to existing tables • Safe: {new_field: {type: "string", max_length: 100, required: false}}

WORKFLOW:

1. Use get_schema to see current schema

2. Modify following ALL rules

3. Call update_schema (saves only)

4. Call deploy_staging to apply changes

5. Monitor with get_job_status

NOTE: This only saves the schema. You MUST call deploy_staging afterwards to apply changes.