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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions what the tool does ('Search character assets') and what it shows ('location and quantity'), but lacks critical details such as authentication requirements, rate limits, pagination behavior, error handling, or whether it's read-only or mutative. For a search tool with no annotation coverage, this is a significant gap.

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

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

The description is extremely concise and front-loaded: a single sentence that efficiently conveys the core functionality. Every word earns its place, with no redundant or vague phrasing. It's appropriately sized for a search tool with clear parameters.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (search with filtering), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like authentication needs, result format, or error conditions. While the schema handles parameters well, the description fails to compensate for missing context, making it inadequate for safe and effective use by an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, meaning all parameters are documented in the schema. The description adds minimal value beyond the schema, mentioning 'item name or type' (hinting at the 'search' parameter) and 'location' (hinting at 'location_name'), but doesn't provide additional context like search syntax, case sensitivity, or default behaviors. With high schema coverage, the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Search character assets by item name or type. Shows location and quantity.' It specifies the verb ('Search'), resource ('character assets'), and scope (search criteria and displayed information). However, it doesn't explicitly differentiate from sibling tools like 'eve_search' or 'eve_type_info', which might have overlapping functionality.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'eve_search' (general search) or 'eve_type_info' (item details), nor does it specify prerequisites such as authentication or character selection. Usage context is implied but not explicitly stated.

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

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 describes a read-only list operation, but does not disclose behavioral traits such as whether it requires authentication, how data is retrieved (e.g., from cache or live API), potential rate limits, or error conditions. The description is minimal and lacks context beyond the basic action.

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

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

The description is a single, efficient sentence that front-loads the key action ('List all linked EVE characters') and adds specific details about the output. There is no wasted text, and it is appropriately sized for a simple tool with no parameters.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters, no annotations, and no output schema, the description is minimal but complete for a basic list operation. However, it lacks details on authentication requirements, data freshness, or output format, which could be important for an AI agent to use it correctly in context with sibling tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has 0 parameters, and schema description coverage is 100% (since there are no parameters to describe). The description does not need to add parameter semantics, and a baseline score of 4 is appropriate as it adequately covers the tool's purpose without unnecessary parameter details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('List') and resource ('all linked EVE characters'), specifying the scope with details about what information is included (IDs, owner-account groupings, active status). It distinguishes itself from siblings like 'eve_auth_status' or 'eve_character_info' by focusing on authentication-linked characters rather than general status or character details.

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

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

The description implies usage when needing to view linked characters, but does not explicitly state when to use this tool versus alternatives like 'eve_auth_status' (which might show authentication state) or 'eve_character_info' (which provides details on a specific character). No exclusions or prerequisites are mentioned.

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

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 behavioral traits like opening a dashboard and supporting multiple accounts/characters, but lacks details on permissions, rate limits, or what the dashboard interaction entails (e.g., UI-based vs. programmatic).

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

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

The description is front-loaded with the main action ('Open the EVE MCP multi-character dashboard') and efficiently adds supporting details in two sentences, with no wasted words or redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations, no output schema, and low complexity (0 parameters), the description is somewhat complete but could benefit from more behavioral context (e.g., how the dashboard works, any side effects). It adequately covers the purpose but leaves gaps in operational details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has 0 parameters with 100% schema description coverage, so no parameter information is needed. The description does not add parameter semantics, but this is acceptable given the baseline for zero parameters is 4, as it adequately describes the tool's action without parameter details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verbs ('Open', 'Add, switch, or remove') and resources ('EVE MCP multi-character dashboard', 'characters'), distinguishing it from sibling tools like eve_auth_list_characters or eve_auth_remove_character by indicating it opens a dashboard for managing multiple characters rather than performing isolated actions.

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

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 this tool ('Add, switch, or remove characters', 'Multiple accounts and characters supported simultaneously'), but does not explicitly state when not to use it or name alternatives among siblings, such as using eve_auth_remove_character for removal only.

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

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 that the action is destructive (removal from local store) and mentions the consequence (need to re-authenticate), which is useful behavioral context. However, it doesn't cover other important aspects like whether this requires specific permissions, if the removal is permanent or reversible, or what the response looks like (e.g., success/failure message).

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

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

The description is two sentences that are front-loaded with the core action and follow with important consequence information. Every word earns its place—there's no redundancy, fluff, or unnecessary elaboration. It efficiently communicates both what the tool does and when to use it.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (a destructive operation with no annotations and no output schema), the description is reasonably complete. It covers the purpose, usage guidelines, and key behavioral consequence. However, it lacks details on permissions, response format, or error handling, which would be helpful for a mutation tool. The high schema coverage and clear purpose partially compensate for these gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, with the single parameter 'character' documented as 'Character name or character ID to remove'. The description doesn't add any additional parameter semantics beyond what the schema provides, but with 100% coverage and only one parameter, the baseline is high. A score of 4 reflects that the schema already does the heavy lifting, and the description doesn't need to compensate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Remove a character from the local store') and resource ('character'), distinguishing it from sibling tools like 'eve_auth_list_characters' (which lists characters) and 'eve_auth_login' (which adds/authenticates characters). The verb 'remove' is precise and unambiguous.

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

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

The description explicitly states when to use this tool ('Remove a character from the local store') and provides a clear alternative for re-adding a character ('They will need to re-authenticate via eve_auth_login'), directly naming the sibling tool. This gives the agent clear guidance on the tool's role in the authentication workflow.

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

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 behavioral trait of opening a dashboard, which implies a user-facing action (likely requiring user interaction or browser access). However, it lacks details on permissions, side effects (e.g., if it modifies state), or response format, leaving gaps in behavioral understanding.

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

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

The description is a single, efficient sentence that front-loads key information (alias relationship and action) with zero waste. Every word contributes to understanding the tool's purpose and usage, making it highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (simple alias with no parameters) and lack of annotations or output schema, the description is minimal but complete for its purpose. However, it could benefit from more context on how the dashboard functions or integration with other auth tools, leaving room for improvement in completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description does not add parameter semantics, but this is acceptable given the lack of parameters, warranting a baseline score of 4 as it adequately covers the tool's scope without unnecessary details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 an alias for 'eve_auth_login' and specifies the action ('opens the dashboard') and the resource/context ('for adding/switching characters'). It distinguishes itself from siblings like 'eve_auth_login' by indicating it's an alias, and from other auth tools (e.g., 'eve_auth_list_characters', 'eve_auth_status') by focusing on dashboard access.

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

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

The description implies usage context by stating it's for 'adding/switching characters', which suggests when to use it (e.g., for authentication or character management tasks). However, it does not explicitly state when not to use it or name alternatives beyond the alias reference, leaving some ambiguity compared to other auth tools.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool checks status and shows information, implying a read-only operation, but doesn't clarify whether it requires authentication, has rate limits, returns structured data, or handles errors. For a tool with zero annotation coverage, this leaves significant behavioral gaps.

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

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

The description is two concise sentences that front-load the core purpose ('Check authentication status') and immediately add key details ('Shows active char and token expiry'). Every word earns its place with no waste, making it easy to scan and understand quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers what the tool does but lacks context on prerequisites (e.g., requires linked characters), return format, or error handling. Without annotations or output schema, the description should do more to compensate, but it meets a minimum viable level.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to compensate for any parameter gaps, and it appropriately focuses on the tool's purpose without redundant parameter explanations. A baseline of 4 is applied since no parameters exist.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Check authentication status for all linked characters' specifies the verb (check) and resource (authentication status), and 'Shows active char and token expiry' adds detail about what information is returned. It distinguishes from siblings like eve_auth_login (authentication initiation) and eve_auth_list_characters (listing characters), though it doesn't explicitly name these alternatives.

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

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

The description implies usage context by mentioning 'all linked characters' and 'active char', suggesting it's for monitoring authentication state rather than initiating or modifying it. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like eve_auth_list_characters (which might list characters without status details) or when not to use it (e.g., if no characters are linked).

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool sets an active character for use by other tools, which implies a state change, but it doesn't cover critical aspects like whether this requires authentication, if it's reversible, potential side effects, or error conditions. For a tool that likely involves authentication or session management, this is a significant gap.

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

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

The description is extremely concise and front-loaded: it states the core purpose in the first sentence and adds crucial context in the second. Every sentence earns its place by providing essential information without any waste or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (state management for authentication), lack of annotations, and no output schema, the description is minimally adequate. It explains the purpose and usage but misses behavioral details like authentication requirements or error handling. The context signals show a simple parameter structure, which the description aligns with, but it doesn't fully compensate for the lack of annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, with the parameter 'character' documented as 'Character name or character ID to make active.' The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Set the active character.' It specifies the verb ('Set') and resource ('active character'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'eve_auth_list_characters' or 'eve_auth_remove_character' beyond the implied context of switching versus listing or removing.

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

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

The description provides explicit usage guidance: 'Tools without an explicit character_name parameter will use this one.' This clearly indicates when to use this tool (to set a default character for other tools) and implies when not to use it (if a tool already has a character_name parameter). It effectively distinguishes its role in the workflow without naming alternatives.

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

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 states it's a read operation ('Get'), but doesn't cover aspects like authentication requirements, rate limits, error conditions, or the format of returned effects. This is a significant gap for a tool with potential complexity in its output.

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

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

The description is a single, clear sentence that directly states the tool's purpose without any unnecessary words. It's front-loaded and efficiently communicates the core functionality, making it highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'effects' entail, how implants are structured in the response, or any behavioral nuances. For a tool that likely returns complex data (implants with effects), more context is needed to guide the agent effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, with one parameter 'as_character' fully documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline score of 3 for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and the resource 'currently plugged-in implants and their effects', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'eve_character_info' or 'eve_character_skills', which might also provide character-related data, so it doesn't reach the highest score.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites (e.g., authentication status) or compare it to sibling tools like 'eve_character_info' for broader character data, leaving the agent to infer usage context.

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

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 that the tool can fetch both private (linked alts) and public data, which is useful behavioral context. However, it doesn't mention authentication requirements, rate limits, error conditions, or what happens if both parameters are provided. For a tool with no annotations, this leaves gaps in behavioral understanding.

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

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

The description is two sentences: the first states the purpose and enumerates returned data, the second provides usage guidance. Every word earns its place with zero redundancy. It's front-loaded with the core purpose and efficiently structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description does well by specifying the data fields returned and parameter usage. However, it doesn't describe the return format (e.g., structured object vs list) or potential authentication needs for private data. For a tool with 2 parameters and rich functionality, it's mostly complete but could address behavioral aspects more fully.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both parameters well. The description adds meaningful semantics by explaining the purpose of each parameter ('linked alts' vs 'public info') and noting that 'as_character' defaults to active. This provides context beyond the schema's technical descriptions, though it doesn't add syntax or format details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Get') and resource ('character overview'), then enumerates specific data fields returned (name, corporation, alliance, etc.). It distinguishes this tool from siblings like 'eve_intel_character' (which likely provides different intel data) and 'eve_character_skills' (which focuses on skills only).

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

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

The description explicitly provides when-to-use guidance: 'Use "as_character" to query one of your linked alts; use "character_name" to look up someone else's public info.' This clarifies the two distinct use cases and parameter selection, addressing alternatives implicitly by explaining the purpose of each parameter.

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

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 mentions 'Get' implying a read operation, but doesn't specify if it requires authentication, has rate limits, or what the output format looks like (e.g., list structure, error handling). This leaves significant gaps for a tool that likely interacts with user data.

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

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

The description is a single, efficient sentence that front-loads the core purpose ('Get current skill training queue with finish times') with zero wasted words. It's appropriately sized for a simple tool and easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of accessing character-specific data in a game like EVE Online, the description is incomplete. With no annotations and no output schema, it fails to address critical aspects such as authentication requirements, data format, or error conditions, making it inadequate for safe and effective use by an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, with one parameter clearly documented as 'Linked character (name or ID) — defaults to active'. The description doesn't add any extra meaning beyond this, so it meets the baseline of 3 for high schema coverage without compensating value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('Get') and resource ('current skill training queue with finish times'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'eve_character_skills', which might provide related but different information, so it misses the highest score.

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

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

The description provides no guidance on when to use this tool versus alternatives, such as 'eve_character_skills' or other character-related tools. It lacks context about prerequisites, timing, or exclusions, leaving the agent to infer usage based on the purpose alone.

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

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 mentions the return values ('Returns trained level, active level, and SP per skill'), which adds useful context. However, it fails to disclose critical behavioral traits such as authentication requirements, rate limits, error conditions, or whether this is a read-only operation. For a tool with no annotations, this leaves significant 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.

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

The description is concise and front-loaded, stating the core purpose in the first clause. Both sentences earn their place by explaining functionality and return values. However, it could be slightly more structured by separating usage notes from output details, but it remains efficient with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is partially complete. It covers the basic purpose and return values, but lacks details on authentication, error handling, or sibling tool differentiation. Without annotations or output schema, the description should do more to compensate, but it provides a minimal viable explanation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 three parameters. The description adds some semantic context by mentioning filtering ('filter by skill group') and checking ('check specific skills'), which aligns with the schema but doesn't provide additional details like format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate as the description adds minimal value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Get character skills' specifies the verb and resource. It distinguishes from some siblings like 'eve_character_info' or 'eve_character_skillqueue' by focusing specifically on skills, though it doesn't explicitly contrast with all skill-related tools like 'eve_pi_skills'. The description is specific but not fully differentiated from all siblings.

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

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

The description implies usage through phrases like 'Can filter by skill group or check specific skills', suggesting when to use optional parameters. However, it lacks explicit guidance on when to choose this tool over alternatives like 'eve_character_info' (which might include skills) or 'eve_pi_skills' (for planetary interaction skills). No exclusions or prerequisites are mentioned, leaving usage context partially implied.

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

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 mentions the return types (tank stats, DPS estimates, capacitor info) and the use of Dogma attributes, but lacks details on behavioral traits such as error handling, performance characteristics, or any limitations (e.g., rate limits, authentication needs). This is a significant gap for a tool with no annotation coverage.

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

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

The description is a single, efficient sentence that front-loads the core functionality. It avoids unnecessary words and directly states the action, inputs, and outputs, making it easy to parse. However, it could be slightly more structured to explicitly separate input and output details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description provides basic context but is incomplete. It covers the purpose and return types but lacks details on behavioral aspects and output structure. For a tool with 2 parameters and no structured output information, this leaves gaps that could hinder an agent's ability to use it effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both parameters ('fitting_name' and 'eft_string'). The description adds minimal value by mentioning these two input methods but doesn't provide additional semantics like format details or usage context beyond what the schema states. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: analyzing a fitting by name or EFT string to return tank stats, DPS estimates, and capacitor info. It specifies the verb ('analyze') and resource ('fitting'), but doesn't explicitly differentiate from sibling tools like 'eve_fitting_list' or 'eve_fitting_save', which is why it doesn't reach a score of 5.

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

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

The description implies usage by mentioning two input methods (name or EFT string), but it doesn't provide explicit guidance on when to use this tool versus alternatives like 'eve_fitting_list' or 'eve_killmail_analyze'. No exclusions or prerequisites are stated, leaving some ambiguity for the agent.

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

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 states it's a list operation, implying read-only behavior, but doesn't cover critical aspects like authentication requirements, rate limits, pagination, or response format. For a tool that likely requires character context, this omission is significant, though not contradictory.

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

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

The description is a single, clear sentence with zero wasted words. It's front-loaded with the core action ('List all saved ship fittings'), making it easy to parse. Every part of the sentence contributes directly to understanding the tool's purpose, achieving optimal conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (1 optional parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks context on authentication, output structure, or integration with sibling tools. Without annotations or output schema, more behavioral details would improve completeness, but it's not entirely inadequate for a simple list tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, with the single parameter 'ship_type' documented as 'Filter by ship type name'. The description doesn't add any parameter details beyond this, such as examples or filtering logic. Since the schema fully covers the parameter, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't need to.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('List') and resource ('all saved ship fittings for the character'), making the purpose evident. It distinguishes from sibling tools like 'eve_fitting_save' and 'eve_fitting_analyze' by focusing on listing rather than saving or analyzing fittings. However, it doesn't explicitly differentiate from other list tools (e.g., 'eve_assets_search'), which prevents a perfect score.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., character authentication), compare to similar tools like 'eve_assets_search' for broader asset listings, or specify use cases (e.g., inventory management vs. fitting optimization). This lack of context leaves the agent with minimal usage direction.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool performs a save operation (implying mutation/write), but doesn't disclose critical behaviors: whether authentication is required, potential side effects (e.g., overwriting existing fittings), error handling, or response format. For a mutation tool with zero annotation coverage, this is a significant gap.

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

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

The description is a single, efficient sentence that front-loads the core action ('Save a new fitting') and includes essential context ('to character', 'from EFT format'). There is zero waste or redundancy, making it highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (a mutation operation with no annotations and no output schema), the description is incomplete. It lacks information on authentication requirements, behavioral traits (e.g., idempotency, error cases), and what the tool returns. For a save tool in this context, more detail is needed to be fully helpful.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 three parameters (eft_string, name, description) with clear descriptions. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't explain EFT format details or naming constraints). Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Save a new fitting') and the target ('to character'), with specificity about the input format ('from EFT format'). It distinguishes from sibling tools like 'eve_fitting_list' (list vs. save) and 'eve_fitting_analyze' (analyze vs. save), though it doesn't explicitly name these alternatives. The purpose is unambiguous but could be slightly more differentiated.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication status), compare to sibling tools like 'eve_fitting_list' or 'eve_fitting_analyze', or specify scenarios where saving a fitting is appropriate. Usage is implied by the action but lacks explicit context.

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

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

No annotations are provided, so the description carries full burden. It mentions the conditional behavior ('if character is currently in a fleet'), which is useful, but doesn't disclose other traits like authentication requirements, error handling, rate limits, or what happens if the character isn't in a fleet. For a tool with zero annotation coverage, this is a significant gap.

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

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

The description is a single, clear sentence that efficiently conveys the core purpose and condition without any wasted words. It's front-loaded with the main action and appropriately sized for the tool's simplicity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (0 parameters, no output schema), the description is minimally adequate but incomplete. It lacks details on authentication, return format, error cases, or how it relates to sibling tools. With no annotations or output schema, more context would be helpful for an agent to use it effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter information, which is appropriate here. A baseline of 4 is applied as per rules for 0 parameters, since the schema fully covers the absence of inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 'Get fleet information' with the condition 'if character is currently in a fleet', which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'eve_location_current' or 'eve_character_info', which might provide related but different information.

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

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

The description implies usage context ('if character is currently in a fleet'), suggesting it should only be used when the character is fleet-joined, but it doesn't provide explicit when-not-to-use guidance or name alternatives among siblings. This leaves some ambiguity about edge cases or fallback tools.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions what data is retrieved but lacks details on permissions required, rate limits, response format, or potential errors. For an intelligence tool with no annotation coverage, this leaves significant gaps in understanding how the tool behaves operationally.

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

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

The description is a single, efficient sentence that front-loads the core action ('look up a character') and lists key data points without unnecessary words. Every element earns its place by specifying the tool's scope and differentiating it from simpler character tools.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (intelligence gathering with multiple data points), no annotations, and no output schema, the description is incomplete. It outlines what data is retrieved but doesn't cover behavioral aspects like authentication needs, data freshness, or response structure. For a tool with rich potential outputs, more context is needed to be fully helpful.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, with the single parameter 'character_name' clearly documented. The description doesn't add specific parameter details beyond implying it's for character lookup, but with high schema coverage and only one parameter, the baseline is strong. It compensates slightly by contextualizing the parameter's use in intelligence gathering.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verbs ('look up') and resources ('character'), listing detailed information retrieved (corporation, alliance, security status, recent kills/losses, activity patterns, dangerous history). It effectively distinguishes this from sibling tools like 'eve_character_info' by emphasizing intelligence aspects rather than basic character data.

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

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

The description implies usage context through 'look up a character' and the listed data points, suggesting it's for intelligence gathering. However, it doesn't explicitly state when to use this tool versus alternatives like 'eve_character_info' or 'eve_search', nor does it provide exclusions or prerequisites. The guidance is present but not comprehensive.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a read-only operation ('Look up'), but doesn't specify data sources, rate limits, authentication requirements, or error handling. For a tool with no annotations, this leaves significant gaps in understanding its behavior and constraints.

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

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

The description is a single, efficient sentence that front-loads the core action and lists key data points. Every word contributes to understanding the tool's purpose without redundancy or unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description provides a clear purpose but lacks details on behavioral traits, error cases, and return format. It's adequate for a simple lookup tool but incomplete for full agent understanding, especially without output schema to clarify results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with the parameter 'corporation_name' clearly documented in the schema. The description doesn't add any parameter-specific details beyond what the schema provides (e.g., format examples or validation rules), so it meets the baseline for high schema coverage without extra value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Look up') and resource ('a corporation'), and lists specific data points retrieved (member count, alliance, activity, top killers, common ships and doctrines). It distinguishes this from sibling tools like 'eve_intel_character' or 'eve_intel_system' by focusing on corporations, though it doesn't explicitly contrast them.

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

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. It doesn't mention prerequisites (e.g., authentication needs), nor does it differentiate from similar tools like 'eve_character_info' or 'eve_search' that might overlap in functionality. The description assumes context without explicit usage instructions.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions what data is returned but doesn't cover important aspects like rate limits, authentication requirements, data freshness, error conditions, or whether this is a read-only operation. The description is insufficient for a tool that likely queries external data sources.

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

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

The description is a single, efficient sentence that front-loads the core purpose and lists the specific data types returned. Every word earns its place with zero wasted text or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a data query tool with no annotations and no output schema, the description is incomplete. It doesn't explain the return format, data structure, potential limitations, or how the different data types (kills, jumps, sovereignty) relate to each other. The agent would need to guess about the response format and behavioral characteristics.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both parameters completely. The description doesn't add any parameter semantics beyond what's in the schema - it doesn't explain relationships between parameters or provide usage examples. Baseline 3 is appropriate when schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and resource 'intel for a solar system', specifying the exact data types returned (recent kills, NPC kills, jumps, sovereignty). It distinguishes from sibling tools like 'eve_intel_character' and 'eve_intel_corporation' by focusing on solar systems rather than characters or corporations.

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

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

The description implies usage for solar system intelligence gathering, but provides no explicit guidance on when to use this tool versus alternatives like 'eve_system_info' (which might provide static system data) or other intel tools. No exclusions or prerequisites are mentioned.

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

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

No annotations are provided, so the description carries full burden. It mentions what the tool 'shows' (fitting, attackers, damage breakdown) which gives some behavioral insight, but doesn't disclose critical traits like whether it's read-only (implied but not stated), requires authentication, has rate limits, or what format the analysis output takes. For a tool with no annotations, this leaves important behavioral aspects unclear.

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

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

The description is extremely concise with just one sentence that efficiently communicates the core functionality. Every word earns its place: 'Analyze' (action), 'specific killmail' (resource), 'by URL or ID' (input method), and 'shows fitting of victim, attackers involved, damage breakdown' (output content). No wasted words or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations, no output schema, and 3 parameters with good schema coverage, the description provides basic completeness for a read-oriented analysis tool. It covers what the tool does and what it shows, but lacks details about authentication requirements, error conditions, output format, or integration with other tools. For a tool analyzing game combat data, more context about data sources and limitations would be helpful.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 three parameters (killmail_url, killmail_id, killmail_hash) with their types and descriptions. The description adds minimal value beyond the schema by mentioning 'by URL or ID' (though hash is omitted) and implying these are alternative ways to specify a killmail. This meets the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Analyze a specific killmail by URL or ID' with specific resources (killmail) and actions (analyze, shows fitting of victim, attackers, damage breakdown). It distinguishes from sibling tools like 'eve_fitting_analyze' by focusing on killmail analysis rather than general fitting analysis, but doesn't explicitly contrast with other killmail-related tools (none listed).

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

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

The description provides no guidance on when to use this tool versus alternatives. It mentions analyzing killmails but doesn't specify prerequisites, context (e.g., after obtaining a killmail ID from another source), or when other tools might be more appropriate. With sibling tools covering various EVE Online functions, this lack of differentiation is a significant gap.

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

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 states the tool retrieves location data but doesn't disclose behavioral traits such as whether it requires authentication, rate limits, error conditions, or the format of returned data. The description is minimal and lacks critical operational context for a tool that likely interacts with user-specific data.

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

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

The description is extremely concise and front-loaded: a single sentence with no wasted words. It directly states the tool's purpose and key outputs, making it easy to parse and understand quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (a tool that likely requires character context and returns location data), no annotations, and no output schema, the description is incomplete. It doesn't explain authentication needs, return format, or error handling, leaving significant gaps for an AI agent to use the tool effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds no parameter information beyond what the schema provides, but schema description coverage is 100% (the single parameter 'as_character' is fully described in the schema). With 0 parameters mentioned in the description, the baseline is 4, as the schema adequately documents the parameter without needing duplication.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Get current location' specifies the action and resource, followed by details about what location information is retrieved (solar system, station/structure, current ship type). It distinguishes from siblings by focusing on location retrieval rather than assets, auth, fittings, etc., though it doesn't explicitly contrast with similar tools.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., requiring character authentication), exclusions, or comparisons to other location-related tools (none are listed in siblings, but context about other methods isn't given). Usage is implied only by the tool's name and description.

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

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 that the tool returns total buy and sell values, which is useful behavioral context. However, it lacks details on potential limitations (e.g., rate limits, data freshness, error handling) or authentication needs, leaving gaps for a tool that processes market data.

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

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

The description is two sentences, front-loaded with the core purpose and followed by output details. Every word earns its place, with no redundancy or fluff, making it highly efficient and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (batch appraisal with market data), no annotations, and no output schema, the description is reasonably complete. It covers the purpose, input source, and output values, but could improve by addressing behavioral aspects like data accuracy or prerequisites. It provides enough context for basic use but leaves some operational details unspecified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, so the schema already documents the 'items' parameter format. The description adds value by explaining the input source ('paste from in-game asset list or cargo scan') and implying batch processing, but does not provide additional syntax or format details beyond the schema. With 0 parameters beyond the single documented one, a baseline of 4 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Appraise') and resource ('a list of items'), distinguishing it from sibling tools like 'eve_market_price' or 'eve_market_orders' by focusing on batch valuation from in-game data. It specifies the input source ('paste from in-game asset list or cargo scan') and output ('total buy and sell value'), making the purpose explicit and distinct.

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

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 this tool: for appraising items from in-game sources like asset lists or cargo scans. It does not explicitly state when not to use it or name alternatives (e.g., 'eve_market_price' for single items), but the implied usage is straightforward given the sibling tools.

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

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

With no annotations provided, the description carries full burden but only states what the tool does without disclosing behavioral traits like authentication requirements, rate limits, response format, or pagination. It mentions 'your' implying personal data but doesn't clarify access controls or data scope.

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

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

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and appropriately sized for a simple tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description is incomplete. It doesn't explain what 'active market orders' entails, the return format, or any behavioral context like errors or limitations. For a data retrieval tool in a complex system like EVE Online, more detail is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, so the baseline is 3. The description adds no parameter information, but with only one optional parameter and high schema coverage, this is acceptable. The tool's purpose inherently implies the parameter's role in character selection.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and resource 'your active market orders', making the purpose specific and understandable. It distinguishes from siblings like 'eve_market_price' or 'eve_market_appraise' by focusing on orders rather than pricing or appraisal, though it doesn't explicitly contrast them.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'eve_market_price' or 'eve_market_appraise', nor does it mention prerequisites such as authentication or character selection. It lacks explicit usage context or exclusions.

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

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 mentions default behavior (Jita region) and flexibility (other regions), but lacks details on rate limits, authentication needs, error handling, or what 'current' means (e.g., real-time vs. cached). This is a significant gap for a tool with no annotation coverage.

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

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

The description is appropriately sized and front-loaded, with two concise sentences that efficiently convey the tool's purpose and key usage details without any wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose and default behavior but lacks details on authentication, rate limits, return format (e.g., buy/sell prices as numbers or objects), or error cases, which are important for a market price tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both parameters. The description adds marginal value by clarifying the default region ('Jita') and that other regions can be specified, but does not provide additional syntax, format details, or examples beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verbs ('Get current market price') and resource ('for an item'), and distinguishes it from sibling tools like 'eve_market_orders' by focusing on price retrieval rather than order listing.

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

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

The description provides clear context for usage ('Shows Jita buy/sell by default, can specify other regions'), but does not explicitly state when to use alternatives like 'eve_market_appraise' or 'eve_market_orders', nor does it mention exclusions or prerequisites.

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

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 that it lists colonies and shows specific fields, which is useful. However, it does not mention behavioral traits like whether it requires specific permissions, rate limits, pagination, or error handling. The description adds basic context but lacks depth on operational behavior.

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

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

The description is a single, dense sentence that efficiently conveys purpose, scope, and output fields without waste. It is front-loaded with the main action ('List all PI colonies') and follows with specific details, making it highly concise and well-structured for quick understanding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (1 optional parameter, no output schema, no annotations), the description is reasonably complete. It covers what the tool does and the data returned. However, it lacks details on authentication requirements, error cases, or output format specifics, which would be helpful for an agent. With no output schema, some additional context on return structure could improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 1 parameter with 100% description coverage, so the schema already documents it well. The description does not add parameter-specific information, but with only one optional parameter and high schema coverage, the baseline is strong. The description compensates by clarifying the overall output semantics (e.g., fields like 'upgrade level'), though not directly about the parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('List') and resource ('all Planetary Industry (PI) colonies for the authenticated character'), distinguishing it from siblings like 'eve_pi_colony_detail' (which likely shows details for a specific colony) and 'eve_pi_plan' (which might involve planning). It specifies the exact data fields returned (planet name, type, system, upgrade level, pin count, last update), making the purpose highly specific.

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

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

The description implies usage by stating it lists colonies 'for the authenticated character,' suggesting it requires character authentication. However, it does not explicitly state when to use this tool versus alternatives like 'eve_pi_colony_detail' or provide exclusions (e.g., if no colonies exist). The context is clear but lacks explicit guidance on alternatives or edge cases.

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

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 describes what data is retrieved (layout details) but does not disclose behavioral traits such as authentication requirements, rate limits, error conditions, or whether it's a read-only operation. The description is informative but lacks critical operational context.

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

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

The description is a single, well-structured sentence that efficiently lists all key components (pins, extractors, factories, storage, links, routes) without unnecessary words. It is front-loaded with the main purpose and provides specific details concisely.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description provides good detail on what data is retrieved but lacks information on behavioral aspects (e.g., auth, errors) and return format. It is complete for a read operation in terms of content scope but incomplete for operational context, making it adequate but with gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both parameters ('planet_id' and 'as_character'). The description does not add meaning beyond the schema, as it does not explain parameter usage, constraints, or examples. Baseline score of 3 is appropriate since the schema provides adequate parameter information.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('Get') and resource ('detailed colony layout for a specific planet'), and it distinguishes from sibling tools by specifying the detailed content (pins, extractors, factories, storage, links, routes) that differentiates it from broader tools like 'eve_pi_colonies' or 'eve_pi_plan'.

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

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

The description implies usage by specifying 'for a specific planet' and listing detailed components, but it does not explicitly state when to use this tool versus alternatives like 'eve_pi_colonies' (which likely lists colonies) or 'eve_pi_plan' (which might involve planning). No explicit exclusions or prerequisites are provided.

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

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 mentions what the tool shows (full chain, planet types, estimates) but doesn't disclose behavioral traits such as whether it's read-only, if it requires authentication, rate limits, or how it handles errors. The description adds some context but leaves critical operational details unspecified.

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

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

The description is a single, well-structured sentence that efficiently conveys the tool's purpose and output scope. It's front-loaded with the main action and avoids unnecessary details, making it easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of planning a production chain, no annotations, and no output schema, the description is somewhat complete but lacks depth. It covers what the tool does but omits details on authentication needs, error handling, or output format, which are important for a tool with potential dependencies on character data and game mechanics.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 (product_name, num_planets, as_character). The description doesn't add meaning beyond the schema, such as explaining interactions between parameters or default behaviors. Baseline 3 is appropriate as the schema handles parameter documentation adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Plan a PI production chain') and resource ('for a target product'), distinguishing it from sibling tools like eve_pi_colonies or eve_pi_products. It specifies the output scope: 'full chain from P0 raw materials to the target tier, which planet types are needed, and factory/extractor estimates.'

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

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

No explicit guidance on when to use this tool versus alternatives like eve_pi_products (which might list products) or eve_pi_colonies (which might show existing colonies). The description implies usage for planning production chains but lacks context on prerequisites or exclusions.

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

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

No annotations are provided, so the description carries full burden. It mentions 'Shows inputs, outputs, and cycle times' which adds some behavioral context about what information is returned. However, it doesn't disclose important traits like whether this is a read-only operation, if it requires authentication, rate limits, or what format the output takes. For a tool with no annotations, this is insufficient behavioral disclosure.

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

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

The description is extremely concise and well-structured in a single sentence. It front-loads the core functionality ('Browse PI products') and efficiently covers both filtering methods and what information is shown. Every word earns its place with zero waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description provides basic context about what the tool does and what information it returns. However, for a tool that presumably returns complex PI product data with inputs, outputs, and cycle times, the description doesn't adequately explain the return format or structure. The completeness is minimal but adequate for a simple browse/search tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds marginal value by mentioning 'tier (P0-P4)' and 'search by name' which aligns with the schema's descriptions. However, it doesn't provide additional semantic context beyond what's already in the structured schema fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Browse PI products by tier (P0-P4) or search by name.' It specifies the verb ('browse') and resource ('PI products') with two filtering methods. However, it doesn't explicitly differentiate from sibling tools like 'eve_pi_colonies' or 'eve_pi_plan', which reduces it from a perfect score.

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

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

The description provides no guidance on when to use this tool versus alternatives. It mentions browsing by tier or search, but doesn't compare to sibling tools like 'eve_search' or 'eve_type_info' that might overlap in functionality. There's no explicit when/when-not usage context provided.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'authenticated character,' implying some authentication requirement, but doesn't specify what authentication entails (e.g., tokens, permissions) or other behavioral traits like rate limits, error handling, or response format. For a tool with no annotation coverage, this is a significant gap 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.

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

The description is concise and front-loaded, starting with the core purpose in the first clause. The list of skills is specific and relevant, adding necessary detail without redundancy. However, the lack of usage guidelines or behavioral details means it could be more informative while remaining efficient, slightly reducing its structural completeness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (checking specific skills with authentication) and the absence of annotations and output schema, the description is partially complete. It specifies the skills checked and hints at authentication, but lacks details on output format, error cases, or integration with sibling tools. This makes it adequate for basic understanding but insufficient for robust agent operation without additional context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with the single parameter 'as_character' well-documented in the schema as 'Linked character (name or ID) — defaults to active.' The description adds no additional parameter information beyond this, such as examples or constraints. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema adequately handles parameter semantics without extra description input.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Check Planetary Industry relevant skills for the authenticated character' followed by a specific list of skills. This includes a verb ('Check') and resource ('Planetary Industry relevant skills'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'eve_character_skills' which might provide broader skill information, leaving room for improvement in sibling distinction.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'eve_character_skills' (which might list all skills) or 'eve_pi_colonies' (which might relate to PI operations), nor does it specify prerequisites or contexts for usage. This lack of comparative or contextual advice limits the agent's ability to choose appropriately among available tools.

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

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 mentions the route preferences but doesn't disclose critical behavioral traits like whether this is a read-only operation, if it requires authentication, potential rate limits, error conditions (e.g., invalid system names), or what the output looks like (e.g., list of systems, distance). For a tool with no annotations, this leaves significant gaps in understanding how it behaves.

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

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

The description is a single, efficient sentence that front-loads the core purpose and immediately explains the key feature (route preferences). Every word earns its place with no redundancy or unnecessary details, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of route calculation with security considerations, no annotations, and no output schema, the description is incomplete. It lacks information on authentication requirements, error handling, output format (e.g., step-by-step route, total jumps), and behavioral constraints. For a tool that likely interacts with game data and has safety implications, this leaves too much unspecified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 (origin, destination, preference) with descriptions and enum values. The description adds minimal value by hinting at the meaning of preference options ('secure (highsec), and insecure (lowsec/null)'), but doesn't provide additional syntax or format details beyond what the schema offers. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Calculate route') and resource ('between two systems'), and distinguishes itself from sibling tools by focusing on route planning rather than authentication, market, character info, or other EVE Online operations. It's precise and unambiguous.

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

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 this tool by specifying the three route preferences (shortest, secure, insecure), which helps the agent choose based on safety vs. speed trade-offs. However, it doesn't explicitly mention when not to use it or name alternatives among siblings, though the distinct purpose makes alternatives less relevant.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. While it states the search functionality, it lacks critical behavioral details such as whether this requires authentication, rate limits, pagination behavior, error handling, or what the output format looks like (especially important since there's no output schema). This leaves significant gaps for an agent to understand how to properly invoke and interpret results.

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

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

The description is a single, efficient sentence that front-loads the core functionality ('Search for any EVE entity by name') followed by a comma-separated list of entity types. Every word earns its place with zero waste or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations and output schema, the description is incomplete for a search tool with 2 parameters. It doesn't explain what the search returns (e.g., list of matches with IDs/names), how results are ordered, whether it supports partial matching, or any authentication requirements. For a tool that likely returns structured data, this leaves the agent with insufficient context to use it effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already fully documents both parameters ('query' and 'categories'). The description mentions 'by name' which slightly clarifies the 'query' parameter's purpose, but doesn't add meaningful semantic value beyond what the schema provides. The baseline score of 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Search for any EVE entity by name' with specific entity types listed (characters, corporations, alliances, systems, types, stations). This provides a specific verb ('search') and resource ('EVE entity'), though it doesn't explicitly differentiate from sibling tools like 'eve_wiki_search' which also searches but for different content.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'eve_wiki_search' (for wiki content) or 'eve_assets_search' (for asset searches), nor does it specify any prerequisites, exclusions, or contextual triggers for choosing this search tool over others.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool interacts with a running EVE client via a linked character, implying real-time game action, but lacks details on permissions, side effects (e.g., in-game consequences), rate limits, or error handling. For a mutation tool with zero annotation coverage, this is insufficient.

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

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

The description is a single, efficient sentence that front-loads the core purpose without unnecessary details. Every word earns its place, making it appropriately sized and well-structured for quick comprehension.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks critical context such as what the tool returns (e.g., success/failure), error conditions, or behavioral nuances (e.g., whether it requires specific in-game states). For a 4-parameter tool affecting game state, more completeness is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents all 4 parameters. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain system_name format or interactions between clear_other and add_to_beginning). Baseline 3 is appropriate as the schema handles parameter documentation adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Set autopilot destination') and the target ('in-game'), specifying it uses the linked character's running EVE client. It distinguishes from siblings like eve_route_plan (planning vs. setting) and eve_location_current (checking vs. setting), though not explicitly. However, it lacks explicit sibling differentiation, keeping it at 4 instead of 5.

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

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

The description provides no guidance on when to use this tool versus alternatives like eve_route_plan for route planning or other navigation tools. It mentions the linked character context but offers no explicit when/when-not rules or prerequisites, resulting in minimal usage guidance.

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

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

No annotations are provided, so the description carries full burden. It states the tool retrieves information, implying a read-only operation, but doesn't disclose behavioral traits like authentication requirements, rate limits, error handling, or response format. For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves.

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

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

The description is a single, efficient sentence that front-loads the purpose and lists key attributes without waste. Every word earns its place, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations, no output schema, and a simple input schema, the description is minimally adequate. It covers the purpose but lacks behavioral context and usage guidelines. For a read-only tool with one parameter, it's functional but could be more informative about authentication or response structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with the parameter 'system_name' fully documented in the schema. The description adds no additional parameter semantics beyond implying the input is a solar system name. Baseline 3 is appropriate as the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and the resource 'solar system information', with specific attributes listed (security status, constellation, region, stations, stargates, planets). It distinguishes this tool from siblings like eve_intel_system or eve_route_plan by focusing on static system data rather than intelligence or routing.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication needs), compare with similar tools like eve_intel_system, or specify use cases. The agent must infer usage from the purpose alone.

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

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 mentions what information is returned (stats, description, Dogma attributes) but lacks details on behavioral aspects such as rate limits, authentication requirements, error handling, or data freshness. The description is accurate but incomplete for behavioral transparency.

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

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

The description is a single, well-structured sentence that efficiently conveys the tool's purpose, scope, and output. Every word earns its place, with no redundant or vague phrasing, making it easy to understand at a glance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (1 parameter, no nested objects) and lack of output schema, the description adequately covers the basics but could benefit from more context on return values or usage nuances. It meets minimum viability but has clear gaps in behavioral and output details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with the parameter 'type_name' clearly documented in the schema. The description does not add any additional semantic context beyond what the schema provides, such as format examples or validation rules. With high schema coverage, the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Get detailed info') and resource ('any EVE item type'), with specific examples (ship, module, ammo) and output details (stats, description, Dogma attributes). It effectively distinguishes itself from sibling tools like eve_search or eve_wiki_article by focusing on item metadata rather than searching or wiki content.

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

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

The description implies usage for retrieving detailed information about EVE item types, but does not explicitly state when to use this tool versus alternatives like eve_search or eve_wiki_article. No exclusions or prerequisites are mentioned, leaving the context somewhat open-ended.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states it's a read operation ('Get'), but doesn't mention authentication requirements, rate limits, error conditions, or what 'current' means (e.g., cached vs real-time data). For a financial tool with zero annotation coverage, this leaves significant behavioral gaps.

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

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

The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose and appropriately sized for a simple retrieval tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read tool with one well-documented parameter but no annotations or output schema, the description is minimally adequate. It states what the tool does but lacks important context about authentication, data freshness, and relationship to sibling wallet tools, making it incomplete for optimal agent usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 100% description coverage for its single parameter, so the description doesn't need to add parameter details. The description doesn't mention parameters at all, which is acceptable given the high schema coverage, resulting in a baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get current wallet balance' clearly states the verb ('Get') and resource ('wallet balance'), making the purpose immediately understandable. It doesn't specifically differentiate from sibling tools like 'eve_wallet_journal', but it's unambiguous about what it does.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'eve_wallet_journal' or other wallet-related tools. It doesn't mention prerequisites (like authentication status) or contextual constraints, leaving the agent to infer usage from the tool name alone.

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

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

No annotations are provided, so the description carries full burden. It states this is a read operation ('Get') but doesn't disclose important behavioral traits: whether authentication is required, rate limits, pagination behavior (beyond the default 20 entries), what happens when no character is specified, or the format/structure of returned data. The description is minimal and lacks operational context.

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

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

The description is a single, efficient sentence that gets straight to the point. Every word earns its place: 'Get' (action), 'recent wallet transactions' (resource), 'last 30 days' (scope). No wasted words or unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read operation with no annotations and no output schema, the description is insufficient. It doesn't explain authentication requirements, response format, error conditions, or how the 30-day constraint interacts with the 'entries' parameter. The agent would need to guess about important operational aspects.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents both parameters. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain what 'entries' means in context, clarify 'as_character' behavior, or provide usage examples. Baseline 3 is appropriate when schema does all the work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Get') and resource ('recent wallet transactions') with a specific time constraint ('last 30 days'). It distinguishes from sibling tools like 'eve_wallet_balance' by focusing on transaction history rather than current balance. However, it doesn't explicitly differentiate from other transaction-related tools that might exist in broader context.

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

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

The description provides no guidance on when to use this tool versus alternatives. While it mentions 'recent wallet transactions,' it doesn't specify whether this is for personal character wallets, corporation wallets, or other contexts. No exclusions, prerequisites, or alternative tools are mentioned.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool 'Get[s] full content' but doesn't mention potential limitations like rate limits, authentication requirements, error handling, or output format details. This leaves significant gaps for a tool that likely interacts with an external API.

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

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

The description is a single, clear sentence with zero wasted words. It's front-loaded with the core purpose and efficiently specifies the resource scope. Every element earns its place without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only tool with 2 parameters and 100% schema coverage but no output schema or annotations, the description is minimally adequate. It covers the basic purpose but lacks details on behavioral aspects like authentication, rate limits, or return format, which are important for API tools. The absence of an output schema increases the need for more context in the description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents both parameters ('title' and 'section'). The description adds no additional parameter semantics beyond implying retrieval of article content, which aligns with the schema but doesn't provide extra value. Baseline 3 is appropriate when schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and resource 'full content of a specific EVE University Wiki article', making the purpose unambiguous. However, it doesn't explicitly differentiate from its sibling 'eve_wiki_search', which searches rather than retrieves specific articles, though this distinction is implied by the different action verbs.

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

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

The description implies usage by specifying 'specific article', suggesting it's for retrieving known articles rather than searching. No explicit guidance on when to use alternatives like 'eve_wiki_search' is provided, leaving the distinction to inference from the tool names and descriptions.

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

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 mentions the search functionality but lacks behavioral details such as how results are ranked, whether it's a read-only operation, any rate limits, authentication requirements, or what the output format looks like. This is inadequate for a tool with no annotation coverage.

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

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

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every word contributing to understanding the tool's function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations, no output schema, and a search tool that likely returns complex results, the description is incomplete. It doesn't explain what the output contains (e.g., article titles, summaries, links) or any behavioral constraints, making it insufficient for an agent to use the tool effectively without additional context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both parameters ('query' and 'max_results') with descriptions. The description adds no additional parameter semantics beyond what's in the schema, such as query syntax or result limits beyond the default. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Search EVE University Wiki for articles about game mechanics, ships, modules, strategies, guides'. It specifies the verb ('Search'), resource ('EVE University Wiki'), and content scope. However, it doesn't explicitly differentiate from the sibling tool 'eve_wiki_article', which might retrieve specific articles rather than search.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention the sibling tool 'eve_wiki_article' or other search-related tools like 'eve_search', leaving the agent without context for choosing between them.

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