Skip to main content
Glama
Sign In
Stellaris MCP

Stellaris MCP

by GDM-Pixel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

project_health

Analyzes project health by detecting cycles, dead code, coupling hotspots, and complexity. Returns a global score to guide refactoring decisions.

Instructions

Aggregated project health check. Runs cycle detection (Tarjan), dead code analysis, coupling hotspots, graph complexity stats, max import depth, and index freshness — returns a global score A–F. Use as a quick diagnostic before any major refactoring. No API call needed.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "project_health"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv4.4.0

TDQS

A4.4/5.0
Behavior4/5

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

Discloses the tool runs multiple internal analyses, returns a score A–F, and notes 'No API call needed,' implying it is local and low-cost. No annotations provided, but description is transparent about functionality and cost model.

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, no fluff. First sentence covers what it does, second provides usage guidance. Every word adds value.

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 no output schema and no parameters, the description covers the key points: analyses performed, output format, and usage context. Could mention if there are side effects (likely none), but overall complete.

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?

There are zero parameters, and the description does not need to add param semantics. Baseline for 0 params is 4, and the description is sufficient.

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 runs an aggregated health check with specific analyses (cycle detection, dead code, coupling hotspots, etc.) and returns a global score A–F, distinguishing it from sibling tools that focus on individual analyses.

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?

Explicitly says 'Use as a quick diagnostic before any major refactoring.' This gives clear when-to-use guidance. It doesn't explicitly state when not to use, but given sibling tool variety, the context implies this is a high-level overview.

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

Deploy Server

Other Tools