Skip to main content
Glama
KrishnaMuddala

MCP Chat

by KrishnaMuddala
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

MCP Chat

Note: This project is an extension of the MCP certification project originally sourced from the Anthropic Claude MCP course. It has been extended to support local LLMs instead of the Anthropic API, along with additional tooling and improvements.

A command-line interface application that enables interactive chat with a local LLM (via Ollama or any OpenAI-compatible server) using the MCP (Model Context Protocol) architecture for document management.

Prerequisites

  • Python 3.9+

  • Ollama or any OpenAI-compatible local LLM server

Setup

Step 1: Configure environment variables

Create a .env file in the project root:

LOCAL_LLM_MODEL=llama3.2
LOCAL_LLM_BASE_URL=http://localhost:11434/v1
USE_UV=1   # Set to 0 if not using uv

Step 2: Install dependencies

Option 1: With uv (Recommended)

uv is a fast Python package installer and resolver.

pip install uv
uv venv
source .venv/bin/activate  # Windows: .venv\Scripts\activate
uv pip install -e .

Option 2: Without uv

python -m venv .venv
source .venv/bin/activate  # Windows: .venv\Scripts\activate
pip install openai python-dotenv prompt-toolkit "mcp[cli]==1.8.0"

Step 3: Start your local LLM

# Ollama example
ollama serve
ollama pull llama3.2

Step 4: Run the project

# With uv
uv run main.py

# With additional MCP servers
uv run main.py extra_server.py another_server.py

Usage

Basic Chat

Type your message and press Enter:

> What is the state of the condenser tower?

Document Retrieval

Use @ followed by a document ID to include its contents in your query:

> Tell me about @deposition.md
> Summarize @financials.docx

Demo

MCP Chat CLI demo MCP Chat running with llama3.2 via Ollama on Windows

Commands

Use / prefix to execute MCP prompts. Press Tab to autocomplete:

> /format deposition.md
> /summarize report.pdf

Available Documents

Document

Description

deposition.md

Testimony of Angela Smith, P.E.

report.pdf

State of a 20m condenser tower

financials.docx

Project budget and expenditures

outlook.pdf

Projected future performance

plan.md

Project implementation steps

spec.txt

Technical equipment requirements

Architecture

main.py
  ├── MCPClient          # Manages stdio communication with MCP server(s)
  ├── mcp_server.py      # FastMCP server — tools, resources, prompts
  ├── core/claude.py     # Local LLM integration (OpenAI-compatible)
  ├── core/cli_chat.py   # Chat logic with @ and / command handling
  └── core/cli.py        # Terminal UI with Tab autocomplete

MCP Server Features

Feature

Name

Description

Tool

read_doc_contents

Read the contents of a document by ID

Tool

edit_document

Replace text within a document

Resource

docs://documents

List all available document IDs

Resource

docs://documents/{doc_id}

Fetch contents of a specific document

Prompt

/format

Rewrite a document in Markdown format

Development

Adding New Documents

Edit the docs dictionary in mcp_server.py:

docs = {
    "your_doc.md": "Your document content here",
}

Adding New MCP Servers

Pass additional server scripts as arguments when running:

uv run main.py your_custom_server.py

Adding New Tools / Prompts / Resources

Use the FastMCP decorators in mcp_server.py:

@mcp.tool(name="my_tool", description="Does something useful")
def my_tool(input: str) -> str:
    return f"Processed: {input}"

Known Limitations

  • Document edits are in-memory only and lost on server restart

  • No persistent storage backend

  • No authentication or multi-user support (stdio only — single client per server instance)

Troubleshooting

OneDrive hardlink error on Windows:

$env:UV_LINK_MODE = "copy"; uv pip install -e .

Local LLM not responding:

  • Ensure Ollama is running: ollama serve

  • Confirm the model is pulled: ollama pull llama3.2

  • Check LOCAL_LLM_BASE_URL in .env matches your server

Module not found errors:

uv add openai python-dotenv mcp

Available Tools

2 tools
edit_documentB

Edit a document by replacing a string in the documents content with a new string

ParametersJSON Schema
NameRequiredDescriptionDefault
doc_idYesId of the document that will be edited
old_strYesThe text to replace. Must match exactly, including whitespace
new_strYesThe new text to insert in place of the old text

TDQS

B3.3/5.0
Behavior2/5

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

With no annotations, the description carries the full burden. It states 'edit' (a write operation) but does not disclose whether the edit is permanent, what happens on failure, or any side effects. The behavior is minimally transparent.

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 a single concise sentence that front-loads the primary action. It is efficient, though it could be slightly expanded for clarity without losing conciseness.

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

Completeness2/5

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

Given the tool has 3 required parameters, no output schema, and no annotations, the description should clarify return values or error behavior. It lacks this context, making it incomplete for an agent to fully understand the tool's effects.

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 coverage is 100% with good per-parameter descriptions. The tool description adds a high-level context of replacing a string, but does not provide additional syntax or constraints beyond what the schema already offers. Baseline score of 3 is appropriate.

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 clearly states the tool edits a document by replacing a string, which is a specific and distinct operation. The sibling tool 'read_doc_contents' is for reading, so this tool's purpose is well-differentiated.

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

Usage Guidelines3/5

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

The description implies that this tool is for editing (writing) while the sibling is for reading, but it does not explicitly state when to use this tool over the sibling or any prerequisites. Usage context is implied but not clarified.

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

read_doc_contentsA

Read the contents of a document and return it as a string.

ParametersJSON Schema
NameRequiredDescriptionDefault
doc_idYesId of the document to read

TDQS

A3.5/5.0
Behavior2/5

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

No annotations provided. Description lacks details on behavior such as size limits, permissions, or whether it returns raw content or plain text.

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?

Single, clear sentence with no redundancy. Front-loaded with purpose.

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?

Adequate for simple read operation, but missing output structure and potential error conditions. Could benefit from mentioning return format or limits.

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 covers parameter fully with description. No additional meaning added by description beyond schema.

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?

Description clearly states it reads document contents and returns as string. Distinguishes from sibling tool 'edit_document' which modifies.

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

Usage Guidelines3/5

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

Implicit usage by action (read vs edit) but no explicit guidance on when to use or not. Could mention it's for viewing only.

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. 2 tool updatesv0.1.0
    • First observededit_document
    • First observedread_doc_contents
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0
Disambiguation5/5

The two tools have distinct purposes: one for editing documents by replacing strings, and another for reading document contents. There is no overlap or ambiguity between them.

Naming Consistency5/5

Both tool names follow a consistent verb_noun pattern (edit_document, read_doc_contents) using snake_case, making them predictable and easy to understand.

Tool Count3/5

With only two tools, the server feels minimal for general document management, but it may be sufficient for a very narrow chat context. However, the small count is borderline and could benefit from additional operations.

Completeness2/5

The server lacks create and delete operations for documents, which are essential for a complete CRUD lifecycle. Agents would be unable to add or remove documents, leading to failures in typical workflows.

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

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/KrishnaMuddala/cli_project_local_llm'

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