RationalBloks

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: poll the returned job_id with get_job_status. 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 (a decimal with a smaller scale or turned integer, a datetime turned date): deploy_destructive ap…

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 monitor progress. Deployment typically takes 2-5 minutes depending on schema complexity. If deployment fails, read the job's error first: one that starts with 'RationalBloks platform error' is the platform's, not the schema's. Otherwise check: (1) Schema format is FLAT (no 'fields' nesting), (2) Ev…

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 that cannot be applied (a table or field that is not there, a schema the deploy would refuse, such as a field another reads) refuses them all, naming it, and nothing is saved. The answer carries 'applied', 'diff', 'plan' and the new 'version'. WORKFLOW: 1. preview_schema_change with the same ope…

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 call again. While RationalBloks is being updated, the call is refused with 'RationalBloks is being updated': call it again in a few minutes.

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 "quantum" searches name, description, summary, notes, and all other string fields. Returns nodes with _match_fields showing which properties matched. Optionally filter by entity_type to narrow results.

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 creating nodes/relationships to know what entity_type and rel_type values are valid.

Get a specific node by its entity_id from a deployed graph project. Returns all node properties including created_at and updated_at timestamps.

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.

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 deployed one: saved_schema_deployed is true when the last deploy applied it, false when it was saved after the last deploy (undeployed_changes then lists what deploying it would change), and null when no deployed schema is on record.

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 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 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, cardinality, data_schema), and hierarchical entity nesting. Available templates: Start from Scratch (hierarchy, flat labels, every field type), Social Network (people, organizations, content, follows), Knowledge Graph (topic hierarchy, articles, authors, concepts), Product Catalog (products, categories, supp…

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.

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 about three minutes, and a deploy can take up to 15 minutes. A module job names its module_code, and a completed module build's result names the image it built (its commit). If status is 'failed', read failure_side and error: 'customer' means the project's input is proven the cause (an invalid schem…

Get all relationships connected to a specific node. Supports direction filtering (incoming, outgoing, both) and relationship type filtering.

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. RETURNS THE LIVE API URL: staging.url and production.url carry…

Get object-storage usage for a project: file count and bytes used against the plan limits.

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}}}. The response also says whether this saved schema is the deployed one: saved_schema_deployed is true when t…

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

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 is safe — it replaces creator-ownership per table and fails closed on a null link), computed columns (read-only values derived from other columns), __constraints__ (composite uniqueness, checked at commit when deferrable), __audit__ (append-only audit log), __admin_write__ (a table only admins write)…

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: Start from Scratch (every field type), Team Collaboration (workspaces, channels, messages, tasks), E-Commerce Store (customer profiles, products, orders and their line items, reviews, shipments). Each entry's 'schema' goes to create_project as is or adapted; its…

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 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 pool is a UI action (create a bare Ubuntu box, authorise the key we generate, then we provision it into a cluster automatically) — this tool only lists pools you already registered, it never handles cluster credentials.

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).

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>:<short sha>-<build time>), replicas (live pods: 0 when frozen, null while the pool is not reporting), CPU and memory, and env_var_names (the names of its environment variables, never their values).

List a project's uploaded files (metadata + public URLs), most recent first. Inspection only — files are not streamed through MCP.

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 no longer have its job_id (after an interruption, or in a later session): the first job of the job_type you want is the latest. Read older jobs a page at a time with offset; a page shorter than limit is the last.

List all your RationalBloks projects with their status and URLs

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 the column keeps its data. OPERATIONS (each one small object, applied in the order given): • {"op": "add_table", "table": "clocks", "definition": {...}} new table, same FLAT rules as create_project • {"op": "rename_table", "table": "clocks", "to": "timers"} • {"op": "add_field", "table": "ass…

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) ANSWER: 'applied' (for operations), 'diff' (every property saving it would change, by path), 'summary' and 'plan' (the migration the next deploy would then run, every table, field, entity or relationship it drops named), and 'version' (the saved schema's: pass it as expected_version to the save that fo…

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 with get_job_status, whose result names the image built (its commit); list_modules shows it once done. 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 b…

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 last deploy did not apply (deploy_staging deploys those) or when nothing was deployed yet; a save that lands meanwhile is refused rather than deployed. deploy_production rebuilds production the same way when staging runs what production runs. The operation is ASYNCHRONOUS: poll the returned job_id wi…

Rename a project (changes display name, not project_code)

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 schema. 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_job_status, then call again. While RationalBloks is being updated, the call is refused with 'RationalBloks is being updated': call it again in a few …

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. 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_job_status, then call again. While RationalBloks is being updated, the call is refused with 'RationalBlok…

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 'RationalBloks is being updated': call it again in a few minutes.

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": "~physics"} Without entity_type, searches ALL node types.

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 name the variables only. DESTRUCTIVE: a value replaced or removed cannot be read back. CORS_ORIGINS, DEPLOY_* and GITHUB_TOKEN are the platform's. The operation is a job: poll the returned job_id with get_job_status. One operation runs on a module at a time, and none beside an operation on its project:…

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 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 'RationalBloks is being updated': call it again in a few minutes.

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", traverse outgoing relationships up to 3 hops deep: start_entity_type: "person" start_entity_id: "alan-turing-001" max_depth: 3 direction: "outgoing" Supports filtering by relationship types and direction.

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 is being updated, the call is refused with 'RationalBloks is being updated': call it again in a few minutes.

Update properties of an existing node in a deployed graph project. Only send the fields you want to change — unspecified fields remain unchanged.

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 "description" and "schema" with field definitions • Each field is {"type": "...", "required": true/false} — required defaults to false • Relationships need "from", "to", and "cardinality" • Field types: string, integer, float, boolean, date, json • Relationship types should be UPPER_SNAKE_CASE • Entity nam…

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 again. While RationalBloks is being updated, the call is refused with 'RationalBloks is being updated': call it again in a few minutes.

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 change one field risks changing something else on the way. ⚠️ Follow ALL rules from create_project: • FLAT format (no 'fields' nesting) • string: max_length (default 255) • decimal: precision + scale (default 10, 2) • Use "datetime" NOT "timestamp" • DON'T define: id, created_at, updated_at, row_vers…