MCP for Claude & ChatGPT

Tuqui chats

tuqui_chat

Tuqui's own chat conversations. action='send' posts a message and runs the agent loop to completion, creating the conversation when you name no conversation_id and continuing it when you do — it returns the final reply plus a trace (tools called, token usage, guardrail signals); 'list' pages through your conversations, newest first; 'get' reads one in full, with include_tool_calls=true to expand what ran in each assistant turn; 'search' is full-text over your messages and takes the usual websearch syntax (foo bar, foo OR bar, -baz, "exact phrase"), returning matches ranked by relevance with highlights. Everything is the caller's own: these are the same conversations the Tuqui web UI shows, and RLS keeps other people's out of reach.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "tuqui_chat"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No	list / search: page size. Up to 200 for list, up to 100 for search.
`query`	No	Search query. Empty / whitespace-only is rejected.
`action`	No	What to do. Omitted it means 'send', which is what this tool's name meant before the four became one.	send
`offset`	No	list / search: skip this many; use the next_offset of a previous call.
`prompt`	No	User message to send to the chat.
`agent_id`	No	UUID of a Tuqui agent to run the turn under, with its instructions, skills, knowledge base and apps — same as picking it in the web UI. Locked into the conversation on the first turn, so continuing it keeps the same agent. Errors when the agent is unknown, not available to you or deactivated. To find the id, open the agent in the Tuqui web app (Agents) and copy it from the URL.
`workspace`	No	Workspace slug. Optional — defaults to the slug the OAuth session is scoped to. When set it must match; switch with set_workspace beforehand to target another.
`project_id`	No	UUID of a Tuqui project. Only honored on conversation creation; the conversation inherits the project's skills/MCPs/instructions.
`messages_limit`	No	Cap on messages returned. When the conversation has more, the most recent N are kept and truncated_from_start=true is set on the response with the total message count.
`conversation_id`	No	UUID of a conversation. send: continue this one instead of starting a new one. get: the one to read. Discover ids with action='list' or action='search'.
`reasoning_effort`	No	Thinking budget for reasoning-capable models (ignored otherwise). Overrides the conversation's own setting for this turn. Omitted: the conversation's setting when continuing one, 'low' for a new conversation (better skill/guardrail adherence). Pass 'off' to disable.
`tool_calls_limit`	No	Per-message cap on tool_calls when include_tool_calls is true. When exceeded the message carries tool_calls_truncated=true.
`include_tool_calls`	No	When true, expand tool_usage_log entries per assistant message.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 2, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare non-read-only, non-destructive, open-world; the description adds substantial context beyond that: the agent loop runs to completion, the response includes a trace with tools called, token usage and guardrail signals, agent_id is locked in on the first turn, project_id is honored only on creation, and RLS scopes results to the caller. That is real operational disclosure for a mutating tool.

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?

Front-loaded with scope, then organized action-by-action with no filler sentences. The semicolon-chained single paragraph is dense and slightly harder to scan than a bulleted action list would be, but every clause carries information.

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?

For a 13-parameter, four-action tool with no output schema, the description covers what 'send' returns (reply + trace) and what 'search' returns (ranked matches with highlights), plus the ownership/RLS boundary. Remaining return-shape details for 'list'/'get' are partly implied by the paging parameters, leaving no material gap for correct invocation.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description earns more by adding meaning the schema lacks — the websearch query syntax (`foo OR bar`, `-baz`, `"exact phrase"`) with <mark> highlights and relevance ranking, and the mapping of parameters to actions (conversation_id for send/get, include_tool_calls per assistant turn).

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?

Opens with a precise scope statement ("Tuqui's own chat conversations") and then names all four actions with specific verbs and resources: 'send' posts a message and runs the agent loop, 'list' pages conversations, 'get' reads one, 'search' is full-text over messages. An agent can tell exactly which mode to pick without opening the schema.

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?

Each action carries an implicit usage rule (e.g. name no conversation_id to create, pass one to continue; use list/search to discover ids), which gives clear context. However, it never contrasts itself with the sibling tuqui_agent, which also runs agents and could plausibly be confused with action='send' — no explicit when-not or alternative routing is offered.

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

All MCP for Claude & ChatGPT tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.