Skip to main content
Glama
phasetdev

Phaset Manifest Generator MCP

Official
by phasetdev
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

Phaset Manifest Generator MCP

AI-assisted Phaset manifest generation using Model Context Protocol.

A minimal MCP server that leverages Claude's intelligence to generate phaset.manifest.json files by analyzing your repository.

This may or may not work with other MCP-compatible tools, such as ChatGPT, but no testing has been done for anything other than Claude.

Quick Start

Prerequisites

You will need to have Node.js installed.

Configuration

Claude Desktop

(macOS): Edit ~/Library/Application Support/Claude/claude_desktop_config.json

(Windows): Edit %APPDATA%\Claude\claude_desktop_config.json

Add:

{
  "mcpServers": {
    "phaset": {
      "command": "npx",
      "args": ["-y", "phaset-mcp"]
    }
  }
}

Restart Claude Desktop completely.

Claude Code

Add the below to .claude.json:

{
  "mcpServers": {
    "phaset": {
      "command": "npx",
      "args": ["-y", "phaset-mcp"]
    }
  }
}

CLI

Run:

claude mcp add phaset -- npx -y phaset-mcp

Usage

In Claude Desktop:

Generate a Phaset manifest for /path/to/your/project

Claude will:

  1. Collect relevant files (package.json, README, Dockerfile, etc.)

  2. Analyze your project structure

  3. Generate a manifest with confidence annotations

  4. Mark fields requiring manual input as TODO

Related MCP server: shieldbot

Key Features

  • 100% Phaset Compliant: Generated manifests strictly conform to the Phaset schema

  • Smart analysis: Leverages Claude's native understanding of code and configs

  • Helpful notes: Inference notes are presented as complementary text

  • Multiple depth levels: Choose minimal, standard, or deep file analysis

  • Language agnostic: Works with any language Claude understands

Available Tools

get_phaset_schema

Returns the Phaset integration API schema so Claude understands the manifest structure.

collect_repo_files

Intelligently gathers relevant files from a repository based on depth:

  • minimal: Package manifests and README only

  • standard: Adds Dockerfiles, CI/CD configs, API specs

  • deep: Includes infrastructure configs (Terraform, Kubernetes)

suggest_manifest

Orchestrates the full workflow: retrieves schema, collects files, and generates a complete manifest draft.

Architecture

┌─────────────────┐
│   User's IDE    │
│   (Claude Code) │
└────────┬────────┘
         │
         ▼
┌──────────────────────────┐
│ Phaset MCP Server        │
│ • get_phaset_schema()    │
│ • collect_repo_files()   │
│ • suggest_manifest()     │
└────────┬─────────────────┘
         │
         ▼
┌──────────────────────────┐
│ Claude (via MCP)         │
│ • Analyzes files         │
│ • Generates manifest     │
│ • Provides confidence    │
└──────────────────────────┘

What Gets Generated

High Confidence Fields ✅

Claude can reliably infer:

  • name, description, version (from package files)

  • kind (api/service/library/component)

  • sourcingModel (custom vs open source)

  • deploymentModel (cloud/saas/on-premises)

  • tags (detected languages and frameworks)

  • api definitions (from OpenAPI/Swagger specs)

  • External dependencies

Requires Manual Input ⚠️

Fields marked as TODO:

  • repo (your Phaset org/record format)

  • group, system, domain (organizational IDs)

  • dataSensitivity, businessCriticality (business decisions)

  • dependencies.target (Phaset Record IDs)

  • slo, baseline, metadata

Example Output

The generated response includes two parts: a valid JSON manifest and separate inference notes.

Manifest

{
  "spec": {
    "repo": "TODO: YOUR_ORG/YOUR_RECORD_ID",
    "name": "user-api",
    "description": "RESTful API for user management",
    "kind": "api",
    "lifecycleStage": "production",
    "version": "2.3.1",
    "group": "TODO: 8-CHAR-ID",
    "dataSensitivity": "TODO: MANUAL",
    "sourcingModel": "custom",
    "deploymentModel": "public_cloud"
  },
  "tags": ["typescript", "express", "postgresql", "rest-api"],
  "api": [
    {
      "name": "User API",
      "schemaPath": "TODO: PUBLIC_URL_TO_SCHEMA"
    }
  ]
}

Inference Notes (Presented as Text)

  • spec.name: HIGH - Found in package.json

  • spec.description: HIGH - Extracted from README.md

  • spec.kind: HIGH - Identified as API based on OpenAPI spec and REST endpoints

  • spec.version: HIGH - Found in package.json

  • spec.lifecycleStage: MEDIUM - Inferred from production Docker configuration

  • spec.repo: MANUAL - Organization/Record ID format required

  • spec.group: MANUAL - Cannot determine organizational group ID

  • spec.dataSensitivity: MANUAL - Requires business decision

  • spec.sourcingModel: HIGH - Custom development evident from repository structure

  • spec.deploymentModel: MEDIUM - Inferred from Kubernetes configurations

  • tags: HIGH - Detected from package.json dependencies and file types

  • api.name: HIGH - From OpenAPI spec title

  • api.schemaPath: MANUAL - Needs public URL for hosted schema

Tips for Best Results

  1. Keep READMEs updated - Claude extracts descriptions from documentation

  2. Use standard files - package.json, Dockerfile, etc. are automatically detected

  3. Document APIs - Include OpenAPI/Swagger specs for API detection

  4. Provide CODEOWNERS - Helps identify contacts

  5. More files = better inference - Use "deep" analysis for comprehensive results

Resources and links

License

MIT. See the LICENSE file.

Available Tools

3 tools
collect_repo_filesA

Collect relevant files from a repository for Phaset manifest analysis. Returns file contents that can be analyzed to generate a manifest.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesAbsolute path to repository root directory
depthNoHow extensively to scan files (minimal=package files only, standard=includes deployment configs, deep=includes infrastructure)

TDQS

A3.6/5.0
Behavior3/5

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

No annotations provided, so description carries full burden. It mentions returning file contents and references depth parameter for scan extent, but does not detail what 'relevant files' means, output format, or behavior like symlinks/exclusions. Adequate but not thorough.

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 clear, concise sentences with no extraneous information. Purpose and outcome are front-loaded efficiently.

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?

Missing details about return format (plain text, JSON?), file size limits, or handling. Despite low complexity, the description is incomplete for an agent to reliably use without guessing output structure.

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 baseline 3 applies. The description adds no additional parameter context beyond the schema's property descriptions. No extra value contributed.

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 collects relevant files from a repository for Phaset manifest analysis, with a specific verb and resource. It distinguishes itself from siblings (get_phaset_schema, suggest_manifest) by focusing on file collection.

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 context (for manifest analysis) but does not explicitly state when to use this tool versus alternatives or provide exclusion criteria. Usage guidance is only implied.

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

get_phaset_schemaA

Get the Phaset integration API schema (RecordUpdate structure) for manifest generation

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations provided, the description carries full burden. It clearly indicates a read-only retrieval operation ('Get'), so an agent understands it has no side effects. Could add a note about idempotency, but not necessary.

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?

A single sentence that is front-loaded with key information (action, resource, purpose). No extraneous words.

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

Completeness5/5

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

Given zero parameters, no output schema, and the simple nature of the tool, the description fully communicates its purpose and context. No missing details.

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 tool has no parameters, so no parameter documentation is needed. The description adds no param info, but the schema already covers 100%. Baseline of 4 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and the resource 'Phaset integration API schema', and specifies it is for 'manifest generation'. This distinguishes it from sibling tools like 'suggest_manifest', which likely generates the manifest itself.

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 'for manifest generation', suggesting it is a prerequisite for 'suggest_manifest', but does not explicitly state when to use or not use this tool, nor provide alternatives.

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

suggest_manifestA

Analyze a repository and generate a Phaset manifest suggestion. This orchestrates schema retrieval and file collection, then provides them for AI analysis.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesAbsolute path to repository root directory
depthNoAnalysis depth (default: standard)

TDQS

A4/5.0
Behavior3/5

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

With no annotations provided, the description carries the burden of disclosing behavior. It explains the orchestration but does not mention side effects, permissions, or whether it modifies state. It is adequate but lacks full transparency.

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, front-loaded with the primary purpose, followed by a concise explanation of orchestration. 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 the tool has only 2 parameters and no output schema, the description covers the main functionality. However, it could be more specific about what the returned suggestion contains, leaving some room for improvement.

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

Parameters3/5

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

Schema coverage is 100%, so the input schema already describes both parameters. The description adds no additional meaning beyond what the schema provides, warranting a baseline score of 3.

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 analyzes a repository and generates a Phaset manifest suggestion, distinguishing it from siblings by noting it orchestrates schema retrieval and file collection.

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 implies when to use this tool (for generating a manifest suggestion) versus alternatives like collect_repo_files or get_phaset_schema, but does not explicitly state when not to use it.

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. 3 tool updatesv0.0.3
    • First observedcollect_repo_files
    • First observedget_phaset_schema
    • First observedsuggest_manifest
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: collecting files, retrieving schema, and generating manifest suggestions. There is no overlap or ambiguity.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case (collect_repo_files, get_phaset_schema, suggest_manifest), making them predictable and easy to understand.

Tool Count5/5

Three tools is appropriate for a focused manifest generation server; each tool serves a necessary step in the workflow without excess or deficiency.

Completeness5/5

The tool set covers the full manifest generation process: data collection, schema retrieval, and suggestion generation. No obvious gaps for the stated purpose.

Maintenance

ActivityInactive
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

  • shieldbot

    balasriharsha
    A
    license
    A
    quality
    C
    maintenance
    AI-powered security code review for Claude Code that runs multiple scanners (CodeQL, Semgrep, etc.) to detect vulnerabilities, secrets, and dependency CVEs, producing prioritized reports.
    2
    3
    MIT

  • SecureVibes MCP

    SimonvanAs
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables AI-powered security scanning of codebases through conversational analysis, allowing users to assess, threat model, code review, DAST test, and generate security reports using natural language with Claude.
    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/phasetdev/phaset-mcp'

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