Skip to main content
Glama
apettey

eve-esi-mcp

by apettey

Analyze an EFT fit

fitting_analyze
Read-only

Parses EFT fitting text into a detailed breakdown of names, resources, ship stats, module attributes, skill checks, and engine metrics without saving changes.

Instructions

Parses any EFT text (from the user, Pyfa, zKillboard, ...) and returns the same rich breakdown as fitting_get: resolved names, resource usage, ship stats/bonuses, module attributes, skill check against a character and DNA, plus engine stats (EHP, DPS, cap, speed, real CPU/PG) when eve-fit is configured. Does not save anything.

Input Schema

NameRequiredDescriptionDefault
eftYesEFT text starting with [Ship, Name].
characterNoCharacter name or id to act as. Defaults to the active character (see characters_list / character_select).
attributesNoPer-module attribute detail: none, summary (default; fitting-relevant categories) or full.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and external-world behavior are covered. The description adds useful behavioral context: engine stats only appear when eve-fit is configured, and the tool does not persist anything.

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 front-loaded with the core action and return shape, then moves to the non-saving caveat. Despite being a single dense sentence, every clause adds useful scope or output information without redundant filler.

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?

For a three-parameter analysis tool with full schema coverage and annotations, the description is complete enough: it explains input sources, the returned breakdown, the character/skill aspect, the eve-fit dependency, and the fact that nothing is saved. No output schema exists, and the description still summarizes the return value effectively.

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 fully documented in the schema. The description does not add parameter-specific syntax or usage details beyond what the schema provides, making the baseline 3 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 gives a specific verb and resource: it parses any EFT text and returns a rich fitting breakdown. It distinguishes itself from fitting_get by accepting arbitrary EFT input from sources like Pyfa or zKillboard, and from fitting_save by explicitly stating it does not save anything.

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 clearly establishes the context for use: when the caller has EFT text from a user, Pyfa, zKillboard, etc., and wants the same breakdown as fitting_get without saving. It does not explicitly name fitting_get as the alternative for saved fittings or list exclusions, so it stops short of a full when/when-not routing guide.

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