Skip to main content
Glama
merterbak

Grok MCP

by merterbak
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

stateful_chat

Continue server-side stored Grok conversations by sending only the latest prompt with a previous response ID, or omit it to start a new thread.

Instructions

Continue a server-side stored conversation using xAI's deferred/stateful chat.

The xAI API stores every turn so the client only needs to send the latest
prompt plus `previous_response_id`. Omit `response_id` to start a new thread.

Args:
    prompt: User message to append.
    model: Grok model id (default `grok-4.6`).
    response_id: ID of the previous response to continue from (omit to start fresh).
    system_prompt: Optional system instruction. Applied only on the first turn.
    show_usage: Append a token usage and cost footer to the reply (default False).

Returns:
    Assistant reply followed by the new `**Response ID:**` to pass back next turn.

Input Schema

NameRequiredDescriptionDefault
modelNogrok-4.6
promptYes
show_usageNo
response_idNo
system_promptNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.4
  2. Removed
  3. Changed1 schema field changedv1.0.1
    • addedInput schema / properties / show_usage
      Added value: +{
+  "default": false,
+  "title": "Show Usage",
+  "type": "boolean"
+}
  4. Added
  5. Removed
  6. Added
  7. Removed
  8. Added
  9. Removed
  10. Changed1 schema field changed
    • changedInput schema / properties / model / default
      Previous value: -"grok-4"New value: +"grok-4-1-fast-reasoning"
  11. Changed5 schema fields changed
    • removedInput schema / properties / include_reasoning
      Removed value: -{
-  "default": false,
-  "title": "Include Reasoning",
-  "type": "boolean"
-}
    • removedInput schema / properties / max_tokens
      Removed value: -{
-  "anyOf": [
-    {
-      "type": "integer"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "title": "Max Tokens"
-}
    • changedInput schema / properties / model / default
      Previous value: -"grok-4-1-fast-non-reasoning"New value: +"grok-4"
    • removedInput schema / properties / temperature
      Removed value: -{
-  "anyOf": [
-    {
-      "type": "number"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "title": "Temperature"
-}
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "additionalProperties": true,
-      "title": "Result",
-      "type": "object"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "stateful_chatOutput",
-  "type": "object"
-}New value: +null
  12. Changed2 schema fields changedv1.0.0
    • changedInput schema / properties / model / default
      Previous value: -"grok-4"New value: +"grok-4-1-fast-non-reasoning"
    • addedInput schema / title
      Added value: +"stateful_chatArguments"
  13. First observed

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses important behavioral traits: server-side persistence, that only the latest prompt plus previous_response_id is needed, that system_prompt applies only on the first turn, and that the return includes a new Response ID. It does not cover error modes, permission/rate-limit behavior, or whether expired response IDs are rejected.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded, with the core mechanism in the opening paragraphs followed by an Args/Returns block. Every sentence carries information, though the Args/Returns duplication of parameter semantics is slightly verbose for a tool with no output schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description is complete enough for an agent to call the tool correctly: it explains the stateful flow, parameter meanings, defaults, the first-turn system_prompt constraint, and what the return contains (reply plus Response ID to pass back). Nothing essential for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it does: it documents all five parameters with meaning and defaults (prompt, model default grok-4.6, response_id omission semantics, system_prompt first-turn-only constraint, show_usage footer behavior). This adds substantially beyond the bare schema titles/types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (continue) and resource (server-side stored conversation via xAI's deferred/stateful chat). It is clearly distinguishable from the sibling 'chat' and 'retrieve_stateful_response' because it explains the previous_response_id continuation mechanism, which none of the siblings describe.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit context for when to use it: to continue a stored conversation, sending only the latest prompt plus previous_response_id, and to omit response_id to start a new thread. It does not explicitly name the sibling alternatives (e.g., chat, retrieve_stateful_response) or state when not to use this tool, leaving a small gap.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools