How do I use silverstripe-mcp?

1. Click on "Deploy 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., "@silverstripe-mcp Validate this PHP code for Silverstripe 6 compatibility" 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.

silverstripe-mcp

by sandervanscheepen

Overview Schema Source Related Servers Discussions Admin

Local

Silverstripe MCP Server

License: MIT Node.js PHP

A Model Context Protocol server that provides real-time validation feedback when AI assistants generate Silverstripe 6 PHP code. Catches common migration issues from Silverstripe 5 to 6 before they reach your codebase.

Documentation: Architecture | Agent Instructions Setup

The Problem

When using AI coding assistants like Claude Code with Silverstripe 6 projects, they often generate code with outdated patterns:

// AI generates this (SS5 style):
use SilverStripe\ORM\ArrayList;
use SilverStripe\View\ArrayData;

class MyTask extends BuildTask {
    public function run(HTTPRequest $request) {
        echo "Processing...";
    }
}

This MCP server catches these issues immediately, allowing the AI to self-correct:

// After validation, AI generates this (SS6 style):
use SilverStripe\Model\List\ArrayList;
use SilverStripe\Model\ArrayData;

class MyTask extends BuildTask {
    protected static string $commandName = 'my-task';

    protected function execute(InputInterface $input, PolyOutput $output): int {
        $output->writeln('Processing...');
        return Command::SUCCESS;
    }
}

Related MCP server: Magento 2 Coding Standards MCP Server

How It Works

┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐
│  AI generates   │────▶│  MCP validates  │────▶│  AI fixes and   │
│  PHP code       │     │  against SS6    │     │  re-validates   │
└─────────────────┘     └─────────────────┘     └─────────────────┘
                               │
                               ▼
                        ┌─────────────────┐
                        │  PHP Analyzer   │
                        │  (AST-based)    │
                        └─────────────────┘
                               │
                   ┌───────────┴───────────┐
                   ▼                       ▼
            ┌─────────────┐         ┌─────────────┐
            │  Namespace  │         │  BuildTask  │
            │  Validator  │         │  Validator  │
            └─────────────┘         └─────────────┘

The server exposes an ss-validator tool that:

Parses PHP code into an Abstract Syntax Tree (AST)
Runs plugin-based validators against the code
Returns issues with line numbers and suggested fixes
The AI iterates until no issues remain

Quick Start

Installation

git clone https://github.com/sandervanscheepen/silverstripe-mcp
cd silverstripe-mcp

# Install dependencies
npm install
cd php && composer install && cd ..

# Build
npm run build

Then add to your MCP client (e.g., Claude Code):

claude mcp add silverstripe-mcp -- node /path/to/silverstripe-mcp/dist/index.js

Or add to your MCP client configuration file:

{
  "mcpServers": {
    "silverstripe": {
      "command": "node",
      "args": ["/path/to/silverstripe-mcp/dist/index.js"]
    }
  }
}

Agent Instructions Setup

To get the most out of this MCP server, add instructions to your AI agent's project instructions file (e.g., CLAUDE.md, .cursorrules, .github/copilot-instructions.md) that tell it to use the ss-validator tool on all generated PHP code. See Recommended Agent Instructions for full, minimal, and project-specific templates you can copy into your project.

Built-in Validators

Namespace Validator

Detects outdated Silverstripe 5 imports and suggests their Silverstripe 6 equivalents:

SS5 Namespace	SS6 Namespace
`SilverStripe\ORM\ArrayList`	`SilverStripe\Model\List\ArrayList`
`SilverStripe\ORM\PaginatedList`	`SilverStripe\Model\List\PaginatedList`
`SilverStripe\ORM\Map`	`SilverStripe\Model\List\Map`
`SilverStripe\ORM\GroupedList`	`SilverStripe\Model\List\GroupedList`
`SilverStripe\View\ArrayData`	`SilverStripe\Model\ArrayData`
`SilverStripe\View\ViewableData`	`SilverStripe\Model\ModelData`
`SilverStripe\ORM\ValidationResult`	`SilverStripe\Core\Validation\ValidationResult`
`SilverStripe\ORM\ValidationException`	`SilverStripe\Core\Validation\ValidationException`

BuildTask Validator

Detects old BuildTask patterns that need migration to PolyCommand:

Issue	Detection	Suggestion
Deprecated method signature	`run(HTTPRequest $request)`	`execute(InputInterface $input, PolyOutput $output): int`
Missing command name	No `$commandName` property	`protected static string $commandName = 'my-task';`
Output via echo	`echo "..."`	`$output->writeln('...')`
Output via print	`print "..."`	`$output->writeln('...')`

FormField Value Validator

Detects usage of FormField::Value() which was split into three methods in SS6:

// Detects this:
$value = $field->Value();

// Suggests using one of:
$value = $field->dataValue();       // Raw data value
$value = $field->presentedValue();  // Value for display
$value = $field->processedValue();  // Value after form processing

Removed Method Validator

Detects calls to methods that were removed in Silverstripe 6:

Removed Method	Suggestion
`Controller::has_curr()`	Use `Controller::curr()` with try/catch
`DataObject::getCMSValidator()`	Use `getCMSCompositeValidator()` instead
`Requirements::themedCSS()`	Use `Requirements::css()` with ThemeResourceLoader
`Requirements::themedJavascript()`	Use `Requirements::javascript()` with ThemeResourceLoader
`Object::useCustomClass()`	Use Injector configuration instead

Deprecated Config API (`deprecated-config`)

Detects usage of the deprecated Config::inst()->get() pattern:

// Detects this:
$value = Config::inst()->get('SilverStripe\CMS\Model\SiteTree', 'allowed_children');

// Suggests this:
$value = SiteTree::config()->get('allowed_children');

Context-Aware Validators

The following validators auto-enable based on code context, minimizing overhead when analyzing code that doesn't need them:

Extension Hook Visibility (`extension-hook-visibility`)

Auto-enabled when: Class extends Extension, DataExtension, or SiteTreeExtension

SS6 changed many extension hook methods to protected. Detects public hooks in Extension classes:

class MyExtension extends DataExtension {
    // Detects: should be protected
    public function onBeforeWrite() { }
    public function updateCMSFields($fields) { }
}

Configurable prefixes: onBefore, onAfter, update, augment (add more via additionalPrefixes).

Elemental Namespace (`elemental-namespace`)

Auto-enabled when: Any import starts with DNADesign\Elemental

For projects using dnadesign/silverstripe-elemental. Detects namespace changes in Elemental 6:

SS5 Namespace	SS6 Namespace
`DNADesign\Elemental\TopPage\DataExtension`	`DNADesign\Elemental\Extensions\TopPageElementExtension`
`DNADesign\Elemental\TopPage\FluentExtension`	`DNADesign\Elemental\Extensions\TopPageFluentElementExtension`
`DNADesign\Elemental\TopPage\SiteTreeExtension`	`DNADesign\Elemental\Extensions\TopPageSiteTreeExtension`
`DNADesign\Elemental\Controllers\ElementSiteTreeFilterSearch`	`DNADesign\Elemental\ORM\Search\ElementalSiteTreeSearchContext`

Also detects removed classes (GraphQL, ElementalLeftAndMainExtension, etc.).

Forcing All Plugins

To force-enable all validators regardless of context:

Via config (silverstripe-mcp.json):

{
  "enableAllPlugins": true
}

Via tool argument:

{
  "code": "<?php ...",
  "enableAllPlugins": true
}

You can also explicitly enable individual auto-plugins to always run:

{
  "plugins": {
    "elemental-namespace": {
      "enabled": true,
      "additionalMappings": {
        "Custom\\Old\\Class": "Custom\\New\\Class"
      }
    }
  }
}

Configuration

Create silverstripe-mcp.json in your project root to customize behavior:

{
  "phpBinary": "/path/to/php",
  "targetVersion": "6.0",
  "plugins": {
    "namespace-validator": {
      "enabled": true,
      "additionalMappings": {
        "App\\Legacy\\MyClass": "App\\Modern\\MyClass"
      }
    },
    "buildtask-validator": {
      "enabled": true
    },
    "deprecated-config": {
      "enabled": true
    },
    "extension-hook-visibility": {
      "enabled": true,
      "additionalPrefixes": ["can", "provide"]
    }
  },
  "customPlugins": [
    "./my-plugins/CustomValidator.php"
  ]
}

See silverstripe-mcp.example.json for a complete example.

Configuration Options

Option	Type	Description
`phpBinary`	`string`	Path to PHP 8.3+ executable (auto-detected if not specified)
`targetVersion`	`string`	Silverstripe version to validate against (default: `"6.0"`)
`enableAllPlugins`	`boolean`	Force-enable all plugins including context-aware ones (default: `false`)
`plugins`	`object`	Per-plugin configuration
`plugins.*.enabled`	`boolean`	Enable/disable a specific plugin
`plugins.namespace-validator.additionalMappings`	`object`	Custom namespace migrations
`customPlugins`	`string[]`	Paths to custom validator plugins

PHP Binary Resolution

The server requires PHP 8.3+ (Silverstripe 6's minimum version). It resolves the PHP binary in this order:

Config file: phpBinary in silverstripe-mcp.json
Environment variable: PHP_BINARY (if version >= 8.3)
Auto-detect: Common locations (Laragon, XAMPP, Homebrew, system paths)
System PHP: Falls back to php command (if version >= 8.3)

If your system PHP is below 8.3, specify the path in your config:

{
  "phpBinary": "C:/laragon/bin/php/php-8.3.22-Win32-vs16-x64/php.exe"
}

Or set the PHP_BINARY environment variable in your MCP client config:

{
  "mcpServers": {
    "silverstripe": {
      "command": "node",
      "args": ["/path/to/silverstripe-mcp/dist/index.js"],
      "env": {
        "PHP_BINARY": "/usr/local/bin/php8.3"
      }
    }
  }
}

Writing Custom Plugins

Create a PHP class implementing ValidatorPluginInterface:

<?php

namespace MyOrg\MCPPlugins;

use SilverstripeMCP\Contracts\ValidatorPluginInterface;
use SilverstripeMCP\AnalysisContext;
use SilverstripeMCP\Issue;
use PhpParser\NodeVisitorAbstract;
use PhpParser\Node;

class DeprecatedMethodPlugin implements ValidatorPluginInterface
{
    public function getName(): string
    {
        return 'deprecated-method-validator';
    }

    public function getDescription(): string
    {
        return 'Detects usage of deprecated methods';
    }

    public function getTargetVersions(): array
    {
        return ['6.*']; // Applies to all SS6.x versions
    }

    public function configure(array $options): void
    {
        // Handle configuration options
    }

    public function getVisitor(AnalysisContext $context): \PhpParser\NodeVisitor
    {
        return new class($context) extends NodeVisitorAbstract {
            public function __construct(private AnalysisContext $context) {}

            public function enterNode(Node $node): ?int
            {
                // Detect deprecated method calls
                if ($node instanceof Node\Expr\MethodCall) {
                    $methodName = $node->name->toString();

                    if ($methodName === 'deprecatedMethod') {
                        $this->context->addIssue(new Issue(
                            type: 'deprecated_method',
                            message: 'deprecatedMethod() is deprecated in SS6',
                            line: $node->getLine(),
                            suggestion: 'Use newMethod() instead',
                            docsUrl: 'https://docs.silverstripe.org/...'
                        ));
                    }
                }
                return null;
            }
        };
    }
}

// Return the class name for auto-loading
return DeprecatedMethodPlugin::class;

{
  "customPlugins": [
    "./plugins/DeprecatedMethodPlugin.php"
  ],
  "plugins": {
    "deprecated-method-validator": {
      "enabled": true
    }
  }
}

Testing

The project includes comprehensive test suites for both PHP and TypeScript:

# Run PHP tests (PHPUnit)
cd php && composer test

# Run TypeScript tests (Vitest)
npm test

# Run all tests
npm run test:all

# Watch mode for development
npm run test:watch

Project Structure

silverstripe-mcp/
├── src/                          # TypeScript MCP server
│   ├── index.ts                  # Entry point, stdio transport
│   ├── tools/
│   │   └── ss-validator.ts       # Main validation tool
│   └── lib/
│       └── php-bridge.ts         # PHP subprocess communication
│
├── php/                          # PHP analyzer
│   ├── bin/
│   │   └── analyze               # CLI entry point
│   ├── src/
│   │   ├── AnalyzerRunner.php    # Plugin orchestration
│   │   ├── AnalysisContext.php   # Shared analysis state
│   │   ├── Issue.php             # Issue data structure
│   │   ├── Contracts/
│   │   │   └── ValidatorPluginInterface.php
│   │   ├── Plugins/              # Validator plugins
│   │   │   ├── NamespaceValidatorPlugin.php      (core)
│   │   │   ├── BuildTaskValidatorPlugin.php      (core)
│   │   │   ├── FormFieldValuePlugin.php          (core)
│   │   │   ├── RemovedMethodPlugin.php           (core)
│   │   │   ├── HookRenamePlugin.php              (core)
│   │   │   ├── DeprecatedConfigPlugin.php        (core)
│   │   │   ├── ExtensionHookVisibilityPlugin.php (auto: Extension classes)
│   │   │   └── ElementalNamespacePlugin.php      (auto: Elemental imports)
│   │   └── Config/
│   │       ├── namespace-mappings.php
│   │       ├── removed-methods.php
│   │       ├── hook-renames.php
│   │       └── elemental-mappings.php
│   └── tests/                    # PHPUnit tests
│
├── tests/                        # Vitest tests
│   ├── php-bridge.test.ts
│   ├── ss-validator.test.ts
│   └── fixtures/
│
├── docs/
│   ├── architecture.md                    # Technical architecture
│   └── recommended-agent-instructions.md  # Setup for AI agents
├── silverstripe-mcp.example.json # Example configuration
├── CLAUDE.md                     # Development instructions
└── README.md

Development

# Build and watch for changes
npm run dev

# Test PHP analyzer directly
cd php && php bin/analyze '{"code": "<?php use SilverStripe\\ORM\\ArrayList;"}'

# Example output:
{
  "issues": [{
    "type": "deprecated_import",
    "message": "'SilverStripe\\ORM\\ArrayList' has moved to 'SilverStripe\\Model\\List\\ArrayList' in Silverstripe 6",
    "line": 1,
    "suggestion": "use SilverStripe\\Model\\List\\ArrayList;",
    "docsUrl": "https://docs.silverstripe.org/en/6/changelogs/6.0.0/#renamed-classes"
  }],
  "suggestions": [],
  "rerun": true
}

See CONTRIBUTING.md for detailed development instructions.

Requirements

Node.js 18.0 or higher
PHP 8.3 or higher
Composer for PHP dependency management

Contributing

Contributions are welcome! See CONTRIBUTING.md for development setup, architecture details, and testing guidelines.

Credits

Inspired by the Svelte MCP server which provides similar functionality for Svelte 5
Built with nikic/php-parser for robust AST analysis
Uses the Model Context Protocol specification

License

MIT License - see LICENSE for details.

Available Tools

4 tools

get-documentationGet SS6 DocumentationA

Fetches Silverstripe 6 changelog documentation for a specific section. Call list-sections first to see available sections.

ParametersJSON Schema

Name	Required	Description	Default
`section`	Yes	Section ID from list-sections (e.g., "renamed-classes", "cli-changes")

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 full burden. It mentions the dependency on list-sections, which is useful. However, it does not disclose details about return format, error behavior, or what happens if the section ID is invalid, leaving some 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 sentences, front-loaded with the primary action, and includes a critical usage hint. Every word is purposeful with no fluff or repetition.

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 one-parameter tool with no output schema, the description provides sufficient context: what it does and the required precursor. It does not explain the return value, but given the simplicity of fetching documentation, this is a minor gap and the description remains largely 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 coverage of the 'section' parameter with a clear description and example. The tool description adds no additional parameter semantics beyond what the schema documents, 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 clearly states the tool fetches Silverstripe 6 changelog documentation for a specific section, with a specific verb 'fetches' and resource. It distinguishes itself from sibling tools like search-changelog and list-sections by focusing on retrieving a documented section rather than listing or searching.

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 provides explicit guidance to call list-sections first, establishing a required prerequisite. It doesn't explicitly mention when not to use this tool or contrast with alternatives, but the context is clear enough for an agent to understand when to invoke it.

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

list-sectionsList SS6 SectionsA

Lists available Silverstripe 6 changelog sections. Use this to discover what documentation is available before fetching with get-documentation.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior3/5

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

No annotations are provided, so the description must carry behavioral disclosure. It adds workflow context (use before fetching) but does not describe the return format, authentication needs, or any side effects. Since 'list' implies a read-only operation, this is minimally adequate but lacks depth.

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 two sentences are efficient: the first states the action, the second provides usage guidance. No redundant or filler content.

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?

The description covers the core purpose and usage workflow for a zero-parameter list operation. It does not explicitly state the output format, but the verb 'lists' implies the return of available sections, which is sufficient for such a simple tool.

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 zero parameters, so the schema is trivially covered at 100%. The description correctly avoids adding parameter details because none exist, achieving the baseline for no-parameter tools.

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 verb 'Lists' with a concrete resource ('Silverstripe 6 changelog sections'), and then distinguishes the tool from sibling get-documentation by framing it as a discovery step. This clearly differentiates it from search-changelog and ss-validator.

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?

The second sentence explicitly instructs when to use the tool: 'Use this to discover what documentation is available before fetching with get-documentation.' It names the sibling tool as the next step, providing clear usage context, though it doesn't formally state exclusions.

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

search-changelogSearch SS6 ChangelogA

Search the SS6 changelog for specific terms. Use this when you need to find information about a specific class, method, or feature that may not be in the themed documentation sections.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Search term or phrase to find in the changelog
`maxResults`	No	Maximum number of results to return (default: 5)

TDQS

A3.7/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 of behavioral disclosure. It only states that the tool 'searches' the changelog but does not explain matching behavior, result format, or limitations. This leaves important operational details unspecified.

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 sentences, front-loaded with the action ('Search the SS6 changelog') followed by usage context. Every word earns its place with no unnecessary filler.

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 simple two-parameter search tool, the description covers what and when, and the schema handles parameter documentation. However, since there is no output schema, the description does not mention what results contain or how maxResults affects the output, leaving minor gaps.

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 schema provides descriptions for both 'query' and 'maxResults,' covering 100% of parameters, so the baseline is 3. The description reinforces the purpose of the query but does not add new syntax or format details beyond the 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 opens with 'Search the SS6 changelog for specific terms,' clearly stating the verb, resource, and scope. It also distinguishes itself from siblings by referencing 'the themed documentation sections,' showing this tool is for targeted changelog lookups.

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 explicitly says 'Use this when you need to find information about a specific class, method, or feature that may not be in the themed documentation sections,' giving clear usage context. However, it does not name alternative tools or state when not to use it, so it falls slightly short of full guidance.

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

ss-validatorSilverstripe ValidatorA

Analyzes PHP code for Silverstripe 6 compatibility issues. MUST be called on any generated Silverstripe PHP code before presenting to the user. Keep calling until no issues remain.

Detects:

Wrong namespace imports (e.g., SilverStripe\ORM\ArrayList should be SilverStripe\Model\List\ArrayList)
Old BuildTask patterns (run(HTTPRequest) should be execute(InputInterface, PolyOutput))
Missing required properties (e.g., $commandName on BuildTask)
Deprecated patterns (echo in BuildTask should be $output->writeln())

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes	The PHP code to analyze
`filename`	No	Optional filename for context (helps detect BuildTask, Controller, etc.)
`configPath`	No	Optional path to silverstripe-mcp.json config file
`targetVersion`	No	Target Silverstripe version (default: 6.0)	6.0

TDQS

A4.4/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 key behavioral aspects: the types of issues detected and the iterative requirement. However, it does not describe the return format or state that the tool is read-only, which would be valuable for a validator. The absence of return details is a minor 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?

The description is well-structured: a clear purpose sentence, a strong imperative for mandatory usage, and a concise bulleted list of detection categories. Every sentence earns its place, and the front-loaded purpose ensures quick understanding.

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?

The description covers the tool's purpose, when to use it, and what it detects, which is strong given the 4-parameter schema and lack of output schema. However, it does not explicitly describe the return value (e.g., a list of issues, a status indicator), which leaves a gap for agents needing to process results. This is a notable omission for a validator 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%, so the baseline is 3. The description adds minimal extra meaning beyond the schema, except linking 'generated Silverstripe PHP code' to the code parameter and mentioning BuildTask patterns relevant to filename context. It does not provide additional syntax or format details beyond what the schema already offers.

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's function: analyzing PHP code for Silverstripe 6 compatibility issues. It uses a specific verb ('analyzes') and resource ('PHP code'), and the bulleted list of detection categories distinguishes it from sibling tools like get-documentation or search-changelog.

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 when to use the tool ('MUST be called on any generated Silverstripe PHP code before presenting to the user') and provides an iterative usage pattern ('Keep calling until no issues remain'). This gives clear context and exclusions, leaving no ambiguity about when it should be invoked.

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.

4 tool updatesv0.1.0Aug 2, 2026
- First observedget-documentation
- First observedlist-sections
- First observedsearch-changelog
- First observedss-validator

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored 2026-08-02 08:25 across 4 tools

Disambiguation5/5

Each tool serves a distinct purpose: listing changelog sections, fetching specific documentation, searching the changelog, and validating PHP code. No two tools overlap in functionality, making selection unambiguous.

Naming Consistency4/5

Three tools follow a consistent verb_noun pattern (list-sections, get-documentation, search-changelog), but ss-validator breaks the pattern as a noun phrase. This is a minor deviation in an otherwise predictable naming scheme.

Tool Count5/5

With only 4 tools, the server is tightly scoped to its stated purpose of Silverstripe 6 migration assistance. Each tool earns its place, covering documentation access and code validation without redundancy.

Completeness5/5

The tool set provides a complete lifecycle: discover sections, retrieve documentation, search for terms, and validate code. No obvious gaps exist for the domain of Silverstripe 6 compatibility checking.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

HefestoAI A
io.github.artvepa80
Pre-commit code quality guardian. Detects semantic drift in AI-generated code.
Code Analysis Testing & QA Tools Developer Tools
421
Synapse — GEO Growth Layer A
io.github.calvinling2021-star
Lints + auto-fixes how AI coding agents discover any new product. 24 rules, 6 tools, score 0-100.
Developer Tools Coding Agents
2
nittim A
com.nittim
Production-safety audits for AI-generated code, with a fix for every finding.
Code Analysis Penetration Testing
151
Frogeye Security Scanner A
io.github.frogeye-ai
Zero-config MCP security scanner for AI-generated apps. 25K+ vulnerability patterns.
Security Penetration Testing
2

Related MCP Servers

Deslop MCP Server
Developer Tools Code Analysis Testing & QA Tools
collin-ho
F
license
A
quality
D
maintenance
Detects and automatically removes AI-generated code slop patterns like redundant comments, verbose logging, and unnecessary error handling across multiple programming languages.
Updated 9 months ago (2025-12-24 01:37 UTC)
3
1
-
Magento 2 Coding Standards MCP
Developer Tools Code Analysis
Midhun-edv
A
license
A
quality
D
maintenance
Provides AI assistants with comprehensive Magento 2 coding standards, security rules, and theme-specific guidelines to ensure generated code is compliant. It enables real-time code validation, pattern lookup, and security auditing tailored to different Magento frontend stacks.
Updated 7 months ago (2026-02-20 07:32 UTC)
7
15
MIT
CodeGuardian MCP
Code Analysis Developer Tools Testing & QA Tools
codegoddy
A
license
A
quality
D
maintenance
Validates AI-generated code against actual codebases to catch hallucinations, dead code, and API mismatches before runtime.
Updated 7 months ago (2026-02-27 14:29 UTC)
12
9 npm
1
MIT
prodlintofficial
Code Analysis AI & Machine Learning
prodlint
A
license
Not graded
quality
A
maintenance
Static analysis for vibe-coded apps. Flags security, reliability, performance, and AI quality issues in code generated by Cursor, v0, Bolt, and Copilot.
Updated 7 days ago (2026-09-06 16:32 UTC)
952 npm
15
MIT

Silverstripe MCP Server

The Problem

How It Works

Quick Start

Installation

Agent Instructions Setup

Built-in Validators

Namespace Validator

BuildTask Validator

FormField Value Validator

Removed Method Validator

Deprecated Config API (deprecated-config)

Context-Aware Validators

Extension Hook Visibility (extension-hook-visibility)

Elemental Namespace (elemental-namespace)

Forcing All Plugins

Configuration

Configuration Options

PHP Binary Resolution

Writing Custom Plugins

Testing

Project Structure

Development

Requirements

Contributing

Credits

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

prodlintofficial

Deprecated Config API (`deprecated-config`)

Extension Hook Visibility (`extension-hook-visibility`)

Elemental Namespace (`elemental-namespace`)