Skip to main content
Glama
Sign In
chat-export-server

chat-export-server

by svergio
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

chats_create

Creates a new provider chat in the bound browser and seeds it with your initial message. Use it to open or prefill a chat without waiting for an assistant reply.

Instructions

Create a new chat on the provider UI in the bound browser and seed it with text. Prefer chat_ask when you also need to wait for the assistant reply; use chats_create only to open/seed a chat. Requires browsers_bind and allowCreate on the extension.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "platform": "<platform>",
      "text": "<text>"
    },
    "name": "chats_create"
  }
}

Input Schema

NameRequiredDescriptionDefault
textYesInitial user message text to place in the new chat
titleNoOptional title when the provider supports setting one
platformYesProvider id: chatgpt | grok | grok-x | claude | copilot | qwen | deepseek | perplexity

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.0.4
    • addedInput schema / properties / platform / description
      Added value: +"Provider id: chatgpt | grok | grok-x | claude | copilot | qwen | deepseek | perplexity"
    • addedInput schema / properties / text / description
      Added value: +"Initial user message text to place in the new chat"
    • addedInput schema / properties / title / description
      Added value: +"Optional title when the provider supports setting one"
  2. First observedv1.0.3

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare a non-read-only, non-idempotent, non-destructive open-world write, so the description need not restate that; it adds genuinely new context by naming the dependency on browsers_bind and the allowCreate extension permission. It does not say what happens if the browser is unbound or what the call yields (chat id/handle), which matters for a creation tool.

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

Conciseness5/5

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

Two sentences, front-loaded with the action, then routing guidance, then prerequisites. No filler and no repetition of schema content.

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

Completeness4/5

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

Params and prerequisites are fully covered and there is no output schema to explain. The one gap is that a creation tool normally returns an identifier the agent needs for follow-up calls (chat_read, chat_ask), and the description never says so.

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

Parameters3/5

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

Schema description coverage is 100%, so the enum of platform ids and the meaning of text/title are already fully documented in the schema. The description adds only "seed it with text," which is effectively a restatement of the text parameter, so baseline 3 applies.

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?

"Create a new chat on the provider UI in the bound browser and seed it with text" gives a specific verb (create), resource (chat), and execution surface (provider UI in the bound browser). It also implicitly separates itself from read/export siblings like chats_get and chats_export by describing an open-and-seed action.

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

Usage Guidelines5/5

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

Explicitly routes the agent: prefer chat_ask when a reply must be awaited, use chats_create only to open/seed. It also states the prerequisites (browsers_bind first, allowCreate enabled on the extension), which tells the agent when the call is even possible.

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