All servers · Build & deploy · Code & repositories

RationalBloks

io.github.rationalbloks/rationalbloks-mcp · v0.6.1

Measured by MCP Station

Description written by the publisher, not verified

Deploy production REST APIs from JSON schemas in seconds. Manage projects, schemas, and deployments.

Connect

claude mcp add --transport http rationalbloks-mcp https://mcp.rationalbloks.com/mcp

{
  "mcpServers": {
    "rationalbloks-mcp": {
      "url": "https://mcp.rationalbloks.com/mcp"
    }
  }
}

Tools as reported by the server

• list_projects
  List all your RationalBloks projects with their status and URLs
• get_project
  Get detailed information about a specific project
• get_schema
  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 fo
• get_user_info
  Get information about the authenticated user
• list_clusters
  List your registered BYOC resource pools (client-owned Kubernetes clusters). Each returned cluster has an 'id' you MUST pass as create_project's cluster_id to deploy a project onto your own infrastructure — owned hosting is retired, so every project we operate runs on your own cluster. Registering a
• get_job_status
  Check the status of a job (a create, deploy, promotion, rollback, deletion or module operation). STATUS VALUES: pending (queued), processing (in progress), completed (success), failed. Call it until the status is completed or failed: every job ends, since a job whose server stopped is failed within
• list_project_jobs
  List a project's jobs, newest first: every create, deploy, promotion, rollback, resource change and module operation, each with its status, error, failure_side and when it started and ended. A job's record is kept for the life of the project, so this is how to find out what an operation did when you
• get_project_info
  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 schem
• get_version_history
  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.
• get_template_schemas
  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 n
• get_schema_reference
  Get the reference for ADVANCED schema features the templates do not show — read this before adding authorization or derived fields to a schema. Covers: __policy__ (relationship-based read/write authorization with single- and multi-hop membership paths, and the rules that decide whether adopting it i
• get_subscription_status
  Get your subscription tier, limits, and usage
• get_project_usage
  Get resource usage metrics (CPU, memory) for a project
• get_project_storage_usage
  Get object-storage usage for a project: file count and bytes used against the plan limits.
• list_project_files
  List a project's uploaded files (metadata + public URLs), most recent first. Inspection only — files are not streamed through MCP.
• get_schema_at_version
  Get the schema as it was at a specific version/commit
• preview_schema_change
  Preview a schema change, saving nothing: the one way to see what a change would do before it is saved. Pass ONE of: • operations: the operations patch_schema or drop_schema_items would apply (relational projects) • schema: a whole schema in place of the saved one (relational or graph projects) ANSWE
• create_project
  Create a new RationalBloks project (a PostgreSQL REST API) from a JSON schema, on one of your resource pools. ⚠️ CRITICAL RULES - READ BEFORE CREATING SCHEMA: 1. FLAT FORMAT (REQUIRED): ✅ CORRECT: {"orders": {"total": {"type": "decimal", "precision": 10, "scale": 2}}} ❌ WRONG: {"orders": {"fields":
• update_schema write/delete
  Replace a project's WHOLE schema (saves to database, does NOT deploy). DESTRUCTIVE: a table or field the schema leaves out is dropped by the next deploy. For a new data model or a template. To change part of a schema use patch_schema, and drop_schema_items to drop; sending back a large schema to cha
• patch_schema
  Change PART of a project's schema without dropping any of it (saves to database, does NOT deploy). Send only the change. The server applies it to the saved schema, in order and all together, and keeps every table and field it does not touch — including their identity, so a rename stays a rename and
• drop_schema_items write/delete
  Drop tables or fields from a project's saved schema (saves to database, does NOT deploy). DESTRUCTIVE: the next deploy drops their data. OPERATIONS (applied in order and all together): • {"op": "drop_table", "table": "clocks"} • {"op": "drop_field", "table": "parameters", "field": "is_clock"} A drop
• deploy_staging
  Deploy a project's saved schema 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
• deploy_production
  Promote staging to production (requires a paid plan): production's database migrates from the schema it runs to the one staging runs, and production runs staging's build. With staging unchanged since the last promotion, it rebuilds production with no schema change. The operation is ASYNCHRONOUS: pol
• deploy_destructive write/delete
  Deploy a plan that drops data, of a relational or a graph project. DESTRUCTIVE: the tables, fields, entities or relationships the plan drops lose their data. environment 'staging' deploys the saved schema, 'production' promotes staging. Use it only after a deploy tool (deploy_staging, deploy_product
• redeploy_project
  Rebuild and roll out a project's staging environment from the schema it runs, with NO schema change, for a relational or a graph project: the current platform release, the project's settings (email, admin users) and its environment take effect. Refused (409) when the saved schema holds changes the l
• delete_project write/delete
  Delete a project (removes GitHub repo, K8s deployments, and database). It runs as a job: poll the returned job_id with get_job_status until it is completed. One operation runs on a project at a time: while another runs, the call is refused and the refusal names the running job; wait for it with get_
• rollback_project write/delete
  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. Rollbac
• rename_project
  Rename a project (changes display name, not project_code)
• get_graph_schema
  Get the graph schema definition of a project. Returns the hierarchical schema with nodes (entities) and relationships. Graph schemas define entity hierarchies and typed relationships — a different format than relational flat-table schemas. The response also says whether this saved schema is the depl
• get_graph_template_schemas
  Get pre-built graph template schemas for common use cases. ⭐ USE THIS FIRST when creating a new graph project! Templates show the CORRECT graph schema format with: proper node definitions (description, flat_labels, schema with flat field definitions), relationship configurations (from, to, cardinali
• get_graph_version_history
  Get the deployment and version history for a graph project. Shows all schema changes with commit SHAs, timestamps, version numbers, and messages. Use this to find a specific version for rollback operations.
• get_graph_schema_at_version
  Get the graph schema as it existed at a specific version/commit. Use get_graph_version_history to find commit SHAs. Useful for comparing schemas across versions or auditing changes.
• get_graph_project_info
  Get detailed graph project information including Kubernetes deployment status, Neo4j database health, pod status, and resource usage. Use this after deployment to verify the graph project is running correctly.
• create_graph_project
  Create a new Neo4j graph database project from a hierarchical JSON schema. ⚠️ GRAPH SCHEMA FORMAT — READ BEFORE CREATING: Graph schemas define nodes (entities) and relationships, NOT flat database tables. Each field is a dict with "type" and optional "required": true (defaults to false). SCHEMA STRU
• update_graph_schema write/delete
  Replace a graph project's WHOLE schema (saves to database, does NOT deploy). DESTRUCTIVE: an entity, relationship or field the schema leaves out is deleted by the next deploy. ⚠️ Follow ALL rules from create_graph_project: • Must have "nodes" key with at least one entity • Each entity needs "descrip
• deploy_graph_staging
  Deploy a graph project's saved schema to the staging environment. This triggers: (1) Schema validation, (2) Neo4j entity code generation, (3) Docker image build, (4) GitHub commit, (5) Kubernetes deployment with Neo4j instance. The operation is ASYNCHRONOUS — returns immediately with a job_id. Use g
• deploy_graph_production
  Promote graph staging to production. Creates a separate production Neo4j instance with its own credentials and database. Requires paid plan. A plan that drops data is refused, naming every table, field, entity or relationship it would drop, and every field whose type change rounds or cuts its values
• delete_graph_project write/delete
  Delete a graph project (removes GitHub repo, K8s deployments, Neo4j database, and credentials). It runs as a job: poll the returned job_id with get_job_status until it is completed. One operation runs on a project at a time: while another runs, the call is refused and the refusal names the running j
• rollback_graph_project write/delete
  Rollback a graph project to a previous version. ⚠️ WARNING: This reverts schema AND code to the specified commit. Neo4j data is NOT rolled back. Use get_graph_version_history to find the commit SHA of the version you want to rollback to. After rollback, the graph API will be redeployed with the old
• create_graph_node
  Create a single node in a deployed graph project. REQUIRES: Project must be deployed (use deploy_graph_staging first). The entity_type must match an entity key from the project schema. Use get_graph_data_schema to see available entity types and their fields. Example: entity_type: "person" entity_id:
• get_graph_node
  Get a specific node by its entity_id from a deployed graph project. Returns all node properties including created_at and updated_at timestamps.
• list_graph_nodes
  List nodes of a specific entity type from a deployed graph project. Supports pagination with limit/offset. Returns nodes ordered by creation date (newest first).
• update_graph_node
  Update properties of an existing node in a deployed graph project. Only send the fields you want to change — unspecified fields remain unchanged.
• delete_graph_node write/delete
  Delete a node and all its relationships from a deployed graph project. ⚠️ This also removes all relationships connected to this node (DETACH DELETE).
• create_graph_relationship
  Create a relationship between two nodes in a deployed graph project. The rel_type must match a relationship key from the project schema. Use get_graph_data_schema to see available relationship types. Example: rel_type: "authored" from_id: "alan-turing-001" to_id: "on-computable-numbers-001" data: {"
• get_node_relationships
  Get all relationships connected to a specific node. Supports direction filtering (incoming, outgoing, both) and relationship type filtering.
• delete_graph_relationship write/delete
  Delete a specific relationship by its internal ID. Use get_node_relationships to find relationship IDs.
• bulk_create_graph_nodes
  Create multiple nodes at once (up to 500 per call). Uses Neo4j UNWIND for high performance. Essential for knowledge graph population — create hundreds of entities from a single book chapter or article. Each node needs: entity_id (unique string) and data (properties dict). Example: entity_type: "conc
• bulk_create_graph_relationships
  Create multiple relationships at once (up to 500 per call). Uses Neo4j UNWIND for high performance. Essential for connecting knowledge — link hundreds of concepts, people, and events in one operation. Each relationship needs: from_id, to_id, and optional data (properties). Example: rel_type: "relate
• search_graph_nodes
  Search for nodes by property values in a deployed graph project. Supports exact match and contains search (prefix value with ~ for contains). Examples: Exact: filters: {"name": "Alan Turing"} Contains: filters: {"name": "~turing"} (case-insensitive) Combined: entity_type: "person", filters: {"field"
• fulltext_search_graph
  Search across ALL string properties of ALL nodes in a deployed graph using free-text queries. Unlike search_graph_nodes (which filters by specific property), this searches every text field at once. Perfect for finding knowledge when you don't know which property contains the answer. Example: query "
• traverse_graph
  Walk the graph from a starting node, discovering connected knowledge. Returns all nodes reachable within max_depth hops, with their distance from the start. Essential for exploring knowledge graphs — find related concepts, trace connections, discover clusters. Example: Start from "Alan Turing", trav
• get_graph_statistics
  Get statistics about a deployed graph: total node count, total relationship count, counts per entity type, counts per relationship type. Essential for understanding the current state of a knowledge graph before adding more data.
• get_graph_data_schema
  Get the runtime schema of a DEPLOYED graph project — shows the actual entity types and relationship types available for data operations. Returns: Available entity keys (for create_graph_node, list_graph_nodes, etc.) and relationship keys (for create_graph_relationship, etc.). ⭐ USE THIS FIRST before
• list_modules
  List a project's modules and what each runs: module_id (what every module tool takes), name, type (frontblok or logicblok), repository, url, staging_status (not_deployed, deploying, deployed, failed), deployed_at, image (the image of its last successful build, named by the commit it built: <name>:<s
• deploy_module
  Deploy a new module from a GitHub repository onto the project's resource pool: a frontblok module is a Vite frontend, a logicblok module a backend built from its Dockerfile that serves port 8000 with GET /health. Its job clones the repository (the default branch head, or git_ref), builds it and serv
• redeploy_module
  Rebuild a module from its repository's default branch head and roll it out, keeping its pod count. Its data and settings are untouched; the project's API (staging and production) and its backend modules restart to take the module's CORS origin. The operation is ASYNCHRONOUS: poll the returned job_id
• update_module
  Rename a module, or point it at another GitHub repository, which its next redeploy builds. Pass module_name, github_repo_url or both. One operation runs on a module at a time, and none beside an operation on its project: the refusal names the running job; wait for it with get_job_status, then call a
• delete_module write/delete
  Remove a module: its pods stop and it leaves the project and its CORS origins. DESTRUCTIVE. One operation runs on a module at a time, and none beside an operation on its project: the refusal names the running job; wait for it with get_job_status, then call again. While RationalBloks is being updated
• set_module_env write/delete
  Set a module's environment variables: {NAME: value} sets one, {NAME: null} removes one, and every variable not named is kept. A backend module restarts to take them; a frontend module rebuilds (they are build arguments). Values are stored encrypted and never returned: the answer and list_modules nam
• freeze_module
  Stop a module's pods (scale to 0), remembering how many it ran; unfreeze_module starts them again. Freezing a frozen module changes nothing. One operation runs on a module at a time, and none beside an operation on its project: the refusal names the running job; wait for it with get_job_status, then
• unfreeze_module
  Start a frozen module's pods again, as many as it ran before the freeze. A running module is left as it is. One operation runs on a module at a time, and none beside an operation on its project: the refusal names the running job; wait for it with get_job_status, then call again. While RationalBloks
• scale_module
  Run 1 or 2 pods of a module (freeze_module stops it). One operation runs on a module at a time, and none beside an operation on its project: the refusal names the running job; wait for it with get_job_status, then call again. While RationalBloks is being updated, the call is refused with 'RationalBl
• set_module_resources
  Set a module's CPU and memory and rebuild it so its pods take them. The allocation is checked against the resource pool's capacity first; a refused one is restored. The operation is ASYNCHRONOUS: poll the returned job_id with get_job_status. One operation runs on a module at a time, and none beside

Repository · JSON · Text for agents · Registry updated 2026-10-08