How do I use case-chronology-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@case-chronology-mcp Add event: May 1, 2023 - Discovery request." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

case-chronology-mcp

by medelman17

Overview Schema Related Servers Score Discussions

Python

Local

Case Chronology MCP Server

A Model Context Protocol (MCP) server for building and managing chronological timelines of case events. Perfect for legal professionals who need to organize complex case histories.

Features

Smart Date Parsing: Handles various date formats including exact dates, approximate dates, months, and quarters
Document Parsing: Automatically extract dates and events from pasted documents
Multi-format Export: Generate timelines in Markdown, CSV, brief text, or JSON
Advanced Search: Query by date range, parties, keywords, or tags
Party & Document Indexing: Quick lookups by involved parties or source documents

Related MCP server: Writer MCP

Installation

Option 1: Using uvx (Recommended)

No installation needed! The server can be run directly with uvx.

Option 2: Traditional Installation

Clone this repository:

git clone https://github.com/medelman17/case-chronology-mcp.git
cd case-chronology-mcp

Install with uv:

uv pip install -e .

Or with pip:

pip install -r requirements.txt

Configuration

Add the server to your Claude Desktop configuration:

Windows Users - Step by Step

Step 1: Download and Setup

Open PowerShell or Command Prompt
Navigate to where you want to install (e.g., your GitHub folder):
```
cd C:\Users\%USERNAME%\GitHub
```

Clone the repository:

git clone https://github.com/medelman17/case-chronology-mcp.git
cd case-chronology-mcp

IMPORTANT: Run the setup script (this creates a virtual environment and installs dependencies):
```
.\setup.bat
```
Wait for it to complete. You should see "Setup complete!" at the end.

Step 2: Configure Claude Desktop

Open Claude Desktop
Go to Settings (gear icon in bottom left)
Click Developer tab
Find the MCP Servers Configuration section
Add this configuration (replace %USERNAME% with your actual username):

{
  "mcpServers": {
    "case-chronology": {
      "command": "C:\\Users\\%USERNAME%\\GitHub\\case-chronology-mcp\\run_server.bat"
    }
  }
}

For example, if your username is mikee, use:

{
  "mcpServers": {
    "case-chronology": {
      "command": "C:\\Users\\mikee\\GitHub\\case-chronology-mcp\\run_server.bat"
    }
  }
}

Save the configuration
Restart Claude Desktop

Step 3: Test It Works

After restarting Claude Desktop, you should see the Case Chronology server connected. Try asking:

"Add an event: January 15, 2024 - Contract signed between ABC Corp and XYZ LLC"

Mac/Linux Users

Option 1: Using uvx (Recommended)

{
  "mcpServers": {
    "case-chronology": {
      "command": "uvx",
      "args": [
        "--from",
        "git+https://github.com/medelman17/case-chronology-mcp.git",
        "case-chronology-mcp"
      ]
    }
  }
}

Option 2: Local Installation

{
  "mcpServers": {
    "case-chronology": {
      "command": "python",
      "args": ["/full/path/to/case-chronology-mcp/chronology_server.py"]
    }
  }
}

Usage Examples

Adding Events

Simple event:

"Add event: March 15, 2023 - Smith emails Jones about breach of contract. Parties: Smith, Jones"

Event with details:

"Add event: 3/15/2023 - Contract breach notification sent. Parties: Smith, Jones. Tag: breach, notice. Significance: First formal notice of breach"

Document Parsing

"Parse this email and add events to the chronology:

From: Bob Smith
To: Alice Jones
Date: March 15, 2023

I am writing to inform you that your failure to deliver by March 1, 2023 constitutes a breach..."

Searching the Timeline

"Show all events in March 2023"
"Find events involving Smith"
"Search for events tagged 'breach'"
"Show events between 1/1/2023 and 6/30/2023"

Exporting

"Export the chronology as markdown"
"Give me a brief timeline"
"Export as CSV for Excel"
"Export full JSON data"

Date Format Support

The server intelligently parses various date formats:

Exact dates: 3/15/2023, March 15, 2023
Approximate dates: early March 2023, mid March 2023, late March 2023
Month precision: March 2023
Quarter precision: Q1 2023
Approximate markers: around 3/15/2023, approximately March 2023

Data Storage

Events are stored in case_chronology.json in the same directory as the server. The file is created automatically on first use.

Troubleshooting (Windows)

❌ "Virtual environment not found" error

Make sure you ran .\setup.bat first
Check that the venv folder exists in your project directory

❌ "Python not found" error

Install Python 3.10 or later from python.org
Make sure to check "Add Python to PATH" during installation

❌ "Setup failed" error

Try running PowerShell as Administrator

Or manually create the environment:

python -m venv venv
venv\Scripts\activate
pip install -r requirements.txt

❌ Server disconnects immediately

Check that your path in Claude Desktop config is correct
Make sure to use double backslashes (\\) in the JSON path
Verify your username is correct in the path

❌ "Permission denied" errors

Run PowerShell as Administrator
Or try installing in a different location (like your Documents folder)

Testing

Test the server with MCP Inspector:

npx @modelcontextprotocol/inspector python chronology_server.py

Tools Available

add_event - Add a single event to the chronology
parse_document - Extract events from document text
search_timeline - Search events by various criteria
get_timeline_summary - Get overview statistics
export_chronology - Export in different formats
update_event - Modify existing events
delete_event - Remove events from timeline

License

MIT

Available Tools

7 tools

add_eventC

Add a chronology event with automatic date parsing

ParametersJSON Schema

Name	Required	Description	Default
`date_string`	Yes
`description`	Yes
`parties`	Yes
`document_source`	No
`document_excerpt`	No
`tags`	No
`significance`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.9/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. It only mentions 'automatic date parsing' but lacks details on validation, failure modes, side effects, or required permissions.

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 a single, front-loaded sentence with no wasted words. It immediately conveys the core action and a key feature.

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 complexity (7 parameters, 3 required) and the presence of an output schema, the description is too minimal. It fails to provide sufficient context for correct usage, though the output schema partially compensates for return value documentation.

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

Parameters1/5

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

Schema description coverage is 0%. The description does not explain any of the 7 parameters, leaving their meaning and usage entirely undocumented.

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 action ('Add') and the resource ('chronology event'), and highlights a key feature ('automatic date parsing'). It effectively distinguishes itself from sibling tools like delete_event, update_event, etc.

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 (e.g., update_event), nor any context about prerequisites or typical usage scenarios.

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

delete_eventC

Delete a chronology event

ParametersJSON Schema

Name	Required	Description	Default
`event_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.3/5.0

Behavior1/5

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

No annotations are provided, so the description should disclose behavioral traits; it does not mention irreversibility, permissions, or what happens on success/failure.

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

Conciseness3/5

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

The description is extremely short (4 words) and lacks structure; while concise, it sacrifices necessary information.

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 simplicity (1 param, output schema exists), the description fails to cover behavioral details like return values or error handling.

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

Parameters1/5

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

Schema description coverage is 0% and the description adds no meaning to the 'event_id' parameter; it does not explain what it is or how to obtain it.

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 action ('delete') and the resource ('chronology event'), distinguishing it from sibling tools like add_event and update_event.

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

Usage Guidelines1/5

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

No guidance on when to use this tool versus alternatives like update_event, or any prerequisites (e.g., event must exist) are provided.

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

export_chronologyC

Export chronology in various formats

ParametersJSON Schema

Name	Required	Default
`format`	No	markdown
`include_documents`	No
`include_significance`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/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 does not disclose whether the tool is read-only or destructive, what side effects occur (e.g., file creation), or any authentication or authorization requirements. The phrase 'Export chronology' implies a read operation but provides no safety or 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.

Conciseness3/5

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

The description is a single sentence, which is concise. However, it omits critical details, making it under-specified rather than efficiently informative. The structure is simple but fails to front-load essential context.

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 presence of an output schema, the description could be shorter, but it still lacks context on when to call export_chronology instead of sibling tools, what output formats are available, and how parameters affect behavior. The description is incomplete relative to the tool's complexity (3 parameters, default values).

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

Parameters1/5

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

Schema description coverage is 0%, and the description provides no information about the three parameters (format, include_documents, include_significance). The agent must infer meanings from parameter names alone, which is insufficient for correct invocation.

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 'Export chronology', identifying the action and resource. However, it lacks specificity on what the export produces (e.g., downloadable file, data stream) and does not differentiate from siblings, which are event-specific operations.

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 on when to use this tool versus alternatives like get_timeline_summary or search_timeline. The description does not mention any prerequisites, typical use cases, or exclusion criteria.

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

get_timeline_summaryB

Get summary statistics about the chronology

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.3/5.0

Behavior2/5

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

No annotations exist, yet the description omits critical behavioral traits like what statistics are computed, any time range assumptions, or whether all events are included, leaving the agent to infer usage.

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

Conciseness3/5

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

The description is very brief and front-loaded, but could have been more informative about the output without becoming lengthy.

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 existence of an output schema, the description needn't specify return fields, but it fails to clarify the scope of the summary, which is important for a tool that aggregates events.

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?

No parameters exist, so the baseline is 4; while the description adds no semantic detail beyond 'summary statistics', it does not need to compensate for missing schema docs.

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 retrieves summary statistics about the chronology, which is a specific read-only aggregation operation distinct from siblings like add_event or update_event.

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 such as search_timeline or export_chronology, nor any context or prerequisites.

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

parse_documentC

Parse a document and extract potential chronology events

ParametersJSON Schema

Name	Required	Description	Default
`content`	Yes
`document_name`	Yes
`default_parties`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.4/5.0

Behavior1/5

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

The description lacks any behavioral details beyond the basic action. There is no mention of side effects, required permissions, whether events are automatically added, or what the tool returns. With no annotations provided, this is a critical gap.

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

Conciseness2/5

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

The description is extremely concise (one sentence, 9 words) but at the expense of necessary detail. It omits crucial information about parameters, behavior, and usage, making it under-specified rather than efficiently clear.

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 three parameters with no schema descriptions and no annotations, the description is insufficient for an agent to understand how to invoke it correctly. The output schema exists but is not referenced, and the description does not cover return values or typical use cases.

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

Parameters1/5

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

The description does not explain any of the three parameters (content, document_name, default_parties). With 0% schema description coverage, the description fails to add meaning beyond the schema, leaving the agent without guidance on how to use each parameter.

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 it parses a document and extracts potential chronology events, which is a specific verb+resource. It distinguishes from sibling tools like add_event, delete_event, etc., which manage events rather than extracting them from documents.

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. It does not mention contexts where parsing is appropriate, prerequisites, or when other tools might be better suited. The purpose is implied but not explicitly stated for usage.

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

search_timelineC

Search chronology by date range, parties, keywords, or tags

ParametersJSON Schema

Name	Required	Description	Default
`start_date`	No
`end_date`	No
`parties`	No
`keywords`	No
`tags`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

No annotations provided. Description does not disclose any behavioral traits such as read-only nature, return format, pagination, or limits. The sole sentence is insufficient for a search tool.

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?

Single sentence is very concise and front-loads purpose. However, it could be structured with more details in a compact form.

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?

Has output schema so return values are covered, but the description lacks completeness given 5 parameters and no annotations. No examples, constraints, or behavioral context. Inadequate for effective use.

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

Parameters2/5

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

Schema description coverage is 0%, so description must compensate. It mentions the four criteria but does not explain parameter formats, allowed values, or behavior. Adds minimal meaning beyond schema types.

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?

Description clearly states verb 'search' and resource 'chronology', and lists filtering criteria. However, it does not differentiate from sibling tools, though the siblings are mostly about event management.

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 on when to use this tool versus alternatives like get_timeline_summary or export_chronology. The description lacks usage context.

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

update_eventB

Update an existing chronology event

ParametersJSON Schema

Name	Required	Description	Default
`event_id`	Yes
`date_string`	No
`description`	No
`parties`	No
`significance`	No
`tags`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3/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 only states 'Update an existing chronology event' without explaining whether updates are partial or full, idempotency, required permissions, or error conditions. This is insufficient for a mutation tool.

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 extremely concise at one sentence, front-loading the core purpose. However, it may be too sparse; a bit more detail could be included without sacrificing efficiency.

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?

While an output schema exists (so return format is covered), the description fails to explain behavioral details like partial vs. full update, behavior when optional fields are null, or prerequisites. For a tool with 6 parameters and no annotations, this is incomplete.

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

Parameters1/5

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

Schema description coverage is 0%, yet the description adds no meaning to any of the 6 parameters. It does not explain what each parameter does, their constraints, or how they affect the update. The description fails to compensate for the lack of schema documentation.

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 'Update an existing chronology event' uses a specific verb ('Update') and clearly identifies the resource ('existing chronology event'). It effectively distinguishes this tool from siblings like add_event (create) and delete_event (remove).

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 usage when modifying an event, but provides no explicit context on when to use this tool versus alternatives or when not to use it. No exclusions or alternative tools are mentioned.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.2/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: add, delete, update events; export; get summary; parse documents; search. No overlap.

Naming Consistency5/5

All tool names follow the verb_noun pattern with snake_case (e.g., add_event, delete_event, parse_document). Consistent and predictable.

Tool Count5/5

7 tools is well-scoped for a chronology management server, covering essential operations without unnecessary bloat.

Completeness4/5

Covers CRUD (add, update, delete), search, export, summary, and document parsing. Missing a dedicated 'get_event' by ID, but search covers retrieval.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Codey 律所管理系統
com.thecodey
Law firm management MCP: manage cases, clients, tasks, calendar and documents via Claude AI.
Legal & Compliance Project Management Calendar Management
2
Lawstronaut A
com.lawstronaut
Connect AI to millions of laws and court cases with the Lawstronaut MCP.
Legal & Compliance Research & Data Web Scraping
1631
Agenda Intelligence MD A
io.github.vassiliylakhonin
Evidence-readiness MCP server: validate, audit, and score briefs, memos, and evidence packs.
Legal & Compliance Research & Data
116
transaction-coordinator A
io.github.GordonHal
AI transaction coordinator + legal-matters platform for real estate and law firms.
Real Estate Legal & Compliance
112

Related MCP Servers

FS-MCP Server
File Systems Vector Databases
boleyn
A
license
Not graded
quality
F
maintenance
A Model Context Protocol server that provides intelligent file reading and semantic search capabilities across multiple document formats with security-first access controls.
Updated a year ago (2025-06-04 09:16 UTC)
7
MIT
Writer MCP
Knowledge & Memory Vector Databases
huangjien
A
license
Not graded
quality
F
maintenance
A Model Context Protocol server that manages character knowledge and relationships for creative writing projects, offering semantic search and AI-powered analysis.
Updated a year ago (2025-07-05 19:17 UTC)
4
MIT
Jusratio Case File
Legal & Compliance File Systems
carlosvictorodrigues
A
license
B
quality
A
maintenance
Local-first MCP server that transforms civil case PDFs into queryable cases with structural provenance, evidence IDs, and page-level verification for drafting and factual review.
Updated 2 months ago (2026-07-09 03:05 UTC)
22
Apache 2.0
Business Data MCP
RAG Systems Search
Al-Rowads
F
license
Not graded
quality
B
maintenance
An evidence-first Model Context Protocol server for private business documents and structured datasets, preserving original files and source lineage.
Updated 2 months ago (2026-07-19 10:36 UTC)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/medelman17/case-chronology-mcp'

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