Which integrations are available for this server?

Allows correlating log entries with git commits from a specified repository to provide context for incident reports. Enables correlation of log entries with tickets via configurable ticket ID patterns and produces Jira-paste-ready report summaries.

How do I use lograft?

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., "@lograft investigate recent error logs and correlate with git commits" 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.

lograft

by nano-step

Overview Schema Related Servers Score Discussions

TypeScript

Local

lograft

Raft together logs, code, and tickets into post-mortem-ready investigation reports.

lograft is an MCP server that turns raw log query results into structured incident reports — Markdown (paste-into-ticket), JSON (machine-readable), and self-contained HTML (share offline). It composes Microsoft's official @azure/mcp for live Azure Monitor queries, and contributes the parts MS does NOT solve: KQL parsing, log↔git↔ticket correlation, PII redaction, multi-format reporting.

Works in any MCP-compatible client: opencode, Cursor, Claude Desktop, VS Code GitHub Copilot, Windsurf, Zed, Continue.dev.

Status: beta (0.1.x)
License: MIT
Runtime: Node 20.10+

Quick start

npx lograft

That's it. The MCP server starts on stdio and waits for a client to call its tools.

To use lograft as a daily tool, install globally:

npm i -g lograft@beta
lograft   # starts MCP server on stdio

For live Azure mode, you also need @azure/mcp (auto-spawned via npx if absent, but installing it globally is faster):

npm i -g @azure/mcp@^2
az login   # azmcp handles all Azure auth

Related MCP server: ci-triage-mcp

What it does

Given Azure log query results (live or pasted) plus a git repo, lograft produces a single investigation bundle:

reports/<UTC-timestamp>/
├── report.md     # Jira-paste-ready summary + correlations
├── data.json     # machine-readable findings
└── report.html   # offline-viewable, self-contained, CSP-locked

Correlation joins are explicit-keys only: operation_Id, your configured ticket regex (e.g. [A-Z]+-\d+), and a service allowlist. Timestamp proximity is a tiebreaker, never a primary signal (no noise explosion).

Default-on PII redaction — emails, JWTs, GUIDs in auth context, Authorization headers, IPv4/IPv6, RFC1918 private ranges, internal hostnames (*.internal, *.corp, *.local). The redactor is internal middleware — there is no "skip redaction" tool surface.

MCP client setup

lograft speaks the MCP stdio transport. Below are the snippets for the four distinct config formats. Tested in opencode, Cursor, Claude Desktop; the other clients use one of these same formats — contributions welcome to confirm.

opencode (`opencode.json` or `~/.config/opencode/config.json`)

{
  "mcp": {
    "servers": {
      "lograft": {
        "command": "npx",
        "args": ["-y", "lograft@beta"]
      }
    }
  }
}

Claude Desktop family (`claude_desktop_config.json` / Cursor `mcp.json` / Windsurf / Zed)

{
  "mcpServers": {
    "lograft": {
      "command": "npx",
      "args": ["-y", "lograft@beta"]
    }
  }
}

Paths:

Claude Desktop (macOS): ~/Library/Application Support/Claude/claude_desktop_config.json
Claude Desktop (Windows): %APPDATA%\Claude\claude_desktop_config.json
Cursor: ~/.cursor/mcp.json (global) or .cursor/mcp.json (project)
Windsurf: ~/.codeium/windsurf/mcp_config.json
Zed: similar shape — see Zed docs

VS Code GitHub Copilot (`settings.json`)

{
  "chat.mcp.servers": {
    "lograft": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "lograft@beta"]
    }
  }
}

Continue.dev (`~/.continue/config.json`)

{
  "experimental": {
    "modelContextProtocolServers": [
      {
        "transport": {
          "type": "stdio",
          "command": "npx",
          "args": ["-y", "lograft@beta"]
        }
      }
    ]
  }
}

Tools

lograft exposes 5 fine-grained MCP tools plus 1 convenience orchestrator. Most users want lograft_investigate first. The atomic tools exist for partial pipelines.

Tool	Purpose
`lograft_investigate`	Full pipeline: parse → normalize → repo context → correlate → redact → render bundle. The tool most users want.
`lograft_parse_kql`	Pure: extract tables, time range, ticket mentions, projections from a KQL query.
`lograft_normalize`	Pure: turn CSV / JSON / azure-monitor-json into a unified 5-field rowset.
`lograft_gather_repo_context`	Shells out to `git log` for the last N days of commits.
`lograft_correlate`	The heart: joins rows ↔ commits ↔ tickets ↔ atoms via explicit keys only.
`lograft_render_report`	Writes md+json+html bundle. Redactor middleware runs on input — non-bypassable.

The redactor is NOT a public tool by design (plan D13). If it were optional via tool selection, a misbehaving LLM client could exfiltrate raw PII into a Jira paste. Bypassing requires explicit redaction.bypass: true on the render call and emits a prominent stderr warning.

Example — paste mode

You already have a Portal export CSV and want a report.

// Client calls lograft_investigate with:
{
  "result": {
    "kind": "inline",
    "format": "csv",
    "data": "timestamp,message,operation_Id,cloud_RoleName\n2026-05-22T13:58:00Z,InvalidSignature MYPROJ-42,op-1,PaymentService\n…"
  },
  "kql": {
    "kind": "inline",
    "text": "exceptions | where timestamp > ago(1h) | project timestamp, message, operation_Id"
  },
  "repoPath": "/path/to/your/repo",
  "outDir": "./reports"
}

Output:

reports/20260522-141023/
├── report.md
├── data.json
└── report.html

report.md opens with a ≤500-char headline summary block suitable for pasting into a ticket.

Example — live mode (delegates to azmcp)

{
  "kql": {
    "kind": "inline",
    "text": "AppExceptions | where TimeGenerated > ago(1h) | project TimeGenerated, Message, operation_Id"
  },
  "live": {
    "workspaceId": "<log-analytics-workspace-id>",
    "subscriptionId": "<subscription-id>",
    "table": "AppExceptions",
    "hours": 1
  },
  "repoPath": "/path/to/your/repo"
}

Under the hood lograft shells out to:

azmcp monitor workspace log query \
  --subscription <subscription-id> \
  --workspace <workspace-id> \
  --table AppExceptions \
  --query "AppExceptions | where ... " \
  --output json \
  --hours 1

All Azure credentials are handled by azmcp via Microsoft's DefaultAzureCredential chain — lograft never touches AZURE_* env vars itself. See Authentication docs.

If azmcp is missing, lograft returns a clear error with install instructions.

Configuration

Place an optional lograft.config.toml in your project root (or ~/.config/lograft/lograft.config.toml). Resolution order:

--configPath arg on lograft_investigate (explicit)
<MCP-process-cwd>/lograft.config.toml
~/.config/lograft/lograft.config.toml
Built-in defaults

See examples/lograft.generic-issue-tracker.toml for a starting template covering ticket regex, service allowlist, redaction extras, and ticket-link base URL.

Architecture

   ┌────────────────────────┐
   │  Any MCP Client (stdio) │
   └──────────┬─────────────┘
              │
              ▼
   ┌─────────────────────────────────┐
   │  lograft (this package)          │
   │   parse_kql ─┐                   │
   │   normalize ─┼─► correlate ─┐    │
   │   gather    ─┘              │    │
   │                   redactor  │    │   ← internal middleware (D13)
   │                             ▼    │
   │                       render md/json/html
   └─────────────────────┬───────────┘
                         │ subprocess (live mode only)
                         ▼
            ┌──────────────────────────────┐
            │  azmcp (microsoft/mcp, GA)    │
            │  Owns Azure auth + KQL exec.  │
            └──────────────────────────────┘

Trust boundaries:

lograft never holds Azure credentials. Live mode = subprocess to azmcp.
The redactor is the SOLE chokepoint between log content and any output file.
stdout is reserved for MCP JSON-RPC. All logs go to stderr. A runtime guard throws if anything else writes to stdout.

Caps and defaults

Setting	Default	Rationale
Max correlated rows	1000	bounded report size
Max commits considered	200	bounded git log
Max output file size	5 MB	bounded share-ability
Tiebreaker window	±10 min	timestamp proximity, AFTER key match
`azmcp` subprocess timeout	5 min	bounded live mode
Repo lookback	14 days	recent context only

All are TOML-configurable; none are removable.

Roadmap (Phase 2)

Datadog / CloudWatch / Loki / Elastic LogSourceAdapter implementations
Slack / Teams webhook output
Live Jira / GitHub API ticket enrichment (replaces regex-only extraction)
Public MCP registry submission to modelcontextprotocol.io
Multi-query batch mode
lograft_preview_redaction tool — read-only diff for audit

Contributing

Pull requests are welcome — especially new LogSourceAdapter implementations.

Before submitting:

pnpm install
pnpm test
pnpm typecheck
pnpm lint
pnpm build

See CONTRIBUTING.md for adapter contracts and commit conventions.

Security reports: do not open public issues. See SECURITY.md.

License

MIT © Hoài Nhớ

Available Tools

5 tools

lograft_correlateA

Join a NormalizedRowset against a RepoContext using explicit keys (operation_Id, configured ticket regex, service allowlist). Output is redacted via the internal middleware before being returned. Most users want lograft_investigate; this atomic tool is for partial pipelines.

ParametersJSON Schema

Name	Required	Description	Default
`rowset`	Yes
`repoContext`	Yes
`joinPolicy`	Yes
`externalAtoms`	No
`sessionId`	No

TDQS

A4.4/5.0

Behavior4/5

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

Discloses that 'Output is redacted via the internal middleware before being returned,' which is a key behavioral trait beyond what the schema conveys. With no annotations provided, this description adds value. However, it does not explicitly state whether the tool is read-only or if it has side effects, leaving some gap.

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?

Three sentences with no wasted words. The first sentence states the primary function, the second adds behavioral context, and the third provides usage guidance. Information is front-loaded and every sentence contributes.

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?

Given the tool's complexity (5 parameters, nested objects, no output schema), the description covers purpose, usage guidelines, and a behavioral detail (redaction). It does not explain return value structure or all parameters (e.g., externalAtoms, sessionId), but it is reasonably complete for an atomic pipeline tool, especially with sibling tool context.

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 0%, so the description must compensate. It explains the core parameters (rowset, repoContext, joinPolicy) by describing the join operation and listing the explicit keys. However, it does not explain the externalAtoms or sessionId parameters, nor does it provide details about the rowset's inline/ref structure. The description adds some meaning but is incomplete.

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: 'Join a NormalizedRowset against a RepoContext using explicit keys (operation_Id, configured ticket regex, service allowlist).' It specifies the verb (join), the resources (NormalizedRowset, RepoContext), and the key criteria. It also distinguishes itself from the sibling tool lograft_investigate, which is the preferred tool for most users.

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 guides when to use: 'Most users want lograft_investigate; this atomic tool is for partial pipelines.' This tells the agent to prefer lograft_investigate unless working on partial pipelines, providing clear when-not-to-use and an alternative.

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

lograft_gather_repo_contextA

Snapshot a git repository's recent commits (default: last 14 days, max 200 commits) plus current branch and origin URL. Pure read-only, shells out to git. Most users want lograft_investigate; this atomic tool is for partial pipelines.

ParametersJSON Schema

Name	Required	Description	Default
`repoPath`	Yes
`sinceDays`	No
`maxCommits`	No

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations, the description fully carries the burden. It declares the tool is pure read-only and shells out to git, which are important behavioral traits. No contradictions.

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: the first explains the function with limits, the second provides usage guidance. No wasted words, front-loaded with key info.

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?

For a simple tool with 3 parameters and no output schema, the description adequately covers purpose, limits, usage, and read-only nature. Lacks explicit output structure but is still comprehensive given low complexity.

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 0%, so the description must compensate. It mentions the default for sinceDays (14 days) and maxCommits (200), but does not fully explain repoPath or provide detailed parameter semantics beyond these defaults. Adds some but not complete value.

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 gathers a snapshot of recent commits, current branch, and origin URL from a git repository. It distinguishes itself from the sibling tool lograft_investigate, indicating this is for partial pipelines.

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 states that most users should use lograft_investigate, and this tool is atomic for partial pipelines. Also provides defaults and maximum limits (14 days, 200 commits) for when to use.

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

lograft_investigateA

Run the full investigation pipeline in one call: parse KQL (optional) -> normalize -> gather repo context -> correlate -> redact -> render md+json+html bundle. Either pass result={inline|path} (paste mode) OR live={workspace,subscription,table,...} (delegates to azmcp). Returns a Bundle with paths to the written files. This is the tool most users want first.

ParametersJSON Schema

Name	Required	Description	Default
`kql`	No
`result`	No
`live`	No
`repoPath`	Yes
`outDir`	No
`configPath`	No
`ticketLinkBase`	No
`sessionId`	No

TDQS

A4.1/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It mentions the pipeline steps, redaction, and delegation to azmcp for live mode, but does not cover destructive actions, authentication requirements, rate limits, or side effects. The behavioral traits disclosed are adequate but not exhaustive.

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 three sentences long, with no superfluous information. The first sentence lists the pipeline steps, the second explains modes, and the third gives a recommendation. It is front-loaded with essential information.

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?

There is no output schema, so the description must explain return values. It states 'Returns a Bundle with paths to the written files,' which is basic. Given the complexity (8 parameters, nested objects, two modes), it could provide more detail about the bundle contents or output structure.

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 schema has 0% description coverage, so the description must compensate. It explains the two mode parameters ('result' and 'live') and their sub-fields, making the combination clear. It also notes that KQL parsing is optional. While not every parameter is detailed, the description adds significant meaning beyond the raw 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?

The description clearly states the tool runs the full investigation pipeline, listing specific steps (parse KQL, normalize, gather repo context, correlate, redact, render) and two modes. It distinguishes itself from sibling tools by calling itself 'the tool most users want first.'

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?

The description explains two usage modes: paste mode via the 'result' parameter and live mode via the 'live' parameter. It explicitly says 'Either pass result=... OR live=...' and recommends it as the first tool to try. However, it does not explicitly state when not to use it or mention alternatives beyond the sibling tools.

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

lograft_normalizeA

Normalise a CSV / JSON / Azure-Monitor-JSON log export into a 5-field rowset (timestamp, level, message, source, raw). Pass sessionId to receive an opaque rowsetRef for downstream lograft_correlate calls (avoids re-shipping large payloads through MCP). Most users want lograft_investigate; this atomic tool is for partial pipelines.

ParametersJSON Schema

Name	Required	Description	Default
`source`	Yes
`payload`	Yes
`sessionId`	No
`rowCap`	No

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses core behavior (normalization, output rowset fields, sessionId ref) and notes optimization (avoids re-shipping), but doesn't cover potential side effects or read-only nature.

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?

Three sentences front-load the purpose, cover key details, and add sibling differentiation without redundancy.

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 no annotations, no output schema, and four params including a nested oneOf, the description omits output format details (other than rowsetRef), error handling, and parameter constraints, making it incomplete for reliable agent 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%; description only mentions sessionId purpose. Does not explain source enum values, payload structure (inline vs path), or rowCap constraints, leaving significant gaps.

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 normalizes log exports into a specific 5-field rowset, lists supported input formats, and distinguishes itself from the primary sibling tool lograft_investigate.

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 advises that most users want lograft_investigate and this tool is for partial pipelines, providing clear when-to-use and when-not-to-use guidance. Also explains sessionId usage for downstream correlation.

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

lograft_parse_kqlA

Extract structural facts from a Kusto Query Language (KQL) query without executing it. Returns the referenced tables, projected columns, time range, and ticket mentions. Most users want lograft_investigate; use this atomic tool only when you need partial pipeline output. Pure compute, no side effects, no network.

ParametersJSON Schema

Name	Required	Description	Default
`kqlText`	Yes
`ticketRegex`	No

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations provided, the description carries full burden. It states 'Pure compute, no side effects, no network' and 'without executing it', making behavioral traits clear.

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?

Three sentences, each earning its place: purpose with key fact, outputs list, usage guidance, and safety. No wasted words.

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?

Given no annotations or output schema, the description covers purpose, behavior, and usage. It lists returned fields but does not specify output format, e.g., JSON structure. Slight gap but complete enough for its simplicity.

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 has 0% description coverage, so description must compensate. It implies kqlText is the query and ticketRegex is for ticket mentions, but does not explicitly define ticketRegex or provide format. Some value added but incomplete.

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 extracts structural facts from a KQL query without executing it, and distinguishes itself from the sibling lograft_investigate by noting it is for partial pipeline output.

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 says when to use this tool vs the alternative: 'Most users want lograft_investigate; use this atomic tool only when you need partial pipeline output.' Provides clear context.

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.

5 tool updatesv0.1.0-beta.2Jun 12, 2026
- First observedlograft_correlate
- First observedlograft_gather_repo_context
- First observedlograft_investigate
- First observedlograft_normalize
- First observedlograft_parse_kql

Install Server

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

TDQS

A4.5/5.0

Disambiguation5/5

Each tool targets a distinct step in the investigation pipeline, with explicit guidance that most users should start with lograft_investigate. The atomic tools (parse_kql, normalize, gather_repo_context, correlate) have no overlapping purposes.

Naming Consistency5/5

All tools share the lograft_ prefix and use clear verb_noun or verb patterns (e.g., parse_kql, gather_repo_context, investigate). The naming is uniform and predictable.

Tool Count5/5

Five tools is an ideal count for this domain—neither too few nor too many. Each atomic tool serves a specific need, and the full pipeline tool ties them together efficiently.

Completeness5/5

The pipeline is fully covered: parsing KQL, normalizing logs, gathering repo context, correlating, and generating a final bundle. There are no obvious gaps for the stated purpose of log investigation.

Maintenance

ActivityStale

ResponsivenessUnresponsive

Resources

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

Cortex
tv.tootie
Syslog receiver and MCP server for homelab log intelligence.
Observability Monitoring
23
Syslog MCP
tv.tootie
Syslog receiver and MCP server for homelab log intelligence.
Monitoring Observability
23
forkast-mcp-docs A
io.github.ForkastPredict
MCP server for querying Forkast documentation
Documentation Access Search Developer Tools
42
siGit
si.sigit
MCP server for siGit (sigit.si): browse repos, search code, manage PRs/issues, web search.
Version Control Developer Tools
221

Related MCP Servers

Incident Triage MCP
Monitoring Observability
felixkwasisarpong
A
license
C
quality
C
maintenance
Incident Triage MCP is a Model Context Protocol (MCP) server for incident triage. It provides safe, auditable tools for evidence retrieval, deterministic summaries, ticket workflows, and notifications.
Updated a month ago (2026-08-03 06:10 UTC)
28
Apache 2.0
ci-triage-mcp
CI/CD & DevOps Developer Tools Version Control
aamar-shahzad
A
license
A
quality
C
maintenance
MCP server for GitHub Actions CI failure triage. It wraps the gh CLI to fetch PR checks, failed jobs, and tail/grep failed job logs with ANSI/timestamp stripping and root-cause extraction.
Updated 2 months ago (2026-07-10 15:22 UTC)
5
MIT
elastic-mcp
Monitoring Observability
jrvalinas
A
license
Not graded
quality
D
maintenance
Small production-oriented MCP server for diagnosing incidents from Elasticsearch logs with unknown schema. It provides tools for log discovery, retrieval, and issue diagnosis.
Updated 6 months ago (2026-03-10 22:13 UTC)
MIT
ticket-forge
SanjoyDat1
-
license
Not graded
quality
Not graded
maintenance
MCP server that parses stack traces and logs to generate deduplicated issue drafts with severity, repro steps, and owner guesses.
Updated a month ago (2026-07-23 00:26 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/nano-step/lograft'

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

lograft

Quick start

What it does

MCP client setup

opencode (opencode.json or ~/.config/opencode/config.json)

Claude Desktop family (claude_desktop_config.json / Cursor mcp.json / Windsurf / Zed)

VS Code GitHub Copilot (settings.json)

Continue.dev (~/.continue/config.json)

Tools

Example — paste mode

Example — live mode (delegates to azmcp)

Configuration

Architecture

Caps and defaults

Roadmap (Phase 2)

Contributing

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

opencode (`opencode.json` or `~/.config/opencode/config.json`)

Claude Desktop family (`claude_desktop_config.json` / Cursor `mcp.json` / Windsurf / Zed)

VS Code GitHub Copilot (`settings.json`)

Continue.dev (`~/.continue/config.json`)