Skip to main content
Glama

tascan_save_chat_thread

Create a chat thread for an admin of your org (no thread_id: POST /chat/threads with admin_id and an optional title, default New Chat) or rename one (thread_id: PUT /chat/threads/:id with title and/or preview). Write tier.

Input Schema

NameRequiredDescriptionDefault
titleNo
previewNo
admin_idNo
thread_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4/5.0
Behavior3/5

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

Annotations already declare write (readOnlyHint=false), non-destructive, non-idempotent, closed-world. The description adds useful behavioral detail beyond them: the default title 'New Chat', that title is optional on creation, and that renaming is a partial update of title and/or preview. It does not state what happens to fields not supplied, whether renaming requires admin_id, or what the call returns.

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?

One dense sentence, front-loaded with the outcome, then the branch conditions, then a useful tier marker. The raw HTTP endpoint notation is slightly jargon-heavy but earns its place by making behavior predictable.

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

Completeness3/5

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

For a mutation tool with annotations and no output schema, the definition covers mode selection and parameter roles, but leaves open permission requirements, which fields survive a rename, and the response shape an agent should expect after a write.

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 description coverage is 0%, so the description must carry the meaning, and it largely does: admin_id and optional title are tied to the create path, thread_id selects the rename path, and preview is scoped to renaming. Only format/constraint details are left implicit.

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 (create/rename) and resource (chat thread) and disambiguates the two modes it handles via the presence or absence of thread_id. An agent can tell exactly which operation will execute from the parameter shape 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?

The parenthetical routing (no thread_id → POST with admin_id and optional title; thread_id → PUT with title and/or preview) is an explicit when-to-use-which-mode rule. It doesn't reference sibling alternatives such as list_chat_threads or delete_chat_thread, but the internal branching is unambiguous.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.