eve-mentor-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.2
Disambiguation4/5
Each tool has a clear, distinct purpose, but a few pairs could be confused at a glance (e.g., system_intel vs route_danger, or lookup_item vs where_to_buy). Descriptions are detailed enough to resolve ambiguity in practice.
Naming Consistency3/5
Naming mixes verb-first (lookup_item, analyze_fit, remember_goal) with noun-first (system_intel, recent_losses, character_sheet) and even full phrases (what_should_i_do_tonight, cheapest_way_to_play). All use snake_case, but the lack of a consistent verb_noun pattern is noticeable.
Tool Count2/5
At 26 tools, the set is just over the typical 'heavy' threshold. While the broad scope of EVE mentoring justifies many tools, the count edges into bloat territory and could overwhelm an agent.
Completeness5/5
The tool surface covers the full mentoring lifecycle: character awareness, skill planning, fit analysis, market/economy, navigation safety, corp evaluation, and session guidance. Obvious gaps are minor (e.g., no direct 'find a corp' finder, but evaluate_corp supports vetting).
Average 4/5 across 26 of 26 tools scored. Lowest: 3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 28 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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 only states what the queue is, not whether the tool is read-only, what return format to expect, or whether authentication is required (though 'logged-in' implies it). Significant behavioral context is missing.
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, short sentence with no fluff. It is front-loaded and every word adds value, making it appropriately concise for a tool with no parameters.
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?
The tool is low complexity (no params, no output schema), but the description is still quite sparse. It does not mention authentication prerequisites, what the queue includes, or how it relates to sibling tools. It is minimally adequate but leaves gaps in context.
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 trivially covers 100% of parameters. Per the rubric, a baseline of 4 applies. The description adds no parameter information, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a noun phrase identifying the resource ('current skill training queue') and its scope ('logged-in character'), but it lacks a verb telling what the tool does. It is more of a label than a statement of purpose, making it vague compared to action-oriented definitions.
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 use this tool versus alternatives such as top_skills or character_sheet. No context, exclusions, or prerequisites are mentioned, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden of behavioral disclosure. It does not mention whether this is a read-only operation, what 'logged in' means (e.g., in-game vs. app session), or what the return value looks like, leaving significant ambiguity for a status-check tool.
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 with no redundant wording. It is appropriately sized for a simple tool, though it could be slightly more informative without becoming verbose.
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 tool with no parameters and no output schema, the description covers the core purpose but leaves out important context such as the exact interpretation of 'logged in' and response format. It is minimally adequate but not complete for an agent to fully predict behavior.
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 accepts zero parameters, and the schema coverage is 100% (vacuously). The description correctly adds no parameter information because there is nothing to add, achieving the baseline 4 for a no-parameter tool.
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 with a specific verb and resource ('Check whether an EVE character is currently logged in'). It is distinguishable from siblings like eve_login, though it does not explicitly differentiate itself.
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 use this tool versus alternatives. There are no exclusion criteria, prerequisites, or references to sibling tools, leaving the agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 that the tool returns the highest-trained skills, but does not describe ordering (e.g., by skill points or level), whether the result is a list or detailed objects, pagination, or authentication requirements beyond 'logged-in character.' It also adds the interpretive claim about 'fly well' but doesn't explain how to interpret the data. More behavioral context (e.g., 'returns a sorted list of skill typeIDs and levels') is needed.
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, front-loaded sentence. It states the core purpose and a beneficial use case without unnecessary filler. Every word earns its place, and it is appropriately sized for a tool with one parameter and no output schema.
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?
The tool is simple (one optional parameter, no output schema), and the description gives the essential idea. However, the lack of an output schema and annotations means the description should clarify what 'highest-trained' means (e.g., by skill points or level) and what the response format looks like. While the tool seems straightforward, the ambiguity around 'highest-trained' and the absence of return details leave gaps that a more complete description could fill.
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 covers the single parameter 'limit' with a clear description ('How many skills (1-50)'), a default of 15, and min/max bounds. Since schema description coverage is 100%, the baseline is 3. The tool description does not add any extra semantic detail about the parameter, but none is necessary because the schema fully explains it.
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 identifies the tool's output: the logged-in character's highest-trained skills. It implies a retrieval action (get/list) and specifies the resource (skills) and scope (logged-in character). It distinguishes from siblings like skill_queue (queue) and character_sheet (broader sheet), though it doesn't explicitly name them. The verb is implicit but the intent is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a use case: 'useful for judging what they can fly well.' This implies when to use it, but it does not mention alternatives or exclusions. Sibling tools like can_i_fly or character_sheet might overlap, but no guidance is given for choosing between them. The usage context is clear enough for a simple tool, but lacks explicit when-to-use-vs-alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It adds value by stating the return content (description and Jita market prices) and the exact-name matching requirement. However, it does not mention error behavior, case sensitivity, or price details (e.g., buy/sell, update timing), which limits transparency.
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, front-loaded sentence that communicates the action, scope, and return value without redundancy or unnecessary detail. Every word contributes to the meaning.
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 the simple one-parameter tool and no output schema, the description sufficiently covers the essential context: what the tool does, what input is needed, and what is returned. It could be more explicit about the nature of market prices (e.g., buy/sell, current/regional), but for a basic item lookup this is adequate.
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 documents the `name` parameter with examples ('Rifter', 'Damage Control II') and indicates exactness. The description merely repeats 'exact name' and adds no new meaning beyond the schema, so with 100% schema coverage, the baseline score 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 states a clear action ('Look up') and resource ('any EVE item, ship, or module'), and specifies the return value (description and Jita market prices). It does not explicitly differentiate from sibling tools like `where_to_buy`, but the purpose is unambiguous.
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 use this tool versus alternatives. The description solely states what it does without any context for selection, exclusion, or relation to sibling tools. The requirement for an 'exact name' is the closest hint to usage, but it is not framed as guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the report's content scope ('in the last hour'), but does not comment on side effects, permissions, or whether the tool is read-only. Since it's clearly a read-style report, some transparency is implicit, but it falls short of full disclosure.
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?
One tightly worded sentence front-loads the core purpose ('Danger report') and packs specifics into a compact form. Every word contributes, with no redundancy or filler.
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 single-parameter tool with a well-described schema, the description provides enough context: it states what data is included (security status, kills, traffic) and the time horizon. It could mention whether authentication is needed, but given the simple query nature, it is 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 schema description for 'system_name' is thorough with examples, covering 100% of parameters. The tool description adds no additional parameter meaning, but with high schema coverage, baseline 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 clearly states the tool produces a danger report for a solar system, listing specific data (security status, kills, traffic). It distinguishes from siblings like route_danger or recent_losses by focusing on a single system's current danger. However, it lacks an explicit verb, so it doesn't fully meet the 5-level bar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need danger intel for a specific system, but it provides no explicit when-to-use guidance, exclusions, or alternatives. The sibling tools are not referenced, so an agent must infer when to select this over route_danger or sitrep.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It mentions persistence across sessions and per-character storage, which are useful. However, it does not specify duplicate handling, overwrite semantics, or any confirmation/return behavior, leaving gaps in transparency.
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 three sentences, front-loaded with the key action, and every sentence adds meaningful value. Examples are compact and the usage guidance is crisp.
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 tool with no output schema, the description covers purpose, usage, and persistence scope. However, it could be more complete by addressing what happens on duplicate goals or how the stored goals can be retrieved, leaving some ambiguity for a new agent.
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 fully documents the single 'goal' parameter ('The goal in the player's own terms, one ambition per call'), so the baseline is 3. The description adds illustrative examples and the notion of a 'direction worth steering toward later,' which slightly enriches context but does not fundamentally extend the schema.
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 with a specific verb ('save') and resource ('goal or ambition'), and includes concrete examples. However, it does not explicitly differentiate from sibling tools like recall_pilot_notes, so it falls short of a 5.
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 provides an explicit trigger: 'Call this whenever the player expresses a direction worth steering toward later.' This gives clear context on when to use it, but it omits any exclusions or alternatives when another tool might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key behavioral trait: the jump-distance feature only works 'when logged in', implying an authentication requirement. However, it does not mention other behaviors such as error handling for invalid item names, data freshness, or whether the tool is read-only. With no annotations provided, the description carries the full burden but only partially fulfills it.
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, reasonably concise sentence that packs the main action, the list of hubs, the conditional feature, and the intended benefit. It is front-loaded with the verb 'compares' and remains readable without excessive fluff, though the final clause could be trimmed without losing essential meaning.
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 explains the core functionality and the conditional feature, giving a clear sense of what the tool returns: a comparison of sell prices across hubs and, when logged in, jump distances. With no output schema, it does not specify the exact return format, but it is adequate for a simple single-parameter 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?
The input schema already provides a clear description for the single parameter (item_name) with an example. The tool description merely references 'an item' without adding new formatting or constraint details beyond the schema, so it does not go beyond the schema. Since schema coverage is 100%, 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 clearly states the tool's purpose: comparing an item's cheapest sell price across five specific trade hubs, with an optional jump-distance feature when logged in. It uses the specific verb 'compares' and identifies the exact resource and scope, distinguishing it from sibling tools like lookup_item or system_intel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for deciding where to buy an item by weighing price against haul distance, but it does not explicitly state when to use it over alternatives or mention any exclusions. The phrase 'so you can weigh price against the haul' suggests a use case, but there is no direct comparison to sibling tools or conditions like 'use this if you need the cheapest hub'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden but adds useful context: it sources from zKillboard and requires no login. However, it doesn't disclose aspects like data freshness, whether losses are all types or only recent ones, or potential rate limits. It is enough for a simple read-only lookup but lacks deeper behavioral detail.
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 long and front-loaded with the core function. Every phrase earns its place: the source, the fit detail, the purpose, and the no-login requirement. 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?
Given the tool's simplicity (2 params, no output schema), the description covers the key aspects: what it returns (losses with full fit detail), the source (zKillboard), authentication (none needed), and purpose (explaining why they died). It does not describe the exact output format or error conditions, but these are less critical for a straightforward list 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?
The schema already covers both parameters with clear descriptions: character_name requires an exact name, and limit is an integer from 1-10 with a default of 3. The description doesn't add parameter-specific meaning beyond the schema, so the high coverage baseline of 3 applies.
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 returns a character's recent ship losses from zKillboard, with full fit detail. It specifies the resource (losses), the source (zKillboard), and the detail level (full fit), distinguishing it from sibling tools like analyze_fit or fit_readiness. The phrase 'raw material for explaining why they died' reinforces its specific purpose.
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 provides clear context: it is the raw material for explaining why a character died, and it notes that it works for any character name without login. This implies when to use it, but it does not explicitly mention alternatives or when not to use it compared to other sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It explains it uses the logged-in character's skillpoints, wallet, location security, current ship, and training queue, and that it returns building blocks rather than final suggestions. This is useful behavioral context, though it omits details like response format or potential errors.
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 three sentences and every sentence adds relevant detail: what the tool does, what it returns, and the login requirement. It is appropriately sized, though it could be tightened slightly.
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 annotations, the description does a solid job explaining the tool's inputs, process, and output nature. It clarifies that output is raw building blocks for the agent to turn into suggestions, which is essential for correct invocation. It lacks some edge-case detail but is reasonably complete for a zero-parameter 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 baseline is 4. The description adds useful semantics by explaining what data the tool composes internally, which compensates for the lack of input schema.
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 answers the question 'what should I actually do right now?' by composing the character's situation with income options. It identifies the resource (the logged-in character's current state) and distinguishes itself from siblings by generating session suggestions rather than just providing data.
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 gives clear context for when to use it: when the user asks for immediate activity suggestions. It also notes a prerequisite (requires login) but does not mention alternative tools or exclusions, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 meaningful behavior by noting it includes concrete ammo names per weapon system and covers both offense and tanking. This goes beyond a simple statement of purpose.
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, front-loaded with the core purpose, and no redundant filler. Every word contributes to the description.
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?
The tool has only one parameter and a simple advisory purpose. The description fully covers what the tool does and what it returns, so an agent can route requests correctly without needing an output schema.
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 already provides a clear description of the 'target' parameter, covering 100% of the semantics. The description adds extra examples of factions but does not introduce new meaning beyond the schema.
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 purpose: advising on which damage types to shoot and tank against specific targets. It lists the supported factions and player tank types, but does not explicitly differentiate itself from sibling tools.
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 provides clear context for when to use the tool: whenever damage types are needed for NPC pirate factions or shield/armor-tanked players. However, it does not state any when-not conditions or alternative tool recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses data sources (ESI + zKillboard), what the tool returns (signals, questions), and explicitly states limitations ('The API can't see recruitment status or culture — be honest about that'). This is strong behavioral disclosure, though it could mention whether auth is required or any other side effects.
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 two sentences and front-loads the core purpose. The first sentence is slightly dense with a list, but every part adds value. It is concise and structured clearly, though a bit packed.
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 one parameter, no output schema, and no annotations, the description explains what the tool returns (signals and questions) and its limitations. For a query tool of this complexity, the description is complete enough for an agent to understand scope and limitations, though it does not detail output format.
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%: corp_name is described as 'The full corporation name (not the ticker), exactly.' The description adds only 'exact name,' which reinforces but doesn't enrich beyond the schema. Baseline 3 is appropriate due to high schema coverage.
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 provides 'Newbie-friendliness signals for a corporation by exact name' and lists the specific data points (size, age, war exposure, recent activity) and sources (ESI + zKillboard). This distinguishes it from sibling tools like system_intel and recent_losses by focusing on corp evaluation for new players.
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 gives explicit usage context: 'Use it to sanity-check a corp before the player applies.' This tells when to use the tool, though it does not mention specific alternatives or exclusions. The context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It notes that it provides 'live numbers' and 'today's actual Jita price', indicating real-time data fetching. However, it does not explicitly state whether authentication is required, whether it is read-only, or any limitations. This is adequate but leaves some gap.
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, long sentence but well-structured with a colon and list, front-loading the main topic. Every part adds value, though it is slightly dense. It earns a 4 for being efficient without being sparse.
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 zero-parameter informational tool with no output schema, the description fully covers what the tool does: explains Alpha/Omega, PLEX, Jita price, and gives a recommendation. It is complete for its complexity level.
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 baseline is 4. The description adds no parameter-specific meaning because there are no parameters to document. This 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 identifies the tool's purpose: explaining EVE's pay-vs-play economy, including Alpha vs Omega, PLEX, Jita price, and a recommendation. It is specific and distinct from sibling tools like isk_guidance or what_should_i_do_tonight, which focus on different aspects.
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 implies usage for players wanting to understand cost options in EVE, but it does not explicitly state when to use this tool versus alternatives or mention any exclusions. The context is clear, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 discloses key behavioral traits: it opens a browser for SSO and imposes a 3-minute completion window. However, it doesn't mention what happens after login (e.g., session persistence, return values), which would add more transparency.
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—two sentences, front-loaded with the action verb. Every word earns its place, with no filler or redundancy.
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 login flow with no parameters and no output schema, the description covers the essential action and the time constraint. It could be more complete by noting what happens after successful login (e.g., whether it establishes a session), but given the low complexity, it is sufficiently informative.
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 baseline is 4. The description doesn't need to explain parameters, and the empty schema is self-explanatory.
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 purpose: 'Start the EVE Online login flow' with a specific mechanism ('Opens a browser for SSO'). This distinguishes it from the sibling tool eve_auth_status, which likely checks login status rather than initiating login.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied—use when the user wants to initiate EVE Online login—but there is no explicit guidance on when to use this tool versus alternatives like eve_auth_status, nor any exclusions or prerequisites. The presence of a sibling status tool makes this differentiation valuable, but it's absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure. It explains that this is a read-only analysis, personalizes against the logged-in character, and falls back to listing all required skills when not logged in. No hidden side effects are implied.
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 concise sentences, front-loaded with the action and input format. Every clause adds valuable detail about the output and login-dependent behavior, with no filler.
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 the simple single-parameter schema, no annotations, and no output schema, the description covers input format, processing behavior, output contents, and auth nuance. Minor edge-case details (e.g., malformed fit errors) are omitted, but they are not essential for typical use.
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 already provides full coverage for the single 'fit' parameter, including a format example. The description adds sourcing context (fitting sites, PyFA, in-game export) but does not materially change parameter semantics beyond 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 clearly states the input (EFT-format fit text) and the output (can-fly verdict with missing skills, training order, skillpoints, and days). It distinguishes the tool from siblings by emphasizing EFT fit text as the input and the skill/training-focused result.
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 usage context is explicit: paste an EFT fit to get a verdict, with clear behavior for logged-in vs anonymous use. It does not name alternative tools or say when not to use it, but the intended scenario is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 a useful behavior (flagging asset-safety wraps and undockable structures) and implies a read-only listing, but does not explicitly state safety, data freshness, or permissions. It adds some behavioral context beyond a simple list, but not complete transparency.
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 purpose, then a specific use case and behavioral note. Every sentence adds value with no wasted words.
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 the tool is simple with zero parameters and no output schema, the description covers the main return value (owned assets grouped by location) and a notable feature (flagging). It is sufficient for typical use, though it omits details like pagination or exact format of the output.
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, and schema coverage is trivially 100%. The baseline is 4, and the description appropriately does not attempt to explain parameters. It focuses on the meaning of the output, which is useful.
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 lists everything the logged-in character owns, grouped by location, and specifically mentions the additional capability of flagging asset-safety wraps and undockable structures. This is a specific verb+resource+scope that distinguishes it from sibling tools like lookup_item or recent_losses.
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 provides a clear use case: 'use this to find stuff stranded from years ago.' It doesn't explicitly mention when not to use it or name alternatives, but the use case gives the agent adequate context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the transparency burden. It discloses the data source (recent killmails) and the output nature (module frequencies per slot), implying a read-only operation. However, it does not mention edge cases like insufficient killmail data, ship name validation, or whether authentication is needed. The description adds context beyond the basic function but lacks depth on failure modes.
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: the first states the core functionality and output, the second provides usage guidance. It is front-loaded, information-dense, and free of fluff. Every sentence earns its place.
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 relatively simple lookup tool with 2 parameters and no output schema, the description explains what it returns (common modules per slot with frequencies) and how to use it. It lacks details on error behavior or data freshness, but it is sufficient for an agent to select and invoke the tool correctly in most scenarios.
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?
Input schema covers both parameters with descriptions (100% coverage), so the baseline is 3. The tool description does not add significant new meaning to the parameters; it merely reinforces that data comes from recent killmails, which is already implied by the sample parameter. No additional semantic value 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 clearly states the tool's purpose: it shows the most common modules pilots use per slot on a given ship, learned from recent killmails. This specific output distinguishes it from siblings like analyze_fit (which checks a specific fit) and can_i_fly (which checks requirements). The verb 'learned' and the resource 'killmails' make the function concrete.
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 description explicitly says to use it for proposing a realistic starter fit, and then sanity-check with analyze_fit and can_i_fly. This provides clear workflow guidance and names alternatives for subsequent steps. It effectively tells the agent when to invoke this tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses that the tool produces a per-jump report including security, last-hour kill activity, and chokepoints, which fully conveys what the tool does behaviorally. It does not discuss authentication or side effects, but as a read-only report, the description provides appropriate transparency.
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 main purpose, then adds a usage directive. Every word earns its place with no fluff. This is an excellent example of conciseness.
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 tool with no output schema and no annotations, the description explains the report contents (security, kill activity, chokepoints) and when to use it. It is complete enough for an agent to select and invoke the tool correctly. Slight lack of detail on return format, but not required given the clarity of the description.
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 all parameters. The description adds context about high-sec chokepoints and per-jump analysis but does not add new semantics beyond what the schema provides. Baseline 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 a specific verb+resource: 'per-jump safety report for a journey between two systems.' It distinguishes itself from siblings like system_intel or recent_losses by focusing on route-level safety (each system's security, kill activity, and gank chokepoints). This is specific and unambiguous.
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 provides explicit context: 'Use it before anyone undocks for a long haul.' This tells when to use the tool. It does not mention when not to use it or list alternatives, but the clear use case is sufficient for a score of 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It implies an informational, read-only briefing but doesn't explicitly state safety (e.g., read-only, no side effects). The content scope is disclosed well, but behavioral traits like whether it requires auth or caches data are absent.
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 concise sentences, front-loaded with the purpose and a clear player context. No redundant words, every phrase 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?
For a zero-parameter briefing tool with no output schema, the description sufficiently covers the key content areas. It might optionally mention format or update frequency, but the described scope is complete for the use case.
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 schema coverage is trivially 100%. The description doesn't need to explain params and adds context about the briefing content, which is appropriate. Baseline for 0 params is 4.
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 provides a briefing for new or returning players, listing specific content: live server status, active incursions, recent kills, and patch notes. This distinctly positions it against siblings like recent_losses or system_intel.
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 states it's good for someone logging back in after time away, giving a clear use case. It doesn't explicitly discourage use in other contexts, but the targeting is strong enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 discloses the recursive skill tree, ordered training plan, total skillpoints, estimated time, and the logged-in diff behavior. This exceeds minimal expectations but does not mention potential error conditions or whether login is required.
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 a question that frames the purpose and immediately lists the outputs. No redundant wording or fluff.
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?
Given the single parameter and no output schema, the description fully explains what will be returned (recursive tree, training plan, skillpoints, time) and the conditional diff. It is complete for a tool of this simplicity.
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% with a clear description of item_name ('Exact ship or module name'). The tool description adds little beyond the schema, but since the schema fully covers the parameter, the baseline 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 purpose: returns skill prerequisites and training plan for a given ship or module. It clearly distinguishes itself from sibling tools like fit_readiness or skill_queue by focusing on the item-to-skill requirement relationship.
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 provides clear context for when to use the tool (checking what is needed to fly/use an item) and mentions the conditional diff against a logged-in character. It does not explicitly name alternatives or when-not-to-use cases, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the key behavioral modes: passing a term defines it, omitting the term lists everything. This covers the core operational behavior. It doesn't detail return format or side effects, but the behavior is simple and sufficiently exposed.
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, front-loaded with the tool's purpose, followed by usage context and examples. Every word earns its place; no fluff or redundancy.
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?
Given the simplicity of the tool (1 optional parameter, no output schema), the description fully covers its purpose, usage, and behavior. It explains both invocation modes and provides examples, making it complete for an AI agent to select and call correctly.
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 already documents the single parameter with 100% coverage ('The slang term to define; omit to list all terms'). The description adds similar phrasing ('Pass a term to define it') but no additional semantic value 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 clearly states it's an EVE slang glossary, with a specific verb ('define') and resource ('slang glossary'). It distinguishes from sibling tools like lookup_item and system_intel by focusing on slang terminology, and provides concrete examples.
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 whenever the player hits a word like...', giving clear context for when to invoke the tool. It doesn't mention when not to use or alternatives, but the guidance is direct and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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. It discloses the tool's behavior by listing what it detects: mixed weapon systems, mixed shield+armor tank, no propulsion, damage mods without matching weapons. The phrase 'explain the findings' implies the tool returns findings, though the exact output format is not specified. This is adequate for a simple analysis tool.
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: the first immediately states the purpose with examples, the second gives usage direction. Every word is purposeful, with no filler or redundancy It is front-loaded and easy to parse.
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 the tool's simplicity (one array parameter, no output schema), the description covers the essentials: purpose, usage, and detection categories. It could specify the return format more explicitly, but the instruction to 'explain the findings' implies a useful output. For a straightforward analysis tool, this is largely 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?
The input schema already documents module_names as 'exactly as they appear in the fit/killmail'. The description adds value by instructing to feed names 'from a loss report or a pasted fit', giving the agent context on where to source the data. This goes slightly beyond the schema's description, so a 4 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's function: 'Mechanical fit check: classifies each module by type and detects classic mistakes' with concrete examples. This distinguishes it from sibling tools like lookup_item, system_intel, or ammo_advisor, which focus on other aspects. The verb 'classifies' and resource 'modules' are specific and unambiguous.
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 provides clear usage context: 'Feed it module names from a loss report or a pasted fit'. It does not explicitly name alternatives or exclusions, but the domain is well-defined and distinct from siblings, so the agent can infer when to use it. A small gap is the lack of explicit 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 discloses what data is returned (login state, character overview, training, recent loss) and that it does so 'in one call,' implying an efficient aggregation. However, it does not state potential side effects or prerequisites beyond the situation, which is acceptable for a report tool.
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 core purpose and then providing a concise list of included data. It wastes no words and clearly earns its place by covering both function and usage.
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 the zero-parameter, no-output-schema context, the description is nearly complete. It tells the user exactly what information will be provided and when to use it. A minor gap is not explicitly describing the format or order of the report, but the description is sufficient for orientation purposes.
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, and the schema coverage is 100% (empty schema). Per the baseline for 0 params, a score of 4 is appropriate. The description adds no parameter-specific meaning because there are none to explain, but it clarifies the output content that the parameterless call will return.
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 purpose as a 'Session-start situation report' that aggregates login state, character overview, training, and recent loss. This specific verb+resource framing distinguishes it from sibling tools like character_sheet, skill_queue, and recent_losses, which provide individual pieces of this information.
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?
Explicit usage guidance is provided: 'Call this at the start of a mentoring session to orient.' The context is clear, but it does not explicitly mention when not to use it or alternative tools, though the one-call aggregation implies a primary use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 transparently frames the tool as returning static data ('Data for...'), lists the returned trait categories, and clarifies that matching/recommendation is the caller's follow-up. It does not explicitly state 'read-only' or mention lack of side effects, but the intent is clear and no contradictions exist.
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—two succinct sentences plus a usage clause. It front-loads the purpose, then packs trait details and workflow into a compact, scannable form. Every sentence earns its place with no repetition or 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 tool with zero parameters and no output schema, the description is remarkably complete. It explains what is returned (all career paths with specific trait categories), how to use it (interview first, then call, then match), and even how to follow up (recommend concrete steps). No other details are necessary for an agent to invoke it correctly.
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 0 parameters, so per the rubric the baseline is 4. The description adds no parameter-specific meaning (and none is needed). It focuses on the return value and usage, which is appropriate for a no-input tool.
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 identifies a specific resource (EVE career paths) and verb ('Returns'), listing what is included (traits like social/risk/income/activity). This distinguishes it from sibling tools like 'what_should_i_do_tonight' by focusing on comprehensive career path data rather than suggesting immediate activities.
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?
Explicit usage guidance is provided: interview the player about preferences, then call this tool, then match answers to 2-3 paths, and recommend first steps. It does not name alternatives or state when not to use it, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 transparently lists the returned data (total skillpoints, wallet, current location, ship) and implies a read-only informational operation. It does not mention error cases, but for a simple overview this is acceptable.
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, well-structured sentence that front-loads the purpose and enumerates the specific outputs. Every word earns its place, with no redundancy.
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 parameterless overview tool, the description is fully complete: it identifies the target resource (logged-in character), the action (overview), and the specific fields returned. No output schema exists, but the description itself provides sufficient enumeration.
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 description adds no parameter-specific meaning. Baseline 4 is appropriate since there is nothing to document.
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 provides an 'overview' of the logged-in character with specific data points (skillpoints, wallet, location, ship). This distinguishes it from siblings like skill_queue or my_assets which focus on more specific subsets.
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 implies usage when a quick summary of the character is needed, and the 'logged-in' qualifier suggests it requires an active session. It does not explicitly name alternatives or exclusions, but the context is clear enough for most selection scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It honestly discloses that ISK/hour ranges are 'rough community consensus, not live data' and warns never to present them as guarantees. It also clarifies the tool's scope by mentioning the skillpoint tier tiers and what each entry includes (range, requirements, first step), which sets appropriate expectations for the user.
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 three sentences with no fluff: the first sentence covers content and structure, the second gives usage context and policy guidance, and the third provides a critical caveat. Every sentence earns its place, making it compact yet highly informative.
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?
Given that there is no output schema and no annotations, the description thoroughly covers what the tool returns (ISK/hour ranges, requirements, first step), how to use it (by skillpoint tier), and important limitations (non-guaranteed estimates). It is complete for a guidance tool with no parameters, leaving no critical gaps for an agent to misinterpret.
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 input schema has 0 parameters, so there are no parameter descriptions to enhance. The baseline for 0 parameters is 4, and the description compensates by explaining that the tool uses the player's skillpoint tier (likely from context), making the input behavior clear without needing explicit parameters.
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 purpose: providing viable ways to make ISK matched to skillpoint tiers, with honest ISK/hour ranges, requirements, and first steps. It explicitly says to use it to answer 'how do I make money?' and differentiates from sibling tools by focusing on income generation rather than items, intel, fits, or other activities.
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 explicitly says 'Use it to answer 'how do I make money?' for someone's actual stage,' which gives clear when-to-use guidance. It also provides directional advice (point new players at high-ratio activities like exploration over mining, and away from grinds that only pay at high skillpoints). It does not name specific alternative tools or explicitly state when not to use it, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the tool returns previously remembered goals in chronological order (oldest first), which is a meaningful behavioral detail. It does not explicitly state read-only behavior, but the name and wording imply it, and no side effects are suggested.
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, front-loaded with the core purpose, and no redundant details. Every word earns its place.
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 tool with no parameters, no output schema, and none of the complexity of siblings, this description is complete. It explains what is returned, the order, and when to use it, which is sufficient for a simple recall operation.
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, and the schema covers them fully (100% by absence). The description adds no parameter details, but none are needed. Baseline for zero parameters is 4.
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 recalls previously remembered goals, ordered oldest first. It uses a specific verb ('recall') and resource ('pilot notes'), and the mention of 'what_should_i_do_tonight' in usage distinguishes it from that sibling.
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?
Explicit guidance is provided: call at the start of a session or alongside what_should_i_do_tonight to resume context and steer coaching. This gives clear when-to-use context and implies an alternative, satisfying the usage guideline requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![eve-mentor-mcp MCP server](https://glama.ai/mcp/servers/henryjrobinson/eve-mentor-mcp/badges/card.svg)](https://glama.ai/mcp/servers/henryjrobinson/eve-mentor-mcp)

Score Badge

Copy to your README.md:

[![eve-mentor-mcp MCP server](https://glama.ai/mcp/servers/henryjrobinson/eve-mentor-mcp/badges/score.svg)](https://glama.ai/mcp/servers/henryjrobinson/eve-mentor-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/henryjrobinson/eve-mentor-mcp'

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