Skip to main content
Glama
DavidDominguez-11

construction-supervision-mcp

by DavidDominguez-11
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

Construction Supervision MCP Server

A specialized, local Model Context Protocol (MCP) server providing construction-supervision tools for small-to-medium building projects:

  • Houses

  • Small buildings

  • Offices

  • Commercial spaces

Built in Python 3.12 following the standard MCP specifications and JSON-RPC 2.0 directly over standard input and standard output (stdio), without using any third-party MCP SDK or server library.

Features & Implemented Tools

The server implements all 5 core construction supervision tools required by the specification:

  1. get_stage_guidance

    • Provides detailed guidance for any of the 9 supported construction stages and 4 project types.

    • Includes prerequisites, materials with typical quantities per m², main activities, critical supervision checkpoints, common mistakes, safety notes, and related stages.

  2. generate_supervision_checklist

    • Generates actionable, prioritized (critical, important, recommended) inspection checklists for each stage across three project moments: before, during, and after.

  3. record_project_progress

    • Records and updates stage progress (not_started, in_progress, completed, blocked) with notes in a local SQLite database (project_progress.db).

  4. get_next_possible_stages

    • Evaluates recorded project status against strict domain dependency trees stored in structured JSON data (not hallucinated).

    • Identifies stages ready to start, missing prerequisites holding back progress, and suggested pre-stage verification points.

  5. analyze_quotation

    • Analyzes construction material and labor line items against standard reference concepts and price ranges.

    • Detects recognized concepts, potentially missing items, duplicate entries, items priced below/within/above expected ranges, and unclassified entries.

    • Emits appropriate non-binding reference disclaimers.

Related MCP server: Kolmo Construction

Supported Construction Stages

The server manages 9 defined construction stages with realistic sequence dependencies:

  1. site_preparation

  2. foundations (prerequisite: site_preparation)

  3. structural_elements (prerequisite: foundations)

  4. masonry_walls (prerequisite: structural_elements)

  5. electrical_installations (prerequisite: masonry_walls)

  6. plumbing_installations (prerequisite: masonry_walls)

  7. plastering_and_finishes (prerequisites: masonry_walls, electrical_installations, plumbing_installations)

  8. flooring_and_cladding (prerequisite: plastering_and_finishes)

  9. painting_and_handover (prerequisite: flooring_and_cladding)

Supported project types:

  • house

  • small_building

  • office

  • commercial_space

Installation & Prerequisites

Prerequisites

  • Python 3.12+

  • Git

Setup

  1. Clone the repository and navigate into the folder:

    git clone <repository_url>
cd construction-supervision-mcp

  2. Create and activate a Python 3.12 virtual environment:

    # Windows PowerShell
python -m venv .venv
.venv\Scripts\Activate.ps1

# Linux / macOS
python3 -m venv .venv
source .venv/bin/activate

  3. Install the package in editable mode with development dependencies:

    pip install -e ".[dev]"

Running the Server Locally

The server communicates via standard input (stdin) and standard output (stdout). Diagnostics are sent strictly to standard error (stderr).

Run directly:

python -m construction_supervision_mcp

Or via the installed entry-point script:

construction-supervision-mcp

Environment Configuration

Optionally configure the database path via an environment variable (see .env.example):

# Windows PowerShell
$env:PROGRESS_DB_PATH = "my_custom_progress.db"

# Linux / macOS
export PROGRESS_DB_PATH="my_custom_progress.db"

Configuring in an MCP Host

To use this server in an MCP host (such as Claude Desktop, Cursor, or custom terminal chatbot hosts), add the server definition to your client's MCP configuration JSON.

Claude Desktop Configuration Example

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "construction-supervision": {
      "command": "C:\\path\\to\\construction-supervision-mcp\\.venv\\Scripts\\python.exe",
      "args": [
        "-m",
        "construction_supervision_mcp"
      ],
      "env": {
        "PROGRESS_DB_PATH": "C:\\path\\to\\construction-supervision-mcp\\project_progress.db"
      }
    }
  }
}

Tool Specifications & Parameters

1. get_stage_guidance

Returns domain knowledge and specifications for a construction stage.

  • Parameters:

    • stage_id (string, required): One of the 9 supported stage identifiers.

    • project_type (string, required): One of house, small_building, office, commercial_space.

  • Result Schema:

    • Object containing id, name, description, project_types, prerequisites, materials, activities, supervision_points, common_mistakes, safety_notes, and related_stages.

2. generate_supervision_checklist

Generates a checklist for site inspection.

  • Parameters:

    • stage_id (string, required): Stage identifier.

    • moment (string, required): "before", "during", or "after".

  • Result Schema:

    • Object containing stage_id, stage_name, moment, and items (array of objects with item, priority, and explanation).

3. record_project_progress

Saves or updates the progress state for a stage in SQLite.

  • Parameters:

    • project_id (string, required): Unique project identifier.

    • stage_id (string, required): Stage identifier.

    • status (string, required): "not_started", "in_progress", "completed", or "blocked".

    • notes (string, optional): Notes on progress or inspection findings.

  • Result Schema:

    • Object confirming project_id, stage_id, status, notes, and updated_at (ISO 8601 UTC timestamp).

4. get_next_possible_stages

Evaluates database stage statuses against defined dependency rules.

  • Parameters:

    • project_id (string, required): Project identifier.

  • Result Schema:

    • Object containing:

      • completed_stages: List of completed stage records.

      • in_progress_stages: List of currently in-progress stages.

      • blocked_stages: List of blocked stages.

      • possible_next_stages: Stages whose prerequisites are fully met.

      • stages_with_missing_prerequisites: Stages blocked by uncompleted prerequisites.

      • suggested_verifications: Checkpoints to verify before beginning upcoming stages.

5. analyze_quotation

Analyzes quotation line items against reference concepts and price brackets.

  • Parameters:

    • project_type (string, required): Project type.

    • work_category (string, required): Category matching one of the construction stages.

    • items (array, required): Array of item objects, each containing:

      • description (string)

      • unit (string)

      • quantity (number)

      • unit_price (number, in Guatemalan Quetzales [GTQ])

  • Result Schema:

    • Object containing:

      • project_type: Project type identifier.

      • work_category: Work category identifier.

      • reference_currency: Reference currency code ("GTQ").

      • recognized_items: Matched items with reference_range (in GTQ) and price_status (below_range, within_range, above_range).

      • potentially_missing_concepts: Standard concepts not found in quotation.

      • potentially_duplicated_concepts: Reference concepts matched by multiple items.

      • unclassified_items: Items that could not be matched with reference keywords.

      • observations: Summary findings.

      • disclaimer: Reference pricing notice.

Example JSON-RPC Exchanges

1. Initialize Handshake

Request:

{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18"}}

Response:

{"jsonrpc":"2.0","result":{"protocolVersion":"2025-06-18","capabilities":{"tools":{"listChanged":false}},"serverInfo":{"name":"construction-supervision-mcp","version":"0.1.0"}},"id":1}

2. Initialized Notification

Notification:

{"jsonrpc":"2.0","method":"notifications/initialized"}

(No response emitted)

3. List Tools

Request:

{"jsonrpc":"2.0","id":2,"method":"tools/list"}

Response:

{"jsonrpc":"2.0","result":{"tools":[{"name":"get_stage_guidance",...}]},"id":2}

4. Call Tool (record_project_progress)

Request:

{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"record_project_progress","arguments":{"project_id":"house-01","stage_id":"site_preparation","status":"completed","notes":"Clearing finished"}}}

Response:

{"jsonrpc":"2.0","result":{"content":[{"type":"text","text":"{\"project_id\":\"house-01\",\"stage_id\":\"site_preparation\",\"status\":\"completed\",\"notes\":\"Clearing finished\",\"updated_at\":\"...\"}"}]},"id":3}

Testing

Run the automated test suite using pytest:

pytest -v

The test suite covers:

  • JSON-RPC 2.0 protocol message validation, parsing, errors, and serialization (test_protocol.py).

  • MCP lifecycle methods: initialize, notifications/initialized, tools/list, and unknown method handling (test_server_lifecycle.py).

  • All five tools with valid inputs, invalid parameters, unknown stages, and quotation edge cases (test_tools.py).

  • SQLite persistence validation and prerequisite sequence dependency verification.

  • End-to-end stdio streaming test ensuring stdout contains strictly valid JSON-RPC lines without diagnostic pollution (test_stdio_e2e.py).

Price-Reference Disclaimer & Limitations

WARNING

Reference price ranges and standard concepts provided by this server are based on typical construction estimates in Guatemalan Quetzales (GTQ) for academic course demonstration purposes only. They do not represent real-time market prices or vendor quotes. Actual construction costs vary substantially depending on local labor rates, material quality, geographical location, site topography, supplier relationships, inflation, and seasonal conditions.

This tool does not provide legal, financial, architectural, or structural engineering certification or warranty.

Available Tools

5 tools
analyze_quotationA

Analyzes a material or labor quotation against reference concepts, detecting missing items, duplicates, and prices outside reference ranges.

ParametersJSON Schema
NameRequiredDescriptionDefault
itemsYesList of quotation line items.
project_typeYesThe type of construction project.
work_categoryYesWork category matching a construction stage.

TDQS

A3.9/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 the full transparency burden. It discloses what the tool detects (missing items, duplicates, out-of-range prices), which implies read-only analytical behavior, but it does not explain return format, error behavior, or assumptions about reference concepts.

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, information-dense sentence with no filler. The main purpose is front-loaded and the detection outcomes follow immediately, making it easy to scan and parse.

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?

Inputs are fully covered by the schema and the tool's conceptual scope is clear. However, since there is no output schema and no annotations, the description omits the result structure and any caveats about how reference concepts or ranges are determined, leaving a moderate completeness gap.

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 100%, so the schema already documents all parameters. The description adds no per-parameter meaning beyond framing the overall analysis, so the 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 uses a specific verb 'Analyzes' and clearly identifies the resource: 'a material or labor quotation against reference concepts.' It further specifies concrete detection targets (missing items, duplicates, out-of-range prices), which distinguishes it unambiguously from the sibling tools about stages, checklists, and progress.

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 makes the tool's context clear: use it when a quotation needs analysis. Since none of the sibling tools perform quotation analysis, selection is unambiguous. It does not explicitly state when not to use it or name alternatives, but the context is sufficiently clear.

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

generate_supervision_checklistB

Generates a supervision checklist for a construction stage at a specific moment (before, during, or after).

ParametersJSON Schema
NameRequiredDescriptionDefault
momentYesSupervision moment: before, during, or after the stage.
stage_idYesThe construction stage identifier.

TDQS

B3.3/5.0
Behavior2/5

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It only says the tool 'generates' a checklist, without revealing whether this operation is read-only, whether it has side effects, whether it requires any prerequisites, or what the checklist contents depend on beyond the two parameters.

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 sentence, concise and front-loaded with the core action and resource. Every word contributes meaning, and there is no redundant or filler content.

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?

For a tool with only two simple enum parameters, the description is mostly adequate, but it does not address output format, behavioral side effects, or selection guidance among siblings. Since there is no output schema and the interaction with get_stage_guidance is unclear, the description leaves some practical usage context missing.

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 100%, and both parameters have enum descriptions that fully explain their meaning. The description adds no extra semantic detail beyond what the schema already provides, so a baseline score of 3 is appropriate.

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 a specific verb ('Generates') and a specific resource ('supervision checklist for a construction stage'), and it also narrows the scope with 'at a specific moment (before, during, or after).' It does not explicitly distinguish itself from the sibling tool get_stage_guidance, which might overlap in purpose since both could provide stage-related information.

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 when to use the tool: whenever a supervision checklist for a construction stage is needed at a particular moment. However, it provides no explicit guidance about when not to use it or how it compares to alternatives like get_stage_guidance or get_next_possible_stages.

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

get_next_possible_stagesA

Reviews stored project progress and identifies which stages can be started next based on prerequisite dependencies.

ParametersJSON Schema
NameRequiredDescriptionDefault
project_idYesUnique identifier for the project.

TDQS

A3.9/5.0
Behavior3/5

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

With no annotations, the description must carry the behavioral burden. 'Reviews' and 'identifies' imply a non-mutating analysis, but the description never explicitly states that it makes no changes to project progress, nor does it mention what it returns (e.g., a list of stage identifiers) or edge cases. It adds the prerequisite-dependency rule, but not enough to be fully transparent.

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 entire description is a single 18-word sentence that front-loads the action ('Reviews stored project progress') before the outcome. Every word contributes; there is no filler, redundant context, or repetition of the tool name.

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?

For a one-parameter read-style tool, the description covers the essential purpose and prerequisite logic. However, with no output schema and no annotations, it leaves the return format unspecified and doesn't mention empty results or invalid project_id behavior, so it's not fully complete.

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 input schema already provides full documentation for project_id (100% coverage), so the baseline is 3. The description only connects project_id to 'stored project progress' without adding format, validation, or relationship details, so it does not elevate the score.

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 begins with a specific verb ('Reviews') and resource ('stored project progress'), then states the precise outcome ('identifies which stages can be started next based on prerequisite dependencies'). This clearly distinguishes it from siblings like record_project_progress (a write operation) and get_stage_guidance (guidance, not planning).

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?

It communicates the trigger condition: when you need to know which stages are available next given stored progress and prerequisite dependencies. It doesn't explicitly name alternatives or exclusions, but the context is clear enough for an agent to select it over the write-oriented record_project_progress.

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

get_stage_guidanceA

Returns detailed guidance for a construction stage, including description, prerequisites, materials, activities, supervision points, common mistakes, and safety notes.

ParametersJSON Schema
NameRequiredDescriptionDefault
stage_idYesThe construction stage identifier.
project_typeYesThe type of construction project.

TDQS

A4/5.0
Behavior4/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. It clearly states what the tool returns—description, prerequisites, materials, activities, supervision points, common mistakes, and safety notes—which gives a strong sense of behavior. It does not discuss error cases or explicitly confirm read-only behavior, but the "Returns" framing and tool name are sufficient for this simple read 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 a single, well-structured sentence. It fronts the primary purpose and then provides a clear list of content categories without unnecessary words or redundancy.

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 tool with two required enum parameters and no output schema, the description provides enough detail about the return content to guide correct invocation. It does not mention how project_type might affect the guidance or how invalid combinations are handled, but that is a minor gap for a read-only guidance tool.

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 100%, and both parameters have enum definitions with basic descriptions. The tool description does not add extra meaning about how stage_id or project_type interact with the returned guidance, so the schema carries the parameter semantic burden.

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 uses a specific verb, 'Returns', and clearly identifies the resource as 'detailed guidance for a construction stage'. It enumerates the types of content returned, which distinguishes it from siblings like generate_supervision_checklist and get_next_possible_stages.

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 when to use the tool: when an agent needs detailed guidance about a construction stage. However, it does not explicitly state when not to use it or name alternatives such as generate_supervision_checklist or get_next_possible_stages.

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

record_project_progressA

Records or updates progress for one stage of a construction project. Persists data in SQLite.

ParametersJSON Schema
NameRequiredDescriptionDefault
notesNoOptional notes about the progress update.
statusYesCurrent status of the stage.
stage_idYesThe construction stage identifier.
project_idYesUnique identifier for the project.

TDQS

A4/5.0
Behavior3/5

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

No annotations are provided, so the description itself must disclose behavior. It does disclose the persistence side effect in SQLite and implies an upsert-like behavior with 'Records or updates'. However, it does not clarify whether existing records are overwritten, what validations apply, or what the tool returns after a write, leaving some behavioral ambiguity.

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 two short sentences with no filler. The primary action and scope are front-loaded, and the persistence fact is the only extra detail included. Every sentence earns its place.

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 low-complexity tool with a fully documented schema, the description provides the essential persistence context and scope. The main gaps are the lack of explicit create-vs-update semantics and no mention of return values, but these are minor given the schema coverage and simple operation.

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 100%, so the parameters are already well-documented in the schema. The description adds no extra parameter-level meaning; it only references 'progress' and 'one stage,' which maps to the schema but provides no additional detail beyond 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 uses the specific verbs 'Records or updates' and identifies the exact resource: progress for one stage of a construction project. This clearly distinguishes it from sibling tools like get_stage_guidance or analyze_quotation. The additional note 'Persists data in SQLite' reinforces that this is a write operation, making the purpose unambiguous.

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 gives clear context for when the tool is appropriate: when a single stage's progress must be recorded or updated and persisted. It does not explicitly mention alternatives or exclusions, but the sibling tools are obviously different in scope, so an agent can infer the right choice without confusion.

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. 5 tool updatesv0.1.0
    • First observedanalyze_quotation
    • First observedgenerate_supervision_checklist
    • First observedget_next_possible_stages
    • First observedget_stage_guidance
    • First observedrecord_project_progress
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0
Disambiguation5/5

Each tool targets a distinct task: guidance retrieval, checklist generation, progress recording, next-stage determination, and quotation analysis. The two stage-related tools are clearly differentiated by output type and purpose.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case, such as get_stage_guidance, record_project_progress, and analyze_quotation. There are no mixed conventions or vague verbs.

Tool Count5/5

Five tools is well-scoped for a construction supervision server. Each tool addresses a meaningful part of the supervision workflow without redundancy or bloat.

Completeness4/5

The core supervision workflow is covered: guidance, checklists, progress recording, next-stage planning, and quotation analysis. Minor gaps exist around explicit project progress retrieval and project initialization, but these can be worked around in most cases.

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

  • ClaudeHopper

    Arborist-ai
    A
    license
    Not graded
    quality
    D
    maintenance
    AI-powered MCP server that enables Claude and other LLMs to interact directly with construction documents, drawings, and specifications through advanced RAG and hybrid search capabilities.
    9
    MIT

  • Kolmo Construction

    Kolmo-Construction
    A
    license
    Not graded
    quality
    C
    maintenance
    MCP server providing 12 tools for Seattle-area home remodeling: real-time cost estimation across 8 project types, contractor business info, project portfolio, blog content, and quote submission. Connects via Streamable HTTP — no auth required.
    MIT

  • project-mcp

    Gonzo3030
    A
    license
    Not graded
    quality
    C
    maintenance
    MCP server that enables LLMs to read and analyze Microsoft Project schedules, including critical path, resources, and advanced construction planning layers (AWP and LPS) for work packages and Lean planning.
    MIT

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/DavidDominguez-11/construction-supervision-mcp'

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