hello team, having a error using the TS MCP: Connection or agent error: BadRequestError: Error code: 400 - {'error': {'message': "Failed to call a function. Please adjust your prompt. See 'failed_generation' for more details.", 'type': 'invalid_request_error', 'code': 'tool_use_failed', 'failed_generation': '<function=create_analysis_session{"data_source_id": "61411cea-d50c-4cd5-a51e-9d7cbd8e4840"}\n'}}

message has been deleted

That error means the model attempted a tool call, but the call format/flow was rejected before execution:

text
tool_use_failed
failed_generation: <function=create_analysis_session{"data_source_id":"..."}></function>

Most likely causes in TS MCP: 1. Function-call formatting issue in the host LLM/tool bridge (it emitted a pseudo-XML call string instead of a valid tool call envelope your client expects). 2. Tool schema mismatch (client expects different arg shape/name than the MCP server tool definition). 3. Prompt is forcing raw function syntax instead of letting the SDK/tooling produce structured tool calls. 4. Model/tooling incompatibility (tool-calling mode not enabled or wrong API surface). What is valid for ThoughtSpot MCP itself: -

create_analysis_session

is the correct first step. -

data_source_id

is optional and should be a worksheet/model GUID when provided. (So your parameter name looks correct.) ### Quick fix checklist - Do not ask the model to emit

<function=...>

text. - Ensure your client is configured for native tool calling (structured calls), not text-only generation. - Verify the tool is discoverable via MCP

listTools

and that

create_analysis_session

args include

data_source_id

. - Try calling

create_analysis_session

without

data_source_id

first (let TS auto-select datasource), then continue: 1)

create_analysis_session

2)

send_session_message

3)

get_session_updates

### Minimal known-good call shape (conceptual)

json
{
  "tool": "create_analysis_session",
  "arguments": {
    "data_source_id": "61411cea-d50c-4cd5-a51e-9d7cbd8e4840"
  }
}

If you share your client stack (OpenAI SDK version / MCP client library / exact request payload), I can pinpoint the exact field-level fix.

i mean im using gpt open source model from groq just testing it

Got it — that makes sense. If you’re testing with an open-source model via Groq, this specific error usually means the model emitted a raw function-call block that your runner/parser couldn’t execute in the expected schema:

text
<function=create_analysis_session{"data_source_id":"..."}></function>

That

failed_generation

payload is the key signal: the model attempted a tool call, but in a format the API layer rejected (

tool_use_failed

). ### What to change 1. Use a model/runtime that supports your exact tool-calling protocol - Some OSS models produce XML-like or ad-hoc tool syntax unless tightly constrained. - Ensure your Groq client is using its supported tool/function calling JSON schema, not free-form text parsing. 2. Force strict JSON tool calls in your system prompt - Instruct: “When calling tools, return only valid tool call JSON, no XML tags, no prose.” - Reject/reprompt on malformed calls. 3. Add a tool-call validator in your agent loop - Before execution, verify: - tool name exists - args are valid JSON - required fields present - If invalid, send a repair prompt to the model. 4. Try MCP server/tool version alignment - ThoughtSpot has both legacy MCP tool reference and newer MCP references; mixing schemas can break calls. - Confirm your server version and tool names match the docs you integrated. 5. A/B test with a known-good MCP client - Use ThoughtSpot’s example MCP client flow as a baseline to isolate whether issue is model formatting vs MCP backend. If you want, paste your tool definition JSON + one full request/response cycle from Groq, and I can pinpoint exactly where it breaks and give you a drop-in repair prompt.

@bignmn We will review and get back to you

Hi @bignmn, it looks like this is an issue on your client side, where it is not able to form or make the tool call request. Are you able to verify if the tool call HTTP request is actually sent out from your client or not? If the outgoing request is being sent, please provide an mcp-session-id value or any other identifying information, and I can check the logs from our end.