robot_lab 0.2.1 → 0.2.7

data/docs/guides/index.md

@@ -42,6 +42,10 @@ If you're new to RobotLab, start here:
 
     Token tracking, circuit breakers, doom loop detection, auto compaction, and learning accumulation
 
+-   [:octicons-zap-24: **Hook System**](hooks.md)
+
+    Lifecycle hooks for instrumentation, response caching, extensions, and cross-cutting concerns
+
 -   [:octicons-search-24: **Knowledge & Retrieval**](knowledge.md)
 
     Chat history search and embedding-based document store for RAG workflows
@@ -59,6 +63,7 @@ If you're new to RobotLab, start here:
 | [Streaming](streaming.md) | Real-time responses | 5 min |
 | [Memory](memory.md) | Shared data store | 5 min |
 | [Observability & Safety](observability.md) | Token tracking, circuit breaker, doom loop detection, auto compaction, learning loop | 10 min |
+| [Hook System](hooks.md) | Lifecycle hooks, extensions, response caching, instrumentation | 15 min |
 | [Knowledge & Retrieval](knowledge.md) | Chat history search and embedding-based document store (RAG) | 10 min |
 
 ## Extension Gems

data/docs/guides/knowledge.md

@@ -21,6 +21,18 @@ results = robot.search_history(query, limit: 5)
 
 Scores every message in the robot's conversation history against `query` using stemmed term-frequency cosine similarity (via the `classifier` gem). Returns up to `limit` `HistoryResult` objects sorted by score descending.
 
+> [!NOTE]
+> **Every** message in `@chat.messages` is scored — there is no role filter.
+> Results routinely include the `:system` prompt and raw `:tool` result payloads
+> (often JSON) alongside `:user` and `:assistant` turns. Filter by role yourself
+> if you only want the conversation:
+>
+> ```ruby
+> hits = robot.search_history(query, limit: 20)
+>            .select { |r| %i[user assistant].include?(r.role) }
+>            .first(3)
+> ```
+
 ```ruby
 results = robot.search_history("quarterly revenue", limit: 3)
 
@@ -35,7 +47,7 @@ end
 | Field | Type | Description |
 |-------|------|-------------|
 | `text` | String | The message text |
-| `role` | Symbol | `:user`, `:assistant`, or `:system` |
+| `role` | Symbol | The message's role — `:user`, `:assistant`, `:system`, or `:tool` |
 | `score` | Float (0.0–1.0) | Cosine similarity with the query |
 | `index` | Integer | Position in `@chat.messages` |
 
@@ -89,7 +101,7 @@ Without it, calling `search_history` raises `RobotLab::DependencyError` with an
 
 ### The Problem
 
-Sometimes the knowledge you need isn't in the conversation history — it's in a README, a product spec, a changelog. `store_document` / `search_documents` embed arbitrary text with `fastembed` and retrieve the most relevant chunk at query time.
+Sometimes the knowledge you need isn't in the conversation history — it's in a README, a product spec, a changelog. `store_document` / `search_documents` embed arbitrary text and retrieve the most relevant chunk at query time. Embeddings come from `fastembed` when it is installed, and from a built-in TF-IDF fallback when it is not (see [Embedding Model](#embedding-model)).
 
 ### memory.store_document / memory.search_documents
 
@@ -136,7 +148,7 @@ store.clear
 
 Default: `BAAI/bge-small-en-v1.5` (~23 MB, downloaded on first use, cached in `~/.cache/fastembed/`).
 
-Documents are embedded with a `"passage: "` prefix and queries with `"query: "` prefix — the standard retrieval convention for BGE models.
+Documents and queries are embedded asymmetrically: stored text goes through `Fastembed::TextEmbedding#passage_embed`, query text through `#query_embed`. RobotLab does **not** prepend any literal `"passage: "` / `"query: "` string of its own — it hands the raw text to the two methods and lets fastembed handle whatever instruction prefixing the model expects.
 
 Custom model:
 
@@ -144,6 +156,23 @@ Custom model:
 store = RobotLab::DocumentStore.new(model_name: "BAAI/bge-base-en-v1.5")
 ```
 
+### TF-IDF Fallback
+
+`DocumentStore` decides once, at load time, whether `fastembed` is available
+(`RobotLab::DocumentStore::FASTEMBED_AVAILABLE`). When it is **not**, the store
+still works — it silently falls back to a stemmed, stop-word-filtered,
+L2-normalised term-frequency embedder and compares those sparse vectors by
+cosine similarity. Nothing is downloaded and everything runs offline, which
+makes it convenient for development and CI.
+
+> [!WARNING]
+> The fallback is **lexical, not semantic**. It matches shared word stems only,
+> so a query and a document that mean the same thing in different words score
+> `0.0`. There is no error, no warning, and no change to the API — only
+> noticeably worse results. Check `RobotLab::DocumentStore::FASTEMBED_AVAILABLE`
+> if you need to know which path you are on, and note that `model_name:` is
+> ignored entirely when it is `false`.
+
 ### RAG Pattern
 
 ```ruby
@@ -177,12 +206,14 @@ The embedding-based document store requires the [`robot_lab-document_store`](htt
 gem "robot_lab-document_store"
 ```
 
-This gem bundles `fastembed` for ONNX-based embeddings. The `BAAI/bge-small-en-v1.5` model (~23 MB) is downloaded on first use and cached in `~/.cache/fastembed/`. Without `robot_lab-document_store` loaded, calling `memory.store_document` or `memory.search_documents` raises `RobotLab::DependencyError`.
+The gem uses `fastembed` for ONNX-based embeddings when it is installed: the `BAAI/bge-small-en-v1.5` model (~23 MB) is downloaded on first use and cached in `~/.cache/fastembed/`. If `fastembed` cannot be loaded, `DocumentStore` still works via the lexical [TF-IDF fallback](#tf-idf-fallback).
+
+Without `robot_lab-document_store` itself loaded, calling `memory.store_document`, `memory.search_documents`, `memory.document_keys`, or `memory.delete_document` raises `RobotLab::DependencyError`.
 
 ---
 
 ## See Also
 
 - [Observability Guide](observability.md)
-- [Example 25 — Chat History Search](../../examples/25_history_search.rb)
-- [Example 26 — Embedding-Based Document Store](../../examples/26_document_store.rb)
+- [examples/25_history_search.rb](https://github.com/MadBomber/robot_lab/blob/main/examples/25_history_search.rb) — Chat History Search
+- [examples/26_document_store.rb](https://github.com/MadBomber/robot_lab/blob/main/examples/26_document_store.rb) — Embedding-Based Document Store

data/docs/guides/mcp-integration.md

@@ -50,9 +50,10 @@ MCP servers can be declared directly in a template's YAML front matter, making t
 description: GitHub assistant with MCP tool access
 mcp:
   - name: github
-    transport: stdio
-    command: npx
-    args: ["-y", "@modelcontextprotocol/server-github"]
+    transport:
+      type: stdio
+      command: npx
+      args: ["-y", "@modelcontextprotocol/server-github"]
 ---
 You are a helpful GitHub assistant with access to GitHub tools via MCP.
 ```
@@ -64,6 +65,16 @@ robot = RobotLab.build(template: :github_assistant)
 
 Constructor `mcp:` overrides frontmatter `mcp:` when provided.
 
+> [!CAUTION]
+> `transport:` must be a **nested mapping**, exactly as above. The flat form —
+> `transport: stdio` with sibling `command:`/`args:` keys — does not raise:
+> `Server` calls `transform_keys` on the transport value, a String raises
+> `NoMethodError: undefined method 'transform_keys' for an instance of String`,
+> and that exception is caught by MCP setup's rescue. The robot builds and runs
+> with **zero tools** from that server. It is not silent, though: the failure is
+> logged at `WARN` through `RobotLab.config.logger` (`$stdout` by default) and
+> the server name is recorded in `robot.failed_mcp_server_names`.
+
 ### Hierarchical Configuration
 
 The `mcp:` parameter supports three modes:
@@ -96,14 +107,21 @@ MCP configuration resolves through a hierarchy: **runtime > robot build > networ
 
 ```
 Global (RobotLab.config.mcp)
-  -> Network (task mcp: [...])
+  -> Network (network config:  / task config:)
     -> Robot (mcp: :inherit | :none | [...])
-      -> Runtime (robot.run("msg", mcp: [...]))
+      -> Runtime (robot.run("msg", mcp: [...]), and task mcp: [...])
 ```
 
+> [!NOTE]
+> A task's `mcp:`/`tools:` are **not** a separate network tier — `Task` puts
+> them into the run params, so they arrive as the **runtime** value for that
+> robot's `run()`. Only a `config:` (on the network or on the task) acts as the
+> parent level that `:inherit` resolves against.
+
 ## Timeout Configuration
 
-All transports support a configurable request timeout. The default is 15 seconds. Set a custom timeout at the server level:
+Every server config accepts a `timeout:`. The default is 15 seconds
+(`RobotLab::MCP::Server::DEFAULT_TIMEOUT`). Set it at the server level:
 
 ```ruby
 robot = RobotLab.build(
@@ -119,10 +137,46 @@ robot = RobotLab.build(
 )
 ```
 
-Values >= 1000 are auto-converted from milliseconds to seconds. The minimum timeout is 1 second.
+Values >= 1000 are auto-converted from milliseconds to seconds. The minimum timeout is 1 second:
+
+| Given | Stored |
+|-------|--------|
+| `nil` | `15` (the default) |
+| `30` | `30.0` |
+| `5000` | `5.0` (read as milliseconds) |
+| `0.5` | `1` (floored to the 1-second minimum) |
+
+> [!WARNING]
+> **Only the Stdio transport actually enforces the timeout.** SSE, WebSocket,
+> and StreamableHTTP store the value and never reference it — a remote MCP
+> server that stops responding will hang the call indefinitely regardless of
+> what you set here. Apply your own timeout around remote-transport calls if
+> you need one.
 
 ## Transport Types
 
+Valid `type:` values are exactly: `stdio`, `sse`, `ws`, `websocket`,
+`streamable-http`, `http` (`RobotLab::MCP::Server::VALID_TRANSPORT_TYPES`).
+
+An invalid type raises `ArgumentError: Invalid transport type: <type>. Must be
+one of: stdio, sse, ws, websocket, streamable-http, http` — but **only if you
+construct the server or client yourself**. Through the robot (`mcp:` on
+`RobotLab.build`) the error is caught by the same rescue that handles any other
+connect failure: it is logged at `WARN` and the server name is recorded in
+`robot.failed_mcp_server_names`, and the robot carries on with zero tools from
+that server. See [Connection Errors](#connection-errors).
+
+```ruby
+bad = { name: "oops", transport: { type: "streamable_http", url: "https://x" } }
+
+RobotLab::MCP::Server.new(**bad)   # => raises ArgumentError
+
+robot = RobotLab.build(name: "r", system_prompt: "...", mcp: [bad])
+robot.run("hi", mcp: :inherit, tools: :inherit)
+# logs: WARN Robot 'r' error connecting to MCP server 'oops': Invalid transport type: ...
+robot.failed_mcp_server_names   # => ["oops"]
+```
+
 ### Stdio Transport
 
 Communicate via stdin/stdout with a subprocess:
@@ -154,7 +208,9 @@ Connect via WebSocket:
 ```
 
 !!! note "Dependency Required"
-    WebSocket transport requires the `async-websocket` gem.
+    WebSocket transport requires the `async-websocket` gem. (It also reaches for
+    `Async::HTTP::Endpoint` without requiring it, so `async-http` must be loaded
+    as well.)
 
 ### SSE Transport
 
@@ -170,6 +226,9 @@ Server-Sent Events transport:
 }
 ```
 
+!!! note "Dependency Required"
+    SSE transport requires the `async-http` gem.
+
 ### HTTP Transport
 
 Streamable HTTP transport with session support:
@@ -178,7 +237,7 @@ Streamable HTTP transport with session support:
 {
   name: "http_server",
   transport: {
-    type: "streamable_http",
+    type: "streamable-http",   # or "http" — NOT "streamable_http"
     url: "https://api.example.com/mcp",
     session_id: "optional_session_id",
     auth_provider: -> { "Bearer #{fetch_token}" }
@@ -186,30 +245,60 @@ Streamable HTTP transport with session support:
 }
 ```
 
+!!! note "Dependency Required"
+    Streamable HTTP transport requires the `async-http` gem.
+
+> [!CAUTION]
+> The type is spelled with a **hyphen**. `type: "streamable_http"` (underscore)
+> raises `ArgumentError: Invalid transport type: streamable_http`.
+
+> [!WARNING]
+> The remote transports connect inside an un-awaited `Async` block and set
+> their connected flag **before** the MCP initialize handshake. `client.connected?`
+> therefore returns `true` even when the host is unreachable — do not treat it
+> as proof the server answered. Stdio is the only transport that blocks on the
+> handshake and reports a connect failure synchronously.
+
 ## Using MCP Tools
 
-Once configured, MCP tools are automatically discovered and made available to the robot. The robot connects to MCP servers on its first `run` call and discovers tools dynamically:
+Once configured, MCP tools are discovered on connect and made available to the
+robot. **Connecting is not automatic** — see the warning below:
 
 ```ruby
 robot = RobotLab.build(
   name: "helper",
-  system_prompt: <<~PROMPT
+  system_prompt: <<~PROMPT,
     You can help users with GitHub tasks.
     Use available tools to search repositories, create issues, etc.
-  PROMPT,
+  PROMPT
   mcp: [
     { name: "github", transport: { type: "stdio", command: "mcp-server-github" } }
   ]
 )
 
-# MCP tools are automatically available
-result = robot.run("Find repositories about machine learning")
+# mcp: :inherit connects the servers; tools: :inherit sends their tools to the LLM.
+result = robot.run("Find repositories about machine learning", mcp: :inherit, tools: :inherit)
 puts result.last_text_content
 ```
 
+> [!CAUTION]
+> **A plain `robot.run(message)` neither connects MCP servers nor sends any
+> tools.** Both the `mcp:` and `tools:` parameters of `run` default to `:none`,
+> which means "zero this turn" — the build-time `mcp:` list is simply not
+> consulted. You need **both** flags:
+>
+> ```ruby
+> robot.run("...")                                   # no MCP connection, no tools
+> robot.run("...", mcp: :inherit)                    # connects, but sends zero tools
+> robot.run("...", mcp: :inherit, tools: :inherit)   # connects AND sends its tools
+> ```
+
 ## Filtering MCP Tools
 
-Use the `tools:` parameter to restrict which tools (including MCP-discovered tools) are available to a robot:
+Use the `tools:` parameter to restrict which tools (including MCP-discovered
+tools) reach the LLM. It is a **name allowlist**, and it must be supplied at the
+level that actually runs — the `run()` call (or the network `task`, which
+forwards to `run()`):
 
 ```ruby
 robot = RobotLab.build(
@@ -217,14 +306,32 @@ robot = RobotLab.build(
   system_prompt: "You help read and search files.",
   mcp: [
     { name: "filesystem", transport: { type: "stdio", command: "mcp-server-fs" } }
-  ],
-  tools: %w[read_file search_files list_directory]  # Only allow specific tools
+  ]
 )
+
+robot.run("Summarise the README",
+          mcp:   :inherit,
+          tools: %w[read_file search_files list_directory])  # only these
 ```
 
+> [!WARNING]
+> A build-time `tools: %w[...]` allowlist has no effect on its own, because the
+> runtime default of `:none` sends zero tools regardless. And for a
+> **standalone** robot, do not write `tools: :inherit` at build time as a
+> workaround: there the parent level is the global `:none`, so it produces an
+> allowlist of `["none"]` that matches nothing. Leave build-time `tools:` unset
+> and pass the filter at run time.
+>
+> Inside a **network** whose `config:` supplies `tools:`/`mcp:`, this reverses:
+> the parent level is the network's list, and build-time `:inherit` is what
+> makes the robot pick it up. See
+> [Network-Wide Tool and MCP Defaults](creating-networks.md#network-wide-tool-and-mcp-defaults).
+
 ## MCP in Networks
 
-When running robots in a network, use per-task MCP configuration:
+When running robots in a network, use per-task MCP configuration. Remember that
+a task's `mcp:`/`tools:` become that robot's **runtime** values, so `tools:`
+must be set too or the MCP tools will not be sent:
 
 ```ruby
 network = RobotLab.create_network(name: "dev_pipeline") do
@@ -233,6 +340,7 @@ network = RobotLab.create_network(name: "dev_pipeline") do
        mcp: [
          { name: "filesystem", transport: { type: "stdio", command: "mcp-server-fs" } }
        ],
+       tools: :inherit,
        depends_on: [:planner]
   task :reviewer, reviewer_robot, depends_on: [:coder]
 end
@@ -310,6 +418,13 @@ client.list_resources       # => Array of resource definitions
 client.disconnect
 ```
 
+> [!NOTE]
+> `MCP::Client#initialize(server_or_config, poller: nil)` takes its server as a
+> **positional** argument — either a `Server` instance or a config Hash.
+> `Client.new(name: "x", transport: {...})` raises `ArgumentError: wrong number
+> of arguments (given 0, expected 1)`; wrap the hash in braces:
+> `Client.new({ name: "x", transport: {...} })`.
+
 ## Connection Multiplexing
 
 When a robot connects to several local (stdio) MCP servers, each client normally blocks independently while waiting for a response. `MCP::ConnectionPoller` replaces this with a single `IO.select` call across all registered stdout file descriptors, dispatching each response to the pending request for that client.
@@ -377,8 +492,10 @@ robot = RobotLab.build(
   ]
 )
 
-# Discovery connects only :brew for this message — filesystem and github are skipped
-robot.run("install imagemagick")
+# Discovery connects only :brew for this message — filesystem and github are skipped.
+# mcp: :inherit is required; a plain run() resolves the MCP list to empty and
+# discovery never runs.
+robot.run("install imagemagick", mcp: :inherit, tools: :inherit)
 ```
 
 ### How It Works
@@ -387,7 +504,7 @@ robot.run("install imagemagick")
 
 The threshold is intentionally low — server descriptions are short, so raw cosine scores are naturally small even for on-topic queries.
 
-Discovery only applies on the **first** `run()` call (before `@mcp_initialized`). Once a set of servers is connected they remain connected for the robot's lifetime, preserving tool continuity across a conversation.
+Discovery only applies on the **first** MCP-resolving `run()` call (before the robot is marked MCP-initialized). Once a set of servers is connected they remain connected for the robot's lifetime, preserving tool continuity across a conversation.
 
 ### Fallback Behaviour
 
@@ -404,23 +521,42 @@ All servers are returned unchanged when any of the following apply:
 
 ```ruby
 servers = [
-  { name: "filesystem", description: "Read and write files", transport: { ... } },
-  { name: "github",     description: "GitHub repos and PRs",  transport: { ... } }
+  { name: "filesystem", description: "Read and write files",
+    transport: { type: "stdio", command: "mcp-server-fs" } },
+  { name: "github",     description: "GitHub repos and PRs",
+    transport: { type: "stdio", command: "mcp-server-github" } }
 ]
 
 relevant = RobotLab::MCP::ServerDiscovery.select(
-  "list open pull requests",
+  "search github repos",
   from: servers,
   threshold: 0.05   # optional, default
 )
-# => only the :github entry
+# => [{ name: "github", ... }]
 ```
 
+> [!IMPORTANT]
+> Scoring is lexical, not semantic — it compares word stems against each
+> server's `description`. A query that happens to share no stems with **any**
+> description scores 0.0 everywhere, trips the "nothing above threshold"
+> fallback in the table above, and gets **all** servers back rather than none.
+> With the two servers above:
+>
+> ```ruby
+> select("search github repos",     from: servers)  # => ["github"]
+> select("read and write files",    from: servers)  # => ["filesystem"]
+> select("list open pull requests", from: servers)  # => ["filesystem", "github"]  <- fallback
+> ```
+>
+> The last one selects everything because the description says "PRs", not "pull
+> requests". Write descriptions using the words your prompts will actually use.
+
 ## Connection Resilience
 
 ### Eager Connection
 
-By default, MCP connections are lazy — established on the first `run()` call. Use `connect_mcp!` to connect early:
+`connect_mcp!` connects the robot's configured servers immediately, without
+waiting for a `run()` that passes `mcp: :inherit`:
 
 ```ruby
 robot = RobotLab.build(
@@ -440,14 +576,22 @@ if robot.failed_mcp_server_names.any?
 end
 ```
 
+> [!NOTE]
+> `connect_mcp!` only opens the connections. A later plain `robot.run(message)`
+> still sends the LLM **zero** tools, because `run`'s `tools:` defaults to
+> `:none`. Eager connection and tool visibility are separate switches.
+
 ### Automatic Retry
 
-Failed MCP servers are automatically retried on subsequent `run()` calls. If a server was down when the robot first connected, it will be retried transparently:
+Failed MCP servers are retried on subsequent `run()` calls **that resolve to a
+non-empty MCP list** — i.e. runs that pass `mcp: :inherit` (or an explicit
+array). If a server was down when the robot first connected, it is retried
+transparently:
 
 ```ruby
-robot.run("First message")       # github connects, filesystem fails
+robot.run("First message",  mcp: :inherit, tools: :inherit)  # github connects, filesystem fails
 # ... filesystem comes back up ...
-robot.run("Second message")      # filesystem retried and connects
+robot.run("Second message", mcp: :inherit, tools: :inherit)  # filesystem retried and connects
 ```
 
 ### Injecting External MCP Clients
@@ -464,25 +608,45 @@ This skips the normal connection process and marks the robot as MCP-initialized.
 
 ### Connection Errors
 
+MCP connection failures are **not raised**. They are logged as warnings and
+recorded on the robot; the run continues without that server's tools, and one
+failing server does not prevent the others from connecting. Inspect the result
+rather than rescuing:
+
 ```ruby
-begin
-  result = robot.run("Search for repos")
-rescue RobotLab::MCPError => e
-  puts "MCP Error: #{e.message}"
+result = robot.run("Search for repos", mcp: :inherit, tools: :inherit)
+
+if robot.failed_mcp_server_names.any?
+  warn "MCP servers unavailable: #{robot.failed_mcp_server_names.join(', ')}"
 end
 ```
 
-MCP connection failures are logged as warnings but do not raise errors by default. The robot will continue without MCP tools if a server is unreachable. One failing server does not prevent other servers from connecting.
-
 ### Timeout Errors
 
-Stdio transports wrap all blocking I/O with a configurable timeout. If a server does not respond within the timeout period, an `MCPError` is raised with a descriptive message:
+Stdio transports wrap all blocking I/O with a configurable timeout. On expiry
+the transport raises `MCPError`. Note that the two messages differ, and neither
+uses the server *name* you configured — the handshake message names the
+**command**, and the per-request message names nothing at all:
 
 ```ruby
-# Server that takes too long will raise:
-# RobotLab::MCPError: MCP server 'heavy-server' did not respond within 15s
+# Handshake timed out during connect:
+# RobotLab::MCPError: MCP server 'heavy-mcp-server' did not respond within 15s
+
+# A later request timed out:
+# RobotLab::MCPError: MCP server did not respond within 15s
 ```
 
+> [!IMPORTANT]
+> `MCP::Client#connect` rescues **every** `StandardError`, logs
+> `"MCP connection failed for <name>: ..."` at `:warn`, and returns `self` with
+> `connected?` false. So a connect-time timeout never reaches your `begin/rescue`
+> — check `client.connected?` (or `robot.failed_mcp_server_names`) instead.
+> Per-request calls such as `list_tools` and `call_tool` **do** propagate
+> `MCPError`.
+
+SSE, WebSocket, and StreamableHTTP raise no timeout error at all — see the
+warning under [Timeout Configuration](#timeout-configuration).
+
 ## Disconnecting
 
 Robots can be manually disconnected from MCP servers:
@@ -546,25 +710,28 @@ robot = RobotLab.build(
 
 ### 2. Limit Tool Access
 
-Restrict which MCP tools are available to a robot using the `tools:` parameter:
+Restrict which MCP tools reach the LLM with a `tools:` allowlist on the run:
 
 ```ruby
 robot = RobotLab.build(
   name: "reader",
   system_prompt: "You read and search files.",
-  mcp: [{ name: "fs", transport: { type: "stdio", command: "mcp-fs" } }],
-  tools: %w[read_file search_files]  # No write access
+  mcp: [{ name: "fs", transport: { type: "stdio", command: "mcp-fs" } }]
 )
+
+robot.run("Find the config file",
+          mcp:   :inherit,
+          tools: %w[read_file search_files])  # No write access
 ```
 
 ### 3. Use Appropriate Transports
 
 | Transport | Best For |
 |-----------|----------|
-| `stdio` | Local servers, CLI tools |
-| `websocket` | Persistent connections, bidirectional |
+| `stdio` | Local servers, CLI tools. The only transport that enforces `timeout:` and reports connect failures synchronously. |
+| `websocket` (or `ws`) | Persistent connections, bidirectional |
 | `sse` | Server push, event streams |
-| `streamable_http` | Remote APIs, session-based |
+| `streamable-http` (or `http`) | Remote APIs, session-based |
 
 ## Next Steps