Skip to main content
Glama
apettey

eve-esi-mcp

by apettey

Character overview

character_overview
Read-only

Fetch a one-call snapshot of an EVE Online character's corporation, location, ship, wallet, skills, clones, jump fatigue, and loyalty points; unavailable sections are reported, not failed.

Instructions

One-call snapshot of a character: corp/alliance, security status, online state, current system/station, active ship, wallet, SP and what's training, clones and implants (with clone-jump availability), jump fatigue and loyalty points. Sections the character has no scope for are reported under 'unavailable' rather than failing.

Input Schema

NameRequiredDescriptionDefault
sectionsNoLimit to these sections (default all).
characterNoCharacter name or id to act as. Defaults to the active character (see characters_list / character_select).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, and the description adds genuinely non-obvious behavior: sections without scope are reported under 'unavailable' rather than failing, and clone-jump availability is included. That partial-failure contract is the key operational trait an agent needs, though permission/auth requirements are not spelled out.

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?

Front-loaded with the 'one-call snapshot' framing, then a dense but purposeful enumeration, closing with the failure-mode caveat. No filler sentences, though the long field list is a single breathless clause.

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?

There is no output schema, so the description carries the return-value burden itself and does so by enumerating every section and the 'unavailable' bucket. Combined with 100% schema coverage on the two inputs, an agent has everything needed to invoke and interpret it.

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?

Schema coverage is 100%, so both parameters are already documented. The description still adds value by mapping the section enum members to concrete content (e.g. 'fatigue' = jump fatigue, 'skills' = SP and what's training), clarifying what each section selection actually returns.

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?

States a specific verb+resource ('One-call snapshot of a character') and then enumerates the exact contents: corp/alliance, security status, online state, system/station, ship, wallet, SP, clones/implants, fatigue, loyalty points. This is unmistakably distinguishable from narrow siblings like character_skills or wallet.

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?

'One-call snapshot' plus the default-all-sections behavior makes clear this is the aggregate read to use when you want breadth in a single call, with the 'sections' param for narrowing. It stops short of explicitly naming alternatives (character_skills, wallet) that an agent could call instead for a single concern.

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