Skip to main content
Glama

ConferLLM

ConferLLM is a CLI for people and agents to consult AI models, continue conversations, and work with images. Use it to get a second opinion, compare answers across models, or call a model from a script with structured JSON output.

It connects to providers through LiteLLM and stores conversations locally. A bundled Agent Skill and an MCP server expose the same conversation features.

Quick start

Requires Python 3.10+. Bring credentials for the provider you want to use.

1. Install

Install with uv (recommended):

uv tool install conferllm

Alternatively, use pip in an activated Python virtual environment:

pip install conferllm

If your shell cannot find the uv-installed command, run uv tool update-shell and reopen the terminal. See the installation reference for details.

2. Configure one model

Create a private configuration directory:

mkdir -p ~/.conferllm
chmod 700 ~/.conferllm

Create ~/.conferllm/config.yaml with the following content and replace the example API key. If you already have a configuration, add the model without duplicating an existing alias or overwriting your settings.

model_list:
  - model_name: gpt-4o
    capabilities:
      input_modalities: [text, image]
      output_modalities: [text]
    litellm_params:
      model: openai/gpt-4o
      api_key: "replace-with-your-key"
chmod 600 ~/.conferllm/config.yaml

model_name is the alias used in commands; substitute your own if it differs. This example uses OpenAI, and model availability depends on your account. For other providers and local endpoints, see config_example.yaml.

3. Ask a question

conferllm chat --model gpt-4o --prompt "Explain Raft leader election."

The output includes an answer and a session ID. Keep the ID to ask follow-up questions with the conversation history restored.

Related MCP server: MCP AI Gateway

Common tasks

Continue or find a conversation

Replace SESSION_ID with the ID returned by your chat:

conferllm chat --session SESSION_ID --prompt "Now compare it with Paxos."
conferllm sessions list
conferllm sessions list --query raft --json

A session keeps its original model. To compare models, start a separate chat for each configured alias using the same prompt. Use --name "Raft notes" when creating a chat to give it a memorable name.

Use JSON or a prompt file

conferllm chat --model gpt-4o --prompt "Explain Raft leader election." --json
conferllm chat --model gpt-4o --prompt-file ./prompt.md --json

Write a long or multiline prompt into prompt.md before using --prompt-file. JSON output includes session.id, message.text, artifacts, and warnings. See the response and error reference for the full contract.

Include images

With a model that supports images, repeat --image to attach your files in order:

conferllm chat \
  --model gpt-4o \
  --prompt "Compare these screenshots." \
  --image ./before.png \
  --image ./after.png \
  --json

Images are copied into the session so follow-ups can reuse them. For models that return images, --image-output-dir ./output exports additional copies. See image support and limits.

Use from an agent

Install the bundled Skill into ~/.agents/skills/conferllm:

conferllm skill install

For ~/.codex/skills/conferllm, use conferllm skill install --target codex. Then ask your agent to use the ConferLLM Skill for a second opinion or model comparison. The Skill discovers configured aliases and uses the CLI without opening credential or session files.

See Skill installation details for custom destinations and updates.

Use as an MCP server

The stdio server starts with conferllm serve. For clients that use an mcpServers configuration, add:

{
  "mcpServers": {
    "conferllm": {
      "command": "conferllm",
      "args": ["serve"]
    }
  }
}

The client launches the server; you do not need to start it separately. If the client cannot find the command, use the absolute path from command -v conferllm. See the MCP reference for tools and transports.

Configuration and troubleshooting

Inspect configuration without printing credentials:

conferllm doctor --json
conferllm models --json
conferllm model-info gpt-4o

Use --config PATH with a command to select another configuration file. If a model is not found, use an alias listed by conferllm models. See configuration options and troubleshooting.

Privacy and limits

Prompts, history, and images go to the provider endpoint you configure; a local CLI does not imply offline inference. Sessions and image copies remain under ~/.conferllm/sessions/ by default. Keep them and your credentials out of version control. Stored directories use 0700; session and image files use 0600.

Responses are non-streaming. ConferLLM does not execute provider tool calls, download remote-only image outputs, or automatically shorten long histories. See storage and reliability.

Development and contributing

Report bugs in GitHub Issues; pull requests are welcome too. Include reproduction steps and sanitized output, never credentials or private conversations. See the source setup and development checks.

To keep an installed CLI linked to this checkout while editing:

uv tool install --editable . --force

This replaces an existing ConferLLM tool install. Python source edits take effect on the next invocation; restart any running server after edits. Reinstall when dependencies or command entry points change.

License

ConferLLM is released under the MIT License.

Available Tools

3 tools
chatB

Chat with specified AI model.

    Args:
        model: Model name from configuration (e.g., 'gpt-4', 'claude-sonnet-4')
        inputs: Chat input (string or OpenAI-format messages)

    Returns:
        AI model response as string
    
ParametersJSON Schema
NameRequiredDescriptionDefault
inputsYes
modelYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. While it mentions the tool chats with AI models, it doesn't describe important behavioral aspects like rate limits, authentication requirements, cost implications, error handling, or whether this is a read-only vs. state-changing operation.

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?

The description is perfectly structured and concise - a clear purpose statement followed by well-organized parameter explanations and return value description. Every sentence earns its place with no wasted words.

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?

Given the tool's complexity (interactive AI chat) and the presence of an output schema (which handles return values), the description is adequate but incomplete. It covers parameters well but lacks behavioral context that would be crucial for an AI agent to use this tool appropriately.

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?

The description adds significant value beyond the 0% schema description coverage by explaining both parameters: 'model' is described as 'Model name from configuration' with examples, and 'inputs' is clarified as 'Chat input (string or OpenAI-format messages)'. This compensates well for the schema's lack of descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose as 'Chat with specified AI model', which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'get_model_info' or 'list_models', which appear to be informational rather than interactive.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. There's no mention of when to choose 'chat' over the sibling tools 'get_model_info' or 'list_models', nor any context about appropriate use cases or limitations.

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

get_model_infoC

Get information about a specific model.

    Args:
        model: Model name to get info for

    Returns:
        Dictionary with model information
    
ParametersJSON Schema
NameRequiredDescriptionDefault
modelYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'Get information' but doesn't clarify if this is a read-only operation, what happens if the model doesn't exist (e.g., error handling), or any rate limits or permissions required. This leaves significant gaps in understanding the tool's behavior.

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 appropriately sized and front-loaded, starting with the main purpose. The Args and Returns sections are structured clearly, but the formatting with indentation might be slightly verbose. Overall, it's efficient with little waste.

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?

Given the tool's low complexity (one parameter) and the presence of an output schema, the description is somewhat complete. However, it lacks behavioral context and usage guidelines, which are important for an AI agent to invoke it correctly. The output schema helps, but the description could do more to explain the tool's role relative to siblings.

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?

The description adds minimal semantics beyond the input schema, which has 0% description coverage. It specifies that the 'model' parameter is the 'Model name to get info for', but this is basic and doesn't provide details like format, examples, or constraints. With one parameter and low schema coverage, the description compensates slightly but not fully.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('Get') and resource ('information about a specific model'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'list_models', which might list multiple models rather than get detailed info about one.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites, such as whether the model must exist or be accessible, and doesn't mention sibling tools like 'list_models' for comparison or 'chat' for different operations.

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

list_modelsB

List all available AI models.

    Returns:
        List of available model names
    
ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. While it states the tool lists models and returns a list of names, it doesn't describe important behavioral aspects like whether this is a read-only operation, if there are rate limits, authentication requirements, or how the list is structured (e.g., pagination, sorting). The description is minimal and lacks behavioral context.

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 very concise with two sentences: one stating the purpose and one describing the return value. It's front-loaded with the main action. However, the formatting with indentation and a 'Returns:' section is slightly verbose for such a simple tool, but not wasteful.

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?

Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is adequate but minimal. It covers the basic purpose and return type, but lacks context on usage guidelines and behavioral traits. For a simple list tool, this might be sufficient, but it could benefit from more guidance on when to use it versus siblings.

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?

The tool has 0 parameters, and schema description coverage is 100% (empty schema). The description doesn't need to explain any parameters, which is appropriate. It focuses on the return value instead, which adds value beyond the input schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('List') and resource ('all available AI models'). It distinguishes from 'get_model_info' by focusing on listing all models rather than getting detailed information about a specific one. However, it doesn't explicitly differentiate from 'chat' beyond the obvious functional difference.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like 'get_model_info' or 'chat'. It doesn't mention any prerequisites, context, or exclusions for usage. The agent must infer usage from the tool name and description alone.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 3 tool updates
    • First observedchat
    • First observedget_model_info
    • First observedlist_models

TDQS

B3.3/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: chat for interacting with models, get_model_info for retrieving metadata about a specific model, and list_models for enumerating available models. There is no overlap or ambiguity between these functions.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (chat, get_model_info, list_models) with clear, descriptive verbs that align with their actions. No deviations or mixed conventions are present.

Tool Count3/5

With only 3 tools, the set feels thin for an AI hub server, potentially lacking operations like model configuration, session management, or advanced interactions. However, it covers basic listing, info retrieval, and chat functionality.

Completeness3/5

The tools provide core chat and model listing capabilities but have notable gaps for a full AI hub domain, such as updating model settings, managing conversations, or handling multimodal inputs. Agents can work around this but may encounter limitations.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    D
    maintenance
    An MCP server that enables AI applications to access 20+ model providers (including OpenAI, Anthropic, Google) through a unified interface for text and image generation.
    2
    30
    MIT
  • A
    license
    B
    quality
    F
    maintenance
    Enables AI assistants to intelligently select and switch between different AI models (OpenAI, Anthropic, etc.) within the same conversation based on task requirements. Provides a unified interface for accessing multiple AI providers through a single MCP tool.
    1
    8
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    Provides comprehensive AI model metadata through MCP, enabling search and filtering of 100+ AI models by capabilities, pricing, context length, and provider specifications.
    MIT
  • F
    license
    Not graded
    quality
    D
    maintenance
    Provides a unified MCP interface for running completions, embeddings, image generation, and classification across OpenAI, Anthropic, Groq, and Mistral. Eliminates provider-specific boilerplate by standardizing API calls for text generation, vector embeddings, and classification tasks.
    -

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/feiskyer/conferllm'

If you have feedback or need assistance with the MCP directory API, please join our Discord server