diff --git a/website/docs/docs/build/metricflow-commands.md b/website/docs/docs/build/metricflow-commands.md
index 4693aa1a774..af5a54819c0 100644
--- a/website/docs/docs/build/metricflow-commands.md
+++ b/website/docs/docs/build/metricflow-commands.md
@@ -156,8 +156,10 @@ Options:
                       [required]
   --end-time TEXT     Optional iso8601 timestamp to constraint the end time of
                       the data (inclusive)
+                      *Not available in dbt Cloud yet
   --start-time TEXT   Optional iso8601 timestamp to constraint the start time
                       of the data (inclusive)
+                      *Not available in dbt Cloud yet
   --help              Show this message and exit.
 ```
 
@@ -268,10 +270,12 @@ Options:
                            ds, org.
 
   --end-time TEXT          Optional iso8601 timestamp to constraint the end
-                           time of the data (inclusive)
+                           time of the data (inclusive).
+                           *Not available in dbt Cloud yet 
 
   --start-time TEXT        Optional iso8601 timestamp to constraint the start
                            time of the data (inclusive)
+                           *Not available in dbt Cloud yet
 
   --where TEXT             SQL-like where statement provided as a string. For
                            example: --where "revenue > 100". To add a dimension filter to 
@@ -306,7 +310,7 @@ Options:
 
 ### Query examples
 
-The following tabs present various different types of query examples that you can use to query metrics and dimensions. Select the tab that best suits your needs:
+The following tabs present various types of query examples that you can use to query metrics and dimensions. Select the tab that best suits your needs:
 
 <Tabs>
 
@@ -428,11 +432,14 @@ mf query --metrics order_total --group-by metric_time --where "{{ Dimension('ord
 
 To filter by time, there are dedicated start and end time options. Using these options to filter by time allows MetricFlow to further optimize query performance by pushing down the where filter when appropriate. 
 
-**Query**
-```bash
+
+<!--
+bash not support in cloud yet
 # In dbt Cloud
 dbt sl query --metrics order_total --group-by metric_time,is_food_order --limit 10 --order -metric_time --where "is_food_order = True" --start-time '2017-08-22' --end-time '2017-08-27' 
-
+-->
+**Query**
+```bash
 # In dbt Core
 mf query --metrics order_total --group-by metric_time,is_food_order --limit 10 --order -metric_time --where "is_food_order = True" --start-time '2017-08-22' --end-time '2017-08-27' 
 ```
diff --git a/website/docs/reference/dbt-jinja-functions/builtins.md b/website/docs/reference/dbt-jinja-functions/builtins.md
index a5538b27ac8..9f1d139ab20 100644
--- a/website/docs/reference/dbt-jinja-functions/builtins.md
+++ b/website/docs/reference/dbt-jinja-functions/builtins.md
@@ -22,23 +22,27 @@ Using the `builtins` variable in this way is an advanced development workflow. U
 :::
 
 <VersionBlock firstVersion="1.5">
-  
-From dbt v1.5 and higher, use the following macro to extract user-provided arguments, including <code>version</code>, and call the <code>builtins.ref()</code> function with either a single <code>modelname</code> argument or both <code>packagename</code> and <code>modelname</code> arguments, based on the number of positional arguments in <code>varargs</code>:
+
+From dbt v1.5 and higher, use the following macro to override the `ref` method available in the model compilation context to return a [Relation](/reference/dbt-classes#relation) with the database name overriden to `dev`.
+
+It includes logic to extract user-provided arguments, including <code>version</code>, and call the <code>builtins.ref()</code> function with either a single <code>modelname</code> argument or both <code>packagename</code> and <code>modelname</code> arguments, based on the number of positional arguments in <code>varargs</code>.
 
 <br /><br />
 
   
 ```
 {% macro ref() %}
+
 -- extract user-provided positional and keyword arguments
-  {% set version = kwargs.get('version') or kwargs.get('v') %}
-  {% set packagename = none %}
-  {%- if (varargs | length) == 1 -%}
+{% set version = kwargs.get('version') or kwargs.get('v') %}
+{% set packagename = none %}
+{%- if (varargs | length) == 1 -%}
     {% set modelname = varargs[0] %}
 {%- else -%}
     {% set packagename = varargs[0] %}
     {% set modelname = varargs[1] %}
 {% endif %}
+
 -- call builtins.ref based on provided positional arguments
 {% set rel = None %}
 {% if packagename is not none %}
@@ -71,14 +75,10 @@ From dbt v1.4 and lower, use the following macro to override the `ref` method av
 ```
 </VersionBlock>
 
-The ref macro can also be used to control which elements of the model path are rendered when run, for example the following macro overrides the `ref` method to render only the schema and object identifier, but not the database reference i.e. `my_schema.my_model` rather than `my_database.my_schema.my_model`. This is especially useful when using snowflake as a warehouse, if you intend to change the name of the database post-build and wish the references to remain accurate.
+Logic within the ref macro can also be used to control which elements of the model path are rendered when run, for example the following logic renders only the schema and object identifier, but not the database reference i.e. `my_schema.my_model` rather than `my_database.my_schema.my_model`. This is especially useful when using snowflake as a warehouse, if you intend to change the name of the database post-build and wish the references to remain accurate.
 
 ```
--- Macro to override ref and to render identifiers without a database.
 
-{% macro ref(model_name) %}
-
-  {% do return(builtins.ref(model_name).include(database=false)) %}
-
-{% endmacro %}
+  -- render identifiers without a database
+  {% do return(rel.include(database=false)) %}
 ```