Skip to main content
Glama
Atomic-Germ

Optimist MCP Server

by Atomic-Germ
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

Optimist MCP Server

An intelligent code optimization MCP server that analyzes and improves codebases across multiple dimensions

License: MIT TypeScript MCP CI/CD

Overview

Optimist is a Model Context Protocol (MCP) server designed to work alongside other development tools to provide comprehensive codebase optimization. It analyzes code for performance bottlenecks, memory issues, code smells, and maintainability concerns, offering actionable suggestions for improvement.

Key Features

  • 🚀 Performance Analysis - Identify bottlenecks and hot paths

  • 💾 Memory Optimization - Detect leaks and inefficient allocations

  • 📊 Code Quality Metrics - Complexity analysis and maintainability scoring

  • 🔍 Dead Code Detection - Find and eliminate unused code

  • 📦 Dependency Management - Optimize and analyze dependency graphs

  • 🎯 Smart Refactoring - AI-powered refactoring suggestions

  • 🔗 MCP Integration - Seamless integration with other MCP tools

  • ✅ Test-Driven - Built using TDD methodology

Related MCP server: code-graph-mcp

Quick Start

Prerequisites

  • Node.js 18+

  • npm or pnpm

  • An MCP-compatible client (e.g., Claude Desktop)

  • A codebase to analyze

Installation

# Clone the repository
git clone https://github.com/Atomic-Germ/mcp-optimist.git
cd mcp-optimist
npm install
npm run build

Test the Server

# Run tests to verify everything works
npm test

# Run with coverage
npm run test:coverage

# Verify build output
ls -la dist/

Configure MCP Client

Claude Desktop

Edit your configuration file:

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

  • Linux: ~/.config/claude/claude_desktop_config.json

Add the server:

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

Verify Setup

  1. Restart your MCP client

  2. Look for "optimist" in the available tools

  3. You should see 8 optimization tools available

First Code Analysis

Try these examples in your MCP client:

Analyze Code Complexity

Use analyze_complexity tool on your project:
Path: "./src"
Max Complexity: 10
Report Format: "summary"

Detect Performance Issues

Use analyze_performance tool:
Path: "./src"
Include Tests: false
Threshold: "medium"

Find Code Smells

Use detect_code_smells tool:
Path: "./src"
Severity: "medium"

Memory Analysis

Use optimize_memory tool:
Path: "./src"
Detect Leaks: true
Suggest Fixes: true

Development

Development Commands

# Development
npm run dev              # Run with ts-node (development mode)
npm run build:watch      # Auto-rebuild on changes

# Testing
npm test                 # Run all tests
npm run test:watch       # Watch mode for tests
npm run test:coverage    # Generate coverage report

# Code Quality
npm run lint             # Check code with ESLint
npm run lint:fix         # Auto-fix linting issues
npm run format           # Format code with Prettier
npm run format:check     # Check formatting

# Build
npm run build            # Compile to dist/
npm run clean            # Remove dist/

Project Structure

mcp-optimist/
├── src/
│   ├── index.ts         # MCP server entry point
│   ├── server.ts        # OptimistServer class
│   ├── types/           # TypeScript definitions
│   ├── tools/           # Tool implementations
│   ├── analyzers/       # Analysis engines
│   └── utils/           # Utility functions
│
├── tests/
│   ├── unit/            # Unit tests
│   ├── integration/     # Integration tests
│   └── fixtures/        # Test fixtures
│
├── docs/                # Documentation
├── archive/             # Archived documentation
├── README.md            # This file
├── package.json         # Dependencies and scripts
├── tsconfig.json        # TypeScript configuration
├── jest.config.js       # Test configuration
├── eslint.config.js     # Linting rules
├── .prettierrc          # Code formatting
└── dist/                # Compiled JavaScript

Examples

Basic Project Analysis

Perform comprehensive analysis of your entire project:

// Analyze overall code quality
{
  tool: "detect_code_smells",
  arguments: {
    path: "./src",
    severity: "medium"
  }
}

// Check performance issues
{
  tool: "analyze_performance",
  arguments: {
    path: "./src",
    threshold: "medium",
    includeTests: false
  }
}

// Find complexity issues
{
  tool: "analyze_complexity",
  arguments: {
    path: "./src",
    maxComplexity: 8,
    reportFormat: "detailed"
  }
}

Single File Analysis

Analyze a specific problematic file:

{
  tool: "analyze_performance",
  arguments: {
    path: "./src/services/dataProcessor.ts",
    threshold: "low",
    profileHotPaths: true,
    trackAsyncOperations: true
  }
}

Memory Optimization

Find and fix memory leaks in a React component:

{
  tool: "optimize_memory",
  arguments: {
    path: "./src/components",
    detectLeaks: true,
    analyzeClosures: true
  }
}

Leak Analysis Result:

{
  data: {
    findings: [
      {
        type: 'event-listener-leak',
        file: 'src/components/DataChart.tsx',
        line: 23,
        description: 'Event listeners not cleaned up in useEffect',
        leakPotential: 'high',
      },
      {
        type: 'closure-retention',
        file: 'src/hooks/useDataFetch.ts',
        line: 15,
        description: 'Closure retaining large objects unnecessarily',
      },
    ];
  }
}

Memory Leak Fixes:

Problem - Event Listener Leak:

// Problematic - no cleanup
function DataChart() {
  useEffect(() => {
    window.addEventListener('resize', handleResize);
    // Missing cleanup function
  }, []);
}

Fixed:

// Fixed with proper cleanup
function DataChart() {
  useEffect(() => {
    const handleResize = () => {
      // Handle resize
    };

    window.addEventListener('resize', handleResize);

    // Cleanup function prevents leak
    return () => {
      window.removeEventListener('resize', handleResize);
    };
  }, []);
}

Performance Optimization

Identify and fix performance bottlenecks:

{
  tool: "analyze_performance",
  arguments: {
    path: "./src/services/dataProcessor.ts",
    threshold: "low",
    profileHotPaths: true
  }
}

Before (Problematic):

// O(n²) complexity - problematic
function processLargeDataset(items: Item[], lookup: LookupItem[]): ProcessedItem[] {
  return items.map((item) => {
    // Inner loop for each item - O(n²)
    const match = lookup.find((l) => l.id === item.lookupId);
    return { ...item, enrichedData: match?.data };
  });
}

After (Optimized):

// O(n) complexity - optimized
function processLargeDataset(items: Item[], lookup: LookupItem[]): ProcessedItem[] {
  // Create lookup map once - O(n)
  const lookupMap = new Map(lookup.map((l) => [l.id, l.data]));

  // Single pass through items - O(n)
  return items.map((item) => ({
    ...item,
    enrichedData: lookupMap.get(item.lookupId),
  }));
}

Code Quality Analysis

Analyze function complexity and code smells:

{
  tool: "analyze_complexity",
  arguments: {
    path: "./src/utils/validation.ts",
    maxComplexity: 6,
    includeCognitive: true
  }
}

{
  tool: "detect_code_smells",
  arguments: {
    path: "./src/services/UserService.ts",
    severity: "high"
  }
}

For more examples, see the API Reference.

Available Tools

8 tools
analyze_complexityC

Evaluate cyclomatic and cognitive complexity

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesDirectory or file path to analyze
reportFormatNosummary
maxComplexityNoMaximum allowed complexity

TDQS

C2.9/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 disclosing behavior. It does not state whether the operation is read-only, what output the agent should expect, or any side effects or failure modes. While 'Evaluate' suggests analysis, the behavioral profile is largely undisclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no filler, so it is concise. However, it is terse to the point of omitting important usage and behavioral context, making it under-specified rather than efficiently complete.

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?

With no output schema and no annotations, the description must carry more context, but it only states what the tool evaluates. It does not explain return values, report formats, threshold behavior, or how this tool fits among the provided siblings. An agent would struggle to invoke it correctly beyond the obvious path parameter.

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?

The schema describes 'path' and 'maxComplexity', but 'reportFormat' lacks an explanation beyond its enum and default. The description adds no parameter-level meaning and does not compensate for the uncovered parameter. At 67% schema coverage, the description should clarify how reportFormat and maxComplexity affect the analysis, but it does not.

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, 'Evaluate', and names precise resources: cyclomatic and cognitive complexity. This clearly distinguishes it from sibling tools like analyze_performance or detect_code_smells, which target different concerns.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance on when to use this tool versus alternatives such as detect_code_smells or suggest_refactoring. No conditions, exclusions, or recommended contexts are mentioned; usage is only weakly implied by the word 'complexity'.

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

analyze_dependenciesB

Map and analyze dependency graphs

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesProject root path
checkCircularNoDetect circular dependencies
suggestUpdatesNoSuggest dependency updates

TDQS

B3.2/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 transparency. 'Analyze' implies a read-only operation, but the tool does not disclose whether it scans configuration files, whether 'suggestUpdates' has side effects, or what kind of output the agent should expect.

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 extremely concise, front-loaded with the core purpose, and contains no filler or redundancy. The single sentence earns its place, even though it is sparse in broader context.

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?

With no output schema, no annotations, and a very short description, the tool is incomplete from an agent's perspective. The agent does not know what the analysis produces, how results are returned, or what side effects may occur when 'suggestUpdates' is enabled. Given the tool's moderate complexity, more context is needed.

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 documented in the input schema. The description adds no additional meaning beyond what the schema already provides, so the baseline 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 states a specific action, 'Map and analyze dependency graphs', and the resource ('dependency graphs') clearly distinguishes it from sibling tools focused on performance, memory, complexity, code smells, dead code, hot paths, and refactoring. An agent can infer the tool's purpose without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to choose this tool over alternatives or when not to use it. The description does not mention exclusions, prerequisites, or comparison to shadowing sibling tools like analyze_complexity or detect_code_smells.

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

analyze_performanceC

Analyze code performance and identify bottlenecks

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesDirectory or file path to analyze
thresholdNoAlert thresholdmedium
includeTestsNoInclude test files

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description must carry the full burden of behavioral disclosure. It only states a high-level 'analyze' intent and does not disclose whether the operation is read-only, whether files are modified, what side effects occur, or how results are presented.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with no fluff. It is appropriately front-loaded with the core action, though it may be overly sparse rather than concise by choice.

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?

For a tool with no output schema and no annotations, the description leaves out essential context such as expected output, side effects, and selection criteria. It is not complete enough for an agent to invoke confidently without more hints.

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 baseline is 3. The description adds no specific parameter detail, but the schema already documents path, threshold, and includeTests, so no gap exists.

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 the tool's function: analyzing code performance and identifying bottlenecks. The verb and resource are specific, and the focus on performance/bottlenecks distinguishes it from sibling tools like analyze_complexity and optimize_memory, though it does so implicitly rather than via explicit naming.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus the seven siblings. There is no mention of scenarios, exclusions, or alternative tools, leaving the agent without context to choose between analyze_performance and e.g., optimize_hot_paths or analyze_complexity.

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

detect_code_smellsC

Identify anti-patterns and code quality issues

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesDirectory or file path to analyze
severityNoMinimum severity to report

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the purpose and does not describe how the analysis works, whether it is read-only, what types of code smells it detects, or what side effects or performance considerations exist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that front-loads the core action with no filler or redundancy. It is appropriately sized for the amount of information conveyed, though it is minimal in scope.

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?

There is no output schema and no annotations, so the description must explain what happens when the tool is invoked, but it does not mention return values, result format, or any runtime behavior. An agent would be uncertain about the tool's outcome and how to handle its response, making the context incomplete.

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?

Both parameters are already fully described in the schema: 'path' as the directory/file path to analyze and 'severity' as the minimum severity to report. Since schema coverage is 100%, the description adds no additional parameter semantics, so the baseline of 3 applies.

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 'Identify anti-patterns and code quality issues' uses a clear verb and resource that matches the tool name 'detect_code_smells'. It is easy to understand what the tool does, but it does not distinguish itself from sibling tools like analyze_complexity or suggest_refactoring, so the differentiation is weak.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus its siblings. There is no mention of alternatives, exclusions, or conditions under which this tool is the best choice among the listed analysis and optimization tools.

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

find_dead_codeC

Identify and locate unused code

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesDirectory or file path to analyze

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description carries the full burden of explaining behavior, but it only restates the tool's name-level purpose. It does not disclose whether this is a read-only analysis, how code is traversed, what counts as dead code, or what limitations exist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with no filler or redundant wording. It is slightly too sparse to be fully helpful, but it is appropriately front-loaded and every word earns its place.

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 one-parameter analysis tool, the description provides enough to invoke it with a path. However, there is no output schema and no mention of what the tool returns or how results are formatted, which leaves a notable gap in completeness.

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% for the single 'path' parameter, which already documents that it is a directory or file path. The description adds no additional parameter semantics, but the baseline of 3 applies because the schema fully covers the parameter.

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 action — identifying and locating unused code — with a clear target resource. It does not explicitly distinguish itself from sibling tools like detect_code_smells or analyze_dependencies, but the core purpose is evident.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to choose this tool over siblings or when it should not be used. The description implies a scenario (finding unused code) but offers no exclusions, prerequisites, or comparisons with alternatives.

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

optimize_hot_pathsC

Analyze and optimize frequently executed code paths

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesDirectory or file path to analyze
profilingDataNoPath to profiling data (optional)

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of disclosing behavior. It does not state whether 'optimize' means modifying source code, generating suggestions, or requiring user confirmation, and it does not explain what happens when profilingData is omitted.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single efficient sentence with no filler or repetition. It is concise and front-loaded, though it lacks any structural separation between purpose and usage guidance.

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?

With no output schema and no annotations, the description leaves critical context unclear: whether the tool returns analysis results, applies optimizations automatically, or requires profiling data. For a tool whose name and description imply it may modify code, this is a significant 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 both parameters adequately. The description adds little parameter-specific meaning, but because the schema handles it, a baseline 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 states a specific verb ('Analyze and optimize') and a specific resource ('frequently executed code paths'), making the tool's target clear. However, it does not strongly differentiate from siblings like analyze_performance or optimize_memory, since both actions overlap with the names of those tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given about when to use this tool versus alternatives such as analyze_performance or optimize_memory. The phrase 'hot paths' implies a performance-focused context, but there are no explicit conditions, prerequisites, or exclusions to help an agent choose correctly.

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

optimize_memoryC

Detect memory leaks and suggest memory-efficient patterns

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesDirectory or file path to analyze
detectLeaksNoCheck for memory leaks
suggestFixesNoProvide fix suggestions

TDQS

C2.9/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 states that the tool detects leaks and suggests patterns, but it does not clarify whether suggestions are applied automatically, whether the analysis is read-only, what side effects might occur, or what the output looks like. The verb 'suggest' hints at non-destructive behavior, but 'optimize' in the name creates 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 a single sentence with no filler. It front-loads the core action 'detect memory leaks' and follows with the secondary capability 'suggest memory-efficient patterns.' Every word earns its place.

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?

There is no output schema, so the description should explain what the caller will receive, such as a list of leaks or suggested patterns. It also lacks usage context and behavior details. While the schema covers parameters, the description is too thin to fully enable correct invocation and interpretation of results.

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 description coverage is 100%: path, detectLeaks, and suggestFixes all have meaningful descriptions. The tool description adds no additional parameter meaning, but it does not need to because the schema already fully documents the parameters. This matches the baseline of 3 for full schema coverage.

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 uses a specific verb-resource pairing: 'Detect memory leaks' and 'suggest memory-efficient patterns.' It clearly identifies the tool's domain as memory optimization, which distinguishes it from sibling tools focused on performance, complexity, code smells, dead code, dependencies, hot paths, and refactoring. However, it does not explicitly state what 'optimize' means in terms of actual changes or outputs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance about when to use this tool versus alternatives such as analyze_performance or optimize_hot_paths. No context, prerequisites, exclusions, or selection criteria are provided. The agent must infer when memory analysis is appropriate.

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

suggest_refactoringC

Provide AI-powered refactoring recommendations

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesDirectory or file path to analyze
focusAreaNoFocus area for refactoring suggestionsall
maxResultsNoMaximum number of suggestions to return
minPriorityNoMinimum priority level for suggestions (filters out lower priority items)low
excludeTypesNoTypes of refactoring suggestions to exclude (e.g., ["LONG_FUNCTION", "COMPLEX_CONDITION"])

TDQS

C2.9/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 for behavioral disclosure. It implies a read-only analysis by saying 'provide recommendations,' but it does not explicitly state that the tool does not modify files, how results are returned, or any requirements or side effects. This is a significant gap for a tool whose behavior is otherwise opaque.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short sentence and is easy to scan. 'AI-powered' is filler that doesn't add operational value, but otherwise the text is free of redundancy. It is concise but so terse that it sacrifices useful detail.

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?

The tool has five parameters, no output schema, and no annotations, so the description should explain return values, side effects, and how parameters influence results. It only states that it provides refactoring recommendations, leaving an agent without enough context to confidently invoke it. Sibling tools are not referenced to help disambiguate.

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%, with detailed descriptions for all five parameters including enums, defaults, and constraints. The tool description adds no additional parameter meaning beyond what the schema already provides. Baseline 3 is appropriate because the schema carries the documentation burden.

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 uses a specific verb ('provide') and a clear resource ('refactoring recommendations'), which indicates the tool suggests code improvements. It is distinct from siblings like analyze_performance or detect_code_smells, though the distinction is not explicitly stated. 'AI-powered' is unnecessary but doesn't obscure the purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance on when to use this tool versus sibling tools such as detect_code_smells or analyze_performance. It also doesn't mention the focusArea or excludeTypes parameters that could help an agent tailor the call. An agent must infer usage solely from the tool name and schema.

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. 8 tool updatesv0.1.0
    • First observedanalyze_complexity
    • First observedanalyze_dependencies
    • First observedanalyze_performance
    • First observeddetect_code_smells
    • First observedfind_dead_code
    • First observedoptimize_hot_paths
    • First observedoptimize_memory
    • First observedsuggest_refactoring
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0
Disambiguation4/5

Most tools target clearly distinct concerns: complexity, code smells, dead code, dependencies, memory, and refactoring. The only point of confusion is between analyze_performance and optimize_hot_paths, both of which deal with performance bottlenecks and could be misselected by an agent.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern using clear action verbs (analyze, optimize, detect, find, suggest). The convention is uniform and predictable, making it easy to infer the purpose of each tool from its name.

Tool Count5/5

With 8 tools, the server is well-scoped for a code analysis and optimization domain. Each tool covers a distinct aspect of the problem space without unnecessary bloat or redundancy.

Completeness4/5

The tool surface covers the major dimensions of code quality: performance, memory, complexity, smells, dead code, dependencies, and refactoring. A minor gap is the lack of a tool to directly apply or validate changes, but the server's analytical focus is well served by the existing set.

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

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/Atomic-Germ/mcp-optimist'

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