Skip to main content
Glama

LLM 채팅

llm_chat
Read-only

Send a chat request to a selected LLM model and receive the assistant reply. 선택한 LLM 모델에 대화를 보내고 assistant 응답을 받습니다. 서버는 대화 히스토리를 보관하지 않는 stateless 방식 — 매 호출마다 전체 히스토리를 messages 로 전송하고, 응답의 compacted_messages 를 다음 턴의 messages 로 그대로 재사용합니다. 사용 가능한 모델은 llm_models Tool로 조회합니다. 토큰 사용량에 비례해 포인트가 차감됩니다. [무료]

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modelYes모델 id (llm_models Tool로 조회 가능, 예: openai/gpt-oss-120b)
speedNo응답 속도/추론 깊이 — 'fast'(얕게, 빠름) | 'medium' | 'slow'(깊게, 느림). 한글 '빠름'|'중간'|'느림' 허용. 추론 특화 모델에서 효과가 큽니다
systemNosystem 프롬프트 (역할·페르소나·정책·배경지식). 미지정 시 기본 한국어 어시스턴트 프롬프트가 적용됩니다
compactNo히스토리 압축 옵션 { strategy: 'none'(기본) | 'sliding_window', window_pairs: 유지할 user/assistant 페어 수 (기본 10, 최소 1) }. 긴 대화의 input 토큰 누적 방지
contentNo단발 입력 — 사용자 메시지 한 건만 보내는 간편 형태. messages 와 둘 중 하나는 필수
messagesNoOpenAI 형식 [{role, content}] 배열. role 은 'system'|'user'|'assistant'. content 와 둘 중 하나는 필수, 동시 지정 시 messages 우선. 멀티턴 대화는 응답의 compacted_messages 를 다음 턴에 그대로 전송
max_tokensNo응답 최대 토큰. 미지정 시 모델 컨텍스트 기반 안전 상한으로 자동 설정, 상한 초과 지정 시 자동 조정
temperatureNo출력 다양성 0.0~2.0. 낮을수록 재현성, 높을수록 창의성 (미지정 시 모델 기본값)

TDQS

A4.3/5.0
Behavior5/5

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

Beyond readOnlyHint/openWorldHint, it discloses statelessness, requiring the full conversation history on each call and the reuse of compacted_messages for the next turn. It also flags the point deduction proportional to token usage, adding cost awareness.

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 bilingual and includes several technical details, but every sentence conveys meaningful information: purpose, stateless behavior, model lookup, and cost. It is somewhat longer than necessary due to the duplication, but remains well-structured.

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?

With no output schema, the description mentions receiving an 'assistant reply' and the compacted_messages field, but does not detail the full response structure (e.g., usage metadata). Yet it covers the core workflow and prerequisites adequately for a chat tool.

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?

All 8 parameters are described in the schema with 100% coverage, so the description doesn't need to explain each parameter. It reinforces the critical multi-turn mechanism (compacted_messages) which the schema already documents, adding no new semantic value beyond the baseline.

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?

The description opens with a specific, action-oriented statement: 'Send a chat request to a selected LLM model and receive the assistant reply.' It clearly names the resource (LLM model) and the operation (chat request), and differentiates from siblings like llm_models (which lists models) and text_polish/text_summary (which are specialized text tasks).

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?

It explicitly points to llm_models for discovering available models, establishing a prerequisite workflow. However, it does not explicitly state when to prefer this over specialized text tools or provide exclusions, so it offers clear context but no full when-not guidance.

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.

TDQS

A4.2/5.0
Disambiguation5/5

llm_chat and llm_models form a clear pair (generic chat vs model catalog), while text_polish and text_summary are narrowly scoped fixed-purpose utilities. Their descriptions make the boundaries obvious, so an agent should not misroute a request between them.

Naming Consistency4/5

All names are lowercase snake_case and follow a readable domain_prefix pattern (llm_* and text_*). The conventions are not perfectly uniform, though: text_summary is a noun where text_polish uses a verb, and llm_models is a catalog noun rather than an action.

Tool Count5/5

Four tools is a compact, well-scoped set with no redundant entries: model discovery, general chat, and two specialized text operations. Each tool earns its place for this server's apparent purpose.

Completeness5/5

The tool surface covers the core LLM workflow (model lookup plus chat) and the advertised text-polish/summary operations without obvious dead ends. The stateless chat design is intentional, and pricing information is provided through llm_models.