docs(mcp): document live-probed capability annotations in .info mcp-server

MCP-Servers.md

@@ -606,6 +606,11 @@ Coyote only emits the meta-functions that make sense for each server:
 So a resources-only server still gets `mcp_search`, `mcp_describe`, and `mcp_read`, and never wastes context on an
 `mcp_invoke` or `mcp_prompt` that would always error.
 
+Note that *declaring* a capability and *serving* items for it are different things: some server SDKs advertise
+prompts/resources unconditionally even when zero prompts or resources are actually registered. Gating (and prompt
+completion) always reflects what the server actually serves, and `.info mcp-server <server>` makes the difference
+visible by live-probing each declared capability.
+
 ## Reading Resources
 
 `mcp_read_<server>` reads a resource by URI, or expands a resource template with variable values:
@@ -793,6 +798,11 @@ tools (2 allowed / 4 total)
 
 * ✓ rows show which pattern matched in each layer, joined with `∧`.
 * ✗ rows name the first layer that hid the tool.
+* The `capabilities` line live-probes prompts and resources: capabilities with served items show a count (e.g.
+  `prompts (2)`, `resources (3)` — resources count includes templates), while a capability the server declares but
+  serves nothing for is annotated `prompts (declared, none served)`. That's why a server can "support" prompts yet
+  offer no `/prompt` completions. If the probe itself errors, the annotation is `(declared, list failed)`. `tools`
+  is never annotated — the tool table below it tells the full story.
 * ⚠ lines flag **dead patterns**: patterns that match none of the server's allowed tools (usually typos). Dead
   patterns are also logged as warnings when the server's catalog is fetched.
 * With no active filter, the header shows `filter layers  (none — all tools allowed)` and every tool is a bare ✓.