ArchLog MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| archlog_check_environmentA | Check the local ArchLog, ENRE-CPP, SemArc, Git, Java, data path, and LLM configuration without starting an analysis. |
| archlog_validate_requestA | Validate and normalize a GitHub C/C++ release range. This performs no checkout and starts no analysis. |
| archlog_start_analysisA | Start an asynchronous architecture-guided release-note analysis and return immediately with a persistent job ID. Poll with archlog_get_status; do not wait in this call. |
| archlog_get_status | Get persisted progress for an ArchLog job. A worker exit alone never means success; only state=succeeded with validated artifacts does. |
| archlog_get_result | Return local release-note and manifest paths only after validating every required Phase 1-3 success artifact. |
| archlog_get_failure_report | Return the truthful failure stage, error, recovery flag, and detailed local log path for a failed job. |
| archlog_resume_analysis | Resume a failed or cancelled job using its existing isolated job directory and checkpoints. |
| archlog_cleanup_intermediate_results | Permanently delete intermediate artifacts for one succeeded job, or all succeeded jobs when job_id is omitted. Retains the traceable release note and minimal MCP metadata. Requires confirm=true. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each tool has a clearly distinct purpose: starting an analysis, checking the environment, and validating a request. There is no overlap or ambiguity.
All tool names follow a consistent 'archlog_verb_noun' pattern, making them predictable and easy to understand.
Three tools are appropriate for the server's focused scope of architecture-guided release-note analysis, covering essential steps without being excessive or thin.
The set references a 'archlog_get_status' tool for polling, but it is missing from the provided tools. This is a significant gap that would cause agent failures when trying to retrieve analysis results.