Stardew Save MCP

by vehemont

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.2.12
Disambiguation5/5
Each tool has a clearly distinct purpose, covering specific aspects of the game like crops, animals, fishing, community center, etc. Even closely related tools like animal_product_quality and animal_product_value measure different metrics.
Naming Consistency4/5
Most tool names follow a descriptive noun_verb or verb_noun pattern (e.g., crop_planner, find_item), but some are single words (e.g., buildings, friends) without a verb, creating minor inconsistency.
Tool Count2/5
With 49 tools, the server is overly large for a typical MCP. While each tool serves a specific purpose, the set could be consolidated (e.g., combining related queries). This number exceeds the recommended range and may overwhelm agents.
Completeness5/5
The tool set covers nearly every facet of Stardew Valley—crops, animals, fishing, mining, community center, friendships, museum, perfection, and more. It includes planning, analysis, and lookup tools, leaving few gaps for the intended domain.
Average 3.5/5 across 49 of 49 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 37 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It mentions relying on held crops and machines owned but does not disclose limitations, dependencies (e.g., save configuration), or the content of the referenced 'note' with multipliers/cycle-day caveats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but its structure is somewhat cryptic with backtick formatting and missing explanation of the note. It is concise but at the cost of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values are covered, but the description omits prerequisites (e.g., save configuration) and does not explain the note's caveats, leaving the tool's overall context incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds no additional meaning to parameters like artisan, extra_jars, extra_kegs, or save_path. Only 'days' is mentioned, which is already in the schema. Description fails to augment the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates kegs/jars needed and estimated gross gold from held crops and machines owned, distinct from siblings like processing or processing_value by focusing on planning to clear a backlog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus siblings like processing or processing_value. The reference to a 'note' for caveats is mentioned but not provided, leaving usage context incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the comparison but does not disclose behavioral traits such as being read-only, required permissions, or any side effects. For a calculation tool, this is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that conveys the core purpose. It is front-loaded and has no wasted words. However, it could be slightly improved by adding a brief usage hint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters and an output schema, the description is too abstract. It does not explain how parameters relate to each other or what the output represents. Despite the output schema, the description lacks completeness for a comparison tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. However, the description does not add any parameter-specific details beyond what the schema already provides. For example, it does not explain the meaning of 'auto' for artisan/rancher, leaving the agent to rely solely on schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compares raw value (with Rancher and quality) vs processed value (with Artisan). It uses specific verbs and bonuses, making the purpose understandable. However, it does not distinguish itself from related siblings like 'animal_product_quality' or 'processing_value'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like 'processing_value' or 'crop_planner'. The description lacks context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions 'presence-only' but does not explain what that means (e.g., does it ignore quality? quantity?). No information about whether it is read-only or requires specific game state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence, 7 words), which is concise but at the expense of completeness. It front-loads the core concept but omits necessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description must clarify the return value, but it does not. The phrase 'finishable from items currently held' is ambiguous—does it return a list of finished bundles, a boolean, or a count? The term 'presence-only' is unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains the 'save_path' parameter adequately. The description adds no additional meaning to the parameter, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific resource ('incomplete CC bundles') and a specific check ('finishable from items currently held'), making the purpose reasonably clear despite the cryptic 'CC' abbreviation. It implicitly distinguishes from sibling tools like 'bundle_sourcing' by focusing on completion rather than sourcing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., 'bundle_sourcing'), nor does it mention any prerequisites or limitations. The agent must infer context from similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not explicitly state that the tool is read-only or non-destructive. The name 'feed' could imply action, but the description mitigates this somewhat by describing status.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (11 words), which is concise but lacks a verb and feels incomplete. It is not structured with sections or examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no description of the return format, an agent may not know what to expect. The description lists components but not their structure or types.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema description for save_path is detailed. The tool description adds no parameter-specific information, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly lists the items the tool provides (animals, silo hay, fiber, days of feed covered), but lacks an explicit verb like 'get' or 'retrieve'. It distinguishes itself from sibling tools by focusing on feed status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, and no conditions or prerequisites are mentioned. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must disclose behavior. It only states the core function but omits whether it modifies data, requires authentication, or has side effects. The save_path parameter implies reading saves, but this is not explicitly stated in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence, 9 words) and front-loaded. However, it is too sparse given the tool has 5 parameters, sacrificing necessary context for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema, the description does not mention the return value or behavior (e.g., integer days). Missing context about hypothetical vs real ponds, save requirements, and relation to other fish tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The tool description adds no additional meaning beyond the schema, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates days to fill a fish pond via reproduction, using specific verb and resource. However, it could be more explicit about 'forecast' and does not strongly differentiate from other forecast tools, though the resource is unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., fish_available) or when not to use it. No prerequisites or context are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must cover behavioral traits. It does not disclose whether the operation is read-only, potential performance implications, or error handling for invalid save paths. The description only lists contents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, but it is merely a list without structure or explanatory text. It could be better organized to improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (many sub-reports) and lack of output schema, the description should explain the format or nature of the returned report. It only lists sections, leaving the agent uncertain about what the output looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The save_path parameter has a comprehensive description in the schema (100% coverage), so the description adds no new parameter meaning. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description lists the components of the report (overview, players, etc.), making it clear what the tool provides. However, it does not explicitly state that it returns a single comprehensive report, and it lacks differentiation from sibling tools that cover individual components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus individual report tools like 'overview' or 'players'. There is no mention of alternatives or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It does not mention any side effects, restrictions, or behavior beyond the basic output. For example, it doesn't state that it reads from a save file or requires specific parameters to function correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, very concise. It gets to the point but lacks structure. Could be improved with a brief explanation of output or use case, but it is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and an output schema, the description is too minimal. It does not explain the output format, scale of percentages, or how factors like farming level or fertilizer affect results. The output schema likely provides structure, but the description should still contextualize the output for easy interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond what is in the schema. It does not explain parameter interactions or provide examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns gold/silver/normal (and iridium with Deluxe) crop-quality percentages. It specifies the resource (crop-quality percentages) and implies a calculation. However, it does not differentiate from siblings like animal_product_quality or animal_product_value, which are distinct but similar in style.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., other quality tools or general calculators). There is no mention of prerequisites, context, or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must convey behavioral traits. It hints at reading save data ('from current save points') but does not state it is read-only, nor does it disclose any side effects, authorization needs, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at one sentence. It is front-loaded with key information (loved gifts, weeks, target hearts). However, brevity sacrifices some clarity and completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and an output schema, the description lacks sufficient context. It does not explain what the tool returns (e.g., number of weeks, breakdown by week), how current friendship points are used, or edge cases like unreachable targets.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with adequate field descriptions. The tool description adds minimal extra meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates the tool calculates weeks to reach a target heart level using loved gifts from save data. It distinguishes itself from sibling tools like 'friendships' (current state) and 'gift_helper' (gift suggestions) by focusing on forecasting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. Does not mention prerequisites, such as requiring an active save, or when not to use it (e.g., if friendship is already at max).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully convey behavioral traits. It only states that the tool detects mods and lists unmapped entries. It does not indicate whether this is a read-only operation, whether it modifies the save file, or any prerequisites (e.g., need for load order). The description is insufficient for an agent to understand side effects or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 20 words, which is concise. The main action 'Detect mods' is front-loaded. However, the latter part could be restructured for better readability, perhaps by separating the purpose from the details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and no output schema, the description covers the core function but lacks specifics: format of the list, what constitutes 'vanilla references', or how mods are detected. The absence of output schema makes the description's role more critical, and it falls short of fully informing an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides a detailed description of the 'save_path' parameter (100% coverage). The tool description adds no additional meaning beyond what the schema already conveys. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Detect mods' and specifies the output: listing what couldn't be mapped to vanilla references. This purpose is distinct from sibling tools, which focus on specific game mechanics. However, the phrase 'modded item ids, unmapped bundle/museum entries' could be clearer, and the description does not explicitly differentiate from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Given the many sibling tools, the agent may struggle to decide when to invoke this tool instead of, e.g., 'find_item' or 'wiki_search'. The description offers no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions outputs (donations count and next milestone) but does not specify the return format, whether it reads or modifies data, or what happens if the input is invalid. The behavioral scope is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the core information concisely, with an example added for clarity. It is front-loaded with the key action and resource. The lack of structure is acceptable given brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description is incomplete. It fails to clarify the return value's structure (e.g., text, number, or object) and the exact meaning of 'next milestone'. Domain experts might infer, but general agents need more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for 'save_path' is already detailed with 100% coverage, so the tool description adds no parameter semantics. The description does not provide additional meaning beyond the schema, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool reports museum donations out of 95 and provides the next milestone with an example (60 = Rusty Key). It is specific about the resource (museum donations) and action (reporting count and next milestone). However, it does not explicitly differentiate from sibling tools like 'missing_museum', though the purpose is distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The usage context is implied (checking museum progress), but there are no explicit conditions, prerequisites, or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only hints at output (materials and affordability check) without details on side effects, limitations, or return format. The output schema exists but the description does not complement it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence covering core functionality. No unnecessary words. Could be slightly more structured, but effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose but omits details like output interpretation or edge cases. Given the output schema exists, it is partially complete but leaves the agent to infer return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description ties parameters together but adds minimal new semantic meaning beyond what is already in the schema (e.g., tiles, sprinkler type).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: providing sprinkler and material requirements to water a given number of tiles, and checking affordability. However, it does not explicitly distinguish from sibling planning tools like crop_planner or processing_planner.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus other planning tools. The description lacks context about prerequisites, alternatives, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description focuses on output content but does not disclose read-only nature, performance implications, or any side effects. It carries the full burden but fails to mention that it does not modify the save.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single run-on sentence with dense listing; lacks front-loading and structure. Could be broken into bullet points or paragraphs for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lists all included digest items, which partially compensates for no output schema. However, missing format details, example output, or any constraints on data volume.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter with 100% schema coverage; schema already fully describes save_path. Description adds no additional meaning or constraints beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly defines the tool as a one-call morning digest listing specific save state details (date, luck, birthdays, gifts, hearts, quests, orders, festivals, goals, chores). Verb 'digest' is specific and resource is the save, distinguishing it from other tools like full_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like full_report or other summary tools. Description implies morning use but does not clarify contexts or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It provides the XP formula and mentions multiplicative stacking, but does not explain how save XP is retrieved, how the save_path parameter is used, or what happens if no save is configured. The note reference is unresolved, leaving behavior partially unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with a formula, front-loading the purpose. However, the unresolved note reference ('see `note`') adds an element of confusion and assumes external knowledge, slightly detracting from conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 parameters and an output schema, the description does not explain what the tool returns (e.g., number of catches, detailed breakdown). The formula and stacking info are useful but omit key behavioral details like save file requirements or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the XP formula and how multipliers (perfect, treasure, legendary) stack, which clarifies the meaning of those boolean parameters beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates 'Catches needed to reach a target fishing level' and provides the XP formula, which is specific and distinguishes it from siblings like 'skill_xp_forecast' or 'fish_available'. However, the reference to a missing note reduces clarity slightly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus sibling tools like 'skill_xp_forecast' or 'fish_available'. The description does not mention any conditions or exclusions, leaving the agent without context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must convey behavioral traits. It lists what fields are returned but does not state that the operation is read-only, has no side effects, or requires specific permissions. The parameter description hints at save configuration but is not part of the main description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that lists the fields. It is concise with no redundant information, and the key purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and no output schema, the description covers the returned fields adequately. However, it lacks behavioral context (e.g., read-only nature, dependency on save configuration) and does not clarify what constitutes a 'headline' selection versus other reports.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameter is already described in the input schema. The description adds no semantic value about how 'save_path' affects the output or how to use it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it provides 'headline state' of the farm, listing specific fields. This clearly indicates the tool returns a summary overview, but does not explicitly differentiate it from siblings like 'full_report' or 'daily_briefing' that might also provide summary data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or when not to use it. Given many sibling tools with similar scope, this 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description states 'Every player' indicating it returns all players, but it does not disclose read-only nature, side effects, or requirements. The burden falls entirely on the description, which 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: a single sentence listing fields with no redundancy. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists the output fields, which is helpful, but lacks explicit statement of the tool's action (e.g., 'Get player information'). With no output schema, the description should be more explicit about the return structure. Overall, minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (save_path has a detailed description). The tool description adds no parameter information, but the schema already covers it adequately, earning a baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description lists the fields returned for every player, which clearly implies a retrieval operation. However, it lacks an explicit verb like 'get' or 'list', reducing specificity. It does not differentiate from siblings such as 'friendships' or 'inventory'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description merely enumerates output fields without context about prerequisites or comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose behavioral traits such as read-only nature, required permissions, or side effects. The agent must assume the tool is safe to use, but this is not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that covers the core purpose. It is appropriately sized for a simple tool, though slightly more detail about output could be added without breaking conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should ideally explain return values. While it mentions hearts/points and spouse status, it lacks detail on the format or scope, making it minimally acceptable but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents the save_path parameter. The description adds no additional meaning beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Per-player villager hearts/points and spouse status' clearly identifies the tool's function (displaying friendship data) and distinguishes it from sibling tools like 'villager_schedule' or 'gift_helper' which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions, leaving the agent to infer usage without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It addresses the output behavior (11 categories, have/total, earned %, verified weights) but does not disclose whether the tool is read-only, requires authentication, or has side effects. For a stat retrieval tool, this is minimally adequate but not complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and output details. It is concise with no wasted words, though it could benefit from a more structured listing of the categories.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description adequately summarizes the output (11 categories, have/total, earned %, verified weights) but omits details on how 'verified weights' are determined or how the overall perfection percentage is calculated. It provides enough to understand the tool's purpose but not full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single parameter (save_path) with a detailed description, achieving 100% coverage. The description adds no additional semantic value for the parameter, only describing the output. With full schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool provides a 'Full weighted Perfection %' with breakdowns of 11 categories including have/total and earned percentages. It identifies the resource (perfection stats) and the output structure, though it lacks an explicit action verb like 'returns' or 'calculates', making it slightly less directive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings like 'full_report' or 'overview'. There is no mention of prerequisites, when not to use it, or alternatives. The description solely focuses on what the tool returns, not on usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It does not mention if the tool is read-only, modifies state, or requires specific permissions. While the description implies a read operation by showing data, it does not explicitly disclose non-destructive behavior or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys the core functionality without any wasted words. It fully explains the output in a front-loaded manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single optional parameter and no output schema, the description adequately explains what the tool returns (items with quantities and a distinct count). It covers the key behavioral aspects for an experienced user, though a novice might need more context on 'basicShipped' or the '154-item target'. Still, it is sufficiently complete for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a detailed description of 'save_path'. The tool description does not mention the parameter or add any context beyond the schema. According to the calibration, high coverage (>80%) gives a baseline of 3, and since the description adds no extra value for parameters, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows shipped items with quantities and a comparison to a perfection target. It uses the verb 'has shipped' which implies a retrieval/display function, and distinguishes the output from sibling tools like 'inventory' or 'perfection' by focusing on shipped items and the specific 154-item target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'inventory' or 'perfection'. The description does not mention prerequisites, when not to use it, or how it differs from siblings. The context signals list many similar tools but no differentiation is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It describes what information is returned but does not mention whether it is a read-only operation, side effects, authorization needs, or performance implications. Minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that clearly and efficiently states the tool's purpose with no extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 100% schema coverage for the single parameter, the description lacks details about the output structure, potential scope (all chests vs. specific), or behavior. It is adequate but could be more complete for a tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'save_path' is fully described in the input schema (100% coverage), so the description does not add extra meaning. Baseline 3 is appropriate as the schema already documents the parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool returns information about containers (chests) including type, location, color, item count, and full contents. It uses specific verbs and clearly identifies the resource, distinguishing it from sibling tools like 'inventory'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. It does not mention conditions, prerequisites, or when not to use it. The description only states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only describes output content but does not disclose whether the tool is read-only, requires authentication, or has side effects. For a query tool, this is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that conveys the key information without unnecessary words. However, it could be structured more clearly with bullet points or separated clauses for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter with full schema coverage and no output schema, the description adequately explains what the tool returns. It covers the main aspects (rooms, bundles, vault) and is complete enough for an informational tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides a detailed description for the single parameter 'save_path', covering 100% of schema properties. The tool description adds no additional parameter information beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides community center progress including rooms done/left, incomplete bundles with exact items, and vault payment status. It uses specific nouns but does not explicitly differentiate from sibling tools like 'bundle_sourcing' or 'can_complete_now'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking community center status, but no explicit guidance on when to use this tool versus alternatives like 'bundle_sourcing' or 'full_report'. No when-not-to-use 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose whether the tool is read-only, requires a specific save state, or has side effects. This is insufficient for a simple retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no unnecessary words. Every word is functional.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return content (kills vs target, reward per category). However, it does not indicate the format (list, table) or whether multiple categories are shown. Adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers the single parameter 'save_path' with a detailed description. The tool description adds no parameter-specific meaning, achieving the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the resource (Adventurer's Guild eradication goals) and the specific data shown (kills vs target, reward per category). It distinguishes itself from sibling tools, which cover different game aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'quests' or 'daily_briefing'. The agent has no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not mention any behavioral aspects such as read-only nature, side effects, or required permissions. The description lacks transparency about what the tool does beyond 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that effectively communicates the tool's purpose. It is front-loaded with the key information, though it lacks structural elements like bullet points or separated sections.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (1 parameter, no output schema, no annotations), the description is minimally adequate. It specifies the output but does not detail the format or additional context that might be needed for full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single parameter completely with a detailed description. The tool description adds no additional meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides each player's tools and upgrade tier, specifying the exact resources (pickaxe, axe, hoe, watering can, rod). This distinguishes it from siblings like 'inventory' or 'players'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The usage is implied but there are no exclusions or alternative tool names provided for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It only lists the items checked, without explaining whether the tool is read-only, if it modifies game state, or any other behavioral traits like required permissions or rate limits. This is a significant gap for a tool that likely runs a complex check.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that clearly conveys the tool's purpose without unnecessary words. However, it lacks structural elements like bullet points or separation of ideas that could improve readability for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and no output schema, the description sufficiently explains what resources are checked. However, it does not describe the output format (e.g., a list of item names) or any other return details, leaving some ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter 'save_path' whose description is thorough. The tool description adds no additional information beyond the schema, so 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly specifies the tool's function: listing ready-to-collect items from machines and harvestable crops. It uses specific verbs ('collect' and 'harvest') and enumerates resource types (kegs, jars, mayo, cheese, tappers, mushroom boxes, crab pots, tilled soil crops). This distinguishes it from sibling tools like 'machines' or 'crop_planner' that may have overlapping but distinct purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used to check what is currently ready to collect or harvest, but it does not explicitly state when to use it versus alternatives like 'machines' for machine status or 'overview' for general farm status. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It states the search scope and return structure (quantity, container location), but omits critical behavioral details like read-only nature, performance implications, side effects, or what happens if the item is not found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, each with clear purpose: first defines action and scope, second describes return format and intent. No superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description provides a reasonable outline of return values (quantity and location) but lacks detail on result structure, error handling, or pagination. For a search tool, this is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no additional semantics beyond the schema, which already details 'name', 'fuzzy' (substring match), and 'save_path' (with path guidance).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'locate', the resource 'item', and the scope 'across player backpacks, all chests, and machine outputs', directly answering 'where is my X?'. This purpose is well-distinguished from sibling tools like 'inventory' and 'chests'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding a specific item's location via 'where is my X?', but lacks explicit when-to-use, when-not-to-use, or comparisons to alternatives. Sibling tools like 'how_to_obtain' suggest different use cases, but no direct guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only mentions output content (undonated items with sourcing notes) without disclosing behavioral traits such as read-only nature, required permissions, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence describing purpose efficiently. No unnecessary words, though could add brief usage note without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with one optional parameter; description sufficiently conveys what it returns. Sufficient for a list tool, despite lacking output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (save_path well-described). Description adds no extra meaning beyond the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists undonated museum items (minerals and artifacts) with sourcing notes, directly distinguishing from the 'museum' sibling tool which likely shows donated status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied—use to see missing items—but no explicit guidance on when to use versus alternatives like 'museum' or 'community_center'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the output is structured key/value fields, which is helpful. However, it doesn't state whether the tool is read-only, requires authentication, or has any limitations. With no annotations, a score of 3 is appropriate as it provides core behavior but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys purpose and value. It is front-loaded with the core function and ends with a compelling reason to use it. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no nested objects, no output schema) and the rich set of sibling tools, the description provides sufficient context. It explains what the tool returns and hints at when to prefer it over others ('most reliable for verification'). Completeness is adequate for this scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (single required parameter 'title' with a clear description). The tool description adds no additional meaning beyond the schema's 'Exact page title, e.g. 'Sturgeon''. Baseline of 3 is warranted as the schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves a page's infobox as structured key/value fields, referencing common fields like price/season/location. It distinguishes from siblings by calling it the 'most reliable surface for verification', implying use for fact-checking. However, it doesn't explicitly state the verb (e.g., 'get' or 'retrieve').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for verification (most reliable surface) but provides no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives such as 'wiki_page' for full content or 'wiki_search' for finding pages, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description discloses what the tool returns but does not mention any behavioral traits such as read-only nature, side effects, or authentication needs. As a progress checker, it is likely safe, but this is not confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the tool's purpose. It is efficient, though it could be slightly more structured with bullet points or separate sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description lists the return components but does not specify their format or structure. For a tool with one parameter, the description is adequate but could be more complete by detailing the output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; the description for the save_path parameter is detailed. The tool description does not add additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides progress information about golden walnuts on Ginger Island, listing specific data points (found vs 130, unspent balance, island unlock status, repeatable-source progress). It distinguishes itself from siblings by being specifically about golden walnuts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking golden walnut progress but does not explicitly state when to use this tool vs alternatives. With many sibling tools, some guidance on when to prefer this would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses the data-driven nature (base sell prices) and scope (backpacks, chests, machine outputs). It implies a read-only calculation with no side effects, which is transparent enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each providing essential information. No redundant or unnecessary text. Front-loaded with the core concept.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains what the tool computes but omits mention of the optional save_path parameter and does not describe the output format. Since there is no output schema, some indication of the return structure would improve completeness. However, for a simple value tool, it is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single parameter 'save_path', but the description does not mention this parameter at all. No additional meaning or usage nuances are provided beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes net worth as gold plus sellable value of all items in backpacks, chests, and machine outputs, using base sell prices. It distinguishes itself as an 'economy snapshot' from sibling tools like 'golden_walnuts' or 'wallet'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or contexts where it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does not mention any side effects, authentication needs, rate limits, or whether the tool is read-only. This is a significant gap for an otherwise helpful description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using two sentences to convey content and usage. It is front-loaded with the resource and purpose, though a more structured format (e.g., bullet points) could improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description adequately explains what the tool returns: buildings, upgrades, capacities, and house levels. It provides enough context for an agent to decide when to invoke it, though it could be slightly more detailed about the scope (e.g., all farm buildings).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a detailed description for the save_path parameter with 100% coverage. The tool description does not add any additional meaning or context for the parameter, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: showing farm buildings, farmhouse upgrades, animal capacities, and house upgrade levels. It uses specific verbs and resources, distinguishing it from sibling tools like 'build_planner' which focus on planning rather than current state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool for reasoning about what to build/upgrade next and checking animal capacity or house perks. While it doesn't mention when not to use it or provide alternatives, the context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions ranking methods and references multipliers, hinting at calculations. However, it does not detail how processing time, seed costs, or artisan profession are handled. The input schema lists relevant parameters (artisan, quality, base_price) but the description does not elaborate on their role.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently communicate the tool's purpose and a key detail (multipliers). No redundant information, and the structure is front-loaded with the main action. Could add a bit more context without bloating, but it's well-sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complete input schema and existence of an output schema (not shown but indicated), the description sufficiently explains the tool's function. It lacks explicit mention of output format, but that is covered by the output schema. Additional details about edge cases or prerequisites would be nice, but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear parameter descriptions. The description adds context by explaining the ranking purpose and referring to multipliers, which complements the schema. It does not provide additional detail beyond the schema and the overall goal, so the added value is moderate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it ranks ways to sell a crop, specifying raw (with Tiller + quality), keg (wine/juice), and jar (jelly/pickle). This distinguishes it from sibling tools like 'processing' and 'processing_planner' which likely focus on processing plans or general processing, not value comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a crop and want to compare selling methods, but it does not explicitly state when to use versus alternatives. No 'when not to use' or exclusions are provided, despite a large sibling list including tools like 'animal_product_value' and 'crop_quality_odds'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It explains the tool uses save context to filter schedules and is paired with user context, but does not state read-only nature, error handling, or output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each earning its place: first defines purpose, second provides usage guidance. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and moderate complexity, the description adequately explains the tool's job but lacks details on return structure or specific behavior when context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The tool description adds 'paired with context' but no additional semantic value beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Describes a specific verb-resource pair: retrieving a villager's schedule and pairing it with save context to pick the correct conditional branch. Clearly distinguishes from sibling wiki tools by emphasizing context integration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tells the agent to 'read the wiki text against the context' and mentions dependencies (season, day, etc.), but does not explicitly differentiate from alternatives like wiki_page or daily_briefing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes core behavior: reads save animals or models a hypothetical. No annotations provided, so description carries full burden. Lacks detail on non-destructive nature, performance, or auth needs, but sufficient for a query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is concise and front-loaded with the result (Iridium/gold/silver/normal produce odds), making it immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, return values need not be explained. The description covers both modes (read vs model) and key inputs. Could mention the mathematical relationship but not necessary for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description adds integration context by grouping parameters (friendship, mood, profession bonus) but does not add substantial new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it computes Iridium/gold/silver/normal produce odds per animal based on friendship, mood, and profession bonus. Distinguishes from sibling 'animal_product_value' which focuses on value, and from 'crop_quality_odds' which is for crops.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies two modes: read all save animals (by default) or model one (by providing parameters). However, no explicit guidance on when to choose this over alternatives like 'animal_product_value' or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose its read-only nature or any authentication requirements. With no annotations provided, the description carries the full burden but only mentions defaults and output fields. It is adequate but not comprehensive, lacking details on side effects or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences. The first sentence states the core purpose and defaults, and the second lists output fields. Every phrase is informative with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of an output schema, the description provides sufficient context about the output fields. It could be more complete by explicitly stating the return format (e.g., list of fish names), but it is adequate for a basic query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value by explaining default behaviors for 'season' (current save's season) and 'weather' (any weather), which compensates for the lack of descriptions in the schema for these parameters. The schema already describes 'save_path' and 'only_uncaught' well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns fish catchable under given conditions, with explicit defaults. It distinguishes itself from sibling tools like fishing_xp_forecast by focusing on availability rather than experience or pond forecasts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The description does not mention any context for choosing this tool over other fishing-related tools, nor does it provide any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description covers the merging behavior and the by_container option. However, it does not disclose read-only nature, performance implications, or any side effects. Adequate but could be more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. Essential information is front-loaded. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's modest complexity (3 boolean params) and no output schema, the description adequately covers functionality. Could mention what the output looks like, but not strictly necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds context for by_container (merging vs breakdown) but not for full or save_path beyond what schema already provides. Minimal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves items from player backpack and chests, with two modes (merged and per-container). It implicitly distinguishes from sibling tool 'chests' by covering both backpack and chest contents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on when to use by_container parameter, but no explicit when-not or alternatives among the 50 sibling tools. Could be improved by mentioning that for per-container breakdown, use by_container or else default merged view.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes return data (counts) but does not disclose operational requirements like needing a save file or side effects. Parameter behavior is covered in schema but not in description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste. Front-loaded with key information: per-player, learned but not made, counts, relation to Perfection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains return values (counts, how many not learned) and context (Perfection). Minor ambiguity about 'Per player' (multiple players?) but otherwise complete for a simple tool with one optional parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The tool description adds no additional meaning for the 'save_path' parameter beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists cooking and crafting recipes learned but not yet made, with counts related to Perfection. This distinguishes it from sibling tools like 'perfection' and 'how_to_obtain'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for progressing Perfection and pairs with 'perfection' categories, but lacks explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses how it works (reads 1.6 mail flags + legacy booleans) and confirms correctness across save versions. This provides good behavioral context beyond just naming the output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences covering purpose and technical nuance. Every word earns its place; no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one optional parameter and no output schema, the description is adequate. It specifies type of items and version handling; could optionally list more items but not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add further parameter details; it only states the purpose. No added value or contradiction.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: retrieving owned special keys/items (Rusty Key, Skull Key, Club Card, etc.), which distinguishes it from sibling tools like 'inventory' or 'chests'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs. alternatives (e.g., inventory). The description only mentions version compatibility, not context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the tool's output (which locations and unlock info) but does not explicitly state read-only nature, prerequisites, or side effects. The implication is read-only, but it could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is structured with a clear first sentence defining purpose, followed by usage guidance. It is slightly verbose due to listing all locations, but every sentence adds value and it is well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input (one optional param with schema coverage) and no output schema, the description adequately explains what the tool returns: reachable locations with gate info and unlock methods. It provides sufficient context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a detailed description of the only parameter (save_path). The tool description does not add additional parameter semantics beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb (list) and clearly specifies the resource (gated locations/vendors reachable in current save), including a list of examples and a concrete use case that distinguishes it from siblings (e.g., filtering item-acquisition advice).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly states when to use the tool: 'Use this to filter item-acquisition advice to what's actually available' with an illustrative example. It does not provide exclusions or when-not-to-use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden. It discloses that the tool fetches wiki summaries (network-dependent), provides locked_source_hints, and includes unlocks snapshot. It does not mention side effects but is accurate for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two well-structured sentences with front-loaded purpose. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although no output schema, the description describes the output format sufficiently: items with summaries, hints, and unlocks snapshot. It covers the key aspects for an AI agent to understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds minimal extra meaning beyond the schema, only briefly connecting research and research_limit to wiki summaries.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns incomplete Community Center bundles with wiki summaries and reachability hints for each needed item, plus locked_source_hints for gated locations. This distinguishes it from siblings like community_center, how_to_obtain, and unlocks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool vs alternatives. It implies usage for checking needed items and gating, but lacks clear 'when to use' or 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description partially compensates by mentioning the Tiller +10% auto-application and the base prices default. However, it does not disclose whether the tool modifies any data, requires specific permissions, or is read-only. More behavioral context would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences that convey the core functionality without any redundant or extraneous information. It is well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 7 parameters, 0 required, high schema coverage (86%), and the presence of an output schema, the description is sufficiently complete. It explains the main goal and key behaviors, though additional details about the output format could be mentioned but are not necessary due to the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the input schema by clarifying that 'base prices' are used unless 'quality_weighted' is enabled, and that Tiller +10% is automatically applied. This enriches the parameter semantics, especially given the high schema coverage (86%).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it determines which crops fully mature within a given window and calculates profit per tile. It specifies the Tiller profession bonus auto-applied and the use of base prices unless quality_weighted is enabled. This clearly defines the tool's purpose and distinguishes it from other crop-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for crop planning but does not provide explicit guidance on when to use this tool over alternatives like 'crop_quality_odds' or 'sprinkler_plan'. It lacks when-not-to-use or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that buffs affect level-dependent effects but not XP gain, and scopes to food/consumable items. This provides useful behavioral context beyond the schema, though could mention if drinks are included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Front-loaded with the key purpose: 'Food/consumable buffs that raise a skill LEVEL'. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description is complete. It explains the domain (food/consumable), effect (raise skill level), and nuance (not XP). Could mention if it includes all buffs or only active ones, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for the only parameter (skill filter). The tool description adds no additional parameter semantics beyond what the schema already provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists food/consumable buffs that raise skill levels, and distinguishes from XP gain. It uses specific examples (Farmer's Lunch +3, Trout Soup +1) and contrasts with sibling tools like skill_xp_forecast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing level-raising buffs but does not explicitly state when to choose this tool over alternatives or when not to use it. Lacks explicit guidance for when to use list_buffs vs. other tools like wiki_page or find_item.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: crops are grouped by the save's own item categories, machine counts are included, and modded items are excluded and listed separately. This adds value beyond the schema, which only describes the save_path parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys the core purpose without unnecessary words. It is front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description adequately covers the purpose and key behaviors. However, it could briefly mention the return format to help the agent interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description is already detailed. The tool description does not add any extra meaning to the single parameter, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool's function: providing keg/jar planning data with grouped crops and machine counts. It distinguishes itself from siblings like 'processing_planner' and 'processing_value' by focusing on held crops and item categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for planning keg/jar processing but does not explicitly state when to use this tool versus alternatives, nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It discloses the tool reads from the save file, lists birthdays within a window, and flags held loved gifts. No destructive or side effects are implied. Transparency is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with main functionality, and uses only necessary sentences. It efficiently communicates the tool's purpose and limitations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although no output schema exists, the description adequately explains what the tool returns (birthdays, hearts, loved gifts, flags). It lacks detail on return format but covers the essential content for a helper tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The description adds minimal new information beyond the schema, such as the window for upcoming days. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: per-villager birthdays, current hearts, notable loved gifts, flagging held gifts, and listing upcoming birthdays. It explicitly distinguishes from wiki_page by noting loved-gift lists are a curated summary, not authoritative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly guides when to use (for quick gift info and birthdays) and explicitly advises using wiki_page for authoritative lists. It does not provide explicit when-not-to-use scenarios, but the alternative is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It states the tool returns a 'lead-section summary' and 'structured infobox', but does not detail the output format (e.g., text vs. JSON) or any potential limitations like freshness of data. The description lacks explicit behavioral traits beyond the basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and no superfluous information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and absence of output schema, the description is mostly complete: it covers purpose, usage context, and relationship to sibling. However, it does not specify the return format (text vs. structured data), which would enhance completeness for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents the single parameter with examples. The description does not add additional semantic information about the parameter beyond what the schema provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a summary of acquisition methods from the wiki's lead section and structured infobox, using specific verbs like 'summary' and 'plan'. It distinguishes itself from sibling wiki_page by offering a condensed overview rather than full drop-rate details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs when to use the tool ('to plan the best way to obtain a quest/bundle item') and when to use an alternative ('Call wiki_page(item) for full drop-rate detail'). This provides clear context and differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that food buffs do not affect XP, which is a key behavioral trait, but does not cover error handling, default behaviors, or what happens if both parameters are supplied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with essential information front-loaded. No wasted words or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately covers the tool's purpose, key parameters, and a behavioral note. It misses details on save path handling or default player, but for a forecasting tool this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds value by explaining the conditional OR relationship between item_price and per_action_xp, and clarifies that food buffs are irrelevant, going beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool forecasts actions needed to reach a target skill level. It distinguishes from siblings like fishing_xp_forecast by covering all skills, and includes specific parameter guidance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on when to use (forecast XP actions) and parameter choices (item_price OR per_action_xp). However, does not explicitly contrast with the sibling fishing_xp_forecast or state exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses output format ('cleaned plain text'), the raw option, redirect behavior, but does not mention error cases (e.g., non-existent pages) or rate limits. Adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with dash and parenthetical list, front-loaded with the action and purpose. No wasted words; every element adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description explains return type ('cleaned plain text') and includes a raw option. It does not detail exact return structure but is sufficient for a simple fetch tool. Could be more specific about what 'cleaned' means.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description reinforces the purpose but adds no new semantic detail beyond the schema definitions for the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Fetch') and resource ('wiki page'), with a clear purpose ('VERIFY facts and pull context') and concrete examples of content types. This distinguishes it from siblings like wiki_infobox or wiki_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (fact verification, context extraction) but does not explicitly mention when not to use it or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses its behavior: it rolls down bars and tapper products, compares against save inventory, and outputs 'still_needed'. It explains the core calculations and what the answer covers, without omitting key traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, info-dense sentence that front-loads the main purpose and efficiently conveys the roll-down logic and inventory comparison. It could be broken into two sentences for readability, but every clause earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a planner with 4 parameters and no output schema, the description adequately explains the output ('what do I need...') and the computational steps. It covers material breakdown, time estimates, and inventory comparison, meeting the needs of a complex planning tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all parameters (100% coverage). The description adds value by explaining how parameters are used: 'spec' defines machines, 'tappers' and 'furnaces' estimate gathering/smelting time, and 'save_path' defaults. This goes beyond bare schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Total materials to craft') and resource ('set of machines'), and clearly distinguishes from siblings by detailing the roll-down logic to ore/coal/furnace-time and tapper-nights, plus inventory comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you need material breakdowns for crafting machines, including ore and tapper products. It does not explicitly state when not to use or name alternatives, but the context of sibling tools like 'processing_planner' provides differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses return structure (grouped by type, counts, state ready/working/idle) and exclusions. It is read-only in nature. Could mention if machines in all locations are included, but 'every placed processing machine' is sufficiently clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with two clear parts: inventory content and usage differentiation. No unnecessary words, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and low complexity (1 param), description covers purpose, exclusions, and sibling differentiation. It doesn't detail exact return format but mentions grouping and state fields, which is adequate for a list-like tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter `save_path`. The description repeats the same information from the schema ('leave empty to use configured save'), adding no new meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is an inventory of processing machines grouped by type with counts and state, and specifies excluded items (chests and decorative craftables). It directly addresses the query 'what/how many machines do I have', showing a specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool ('answer what/how many machines do I have') and distinguishes from the sibling tool 'machines_ready' by noting the latter shows only machines ready to collect. Also specifies exclusions, reducing ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden of behavioral disclosure. It accurately describes what the tool returns for each quest type, including item counts across all containers, the `completable_now` flag, and progress counters. It also explains the research parameter's effect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences front-load the main purpose and detail, with no extraneous information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description provides substantial context about what is returned (quest details, counts, flags). It lacks explicit mention of the output structure or format, but is complete enough for an agent to understand the tool's function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds meaning beyond the schema by explaining that research fetches wiki context (infobox for items, wiki search for quest title) and clarifying save_path behavior for default saves.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns 'every player's active quest journal + the special-orders board' and details what information is provided for different quest types (item delivery/harvest/resource, monster/fishing/socialize). This distinguishes it from siblings by being the primary quest status tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to view active quests and check completion readiness) and the optional research parameter. It does not explicitly state when not to use it, but given the sibling list, no alternative tool exists for this purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool is for title discovery, expects short queries, and is a precursor to other tools. Does not detail output format or error behavior, but adequately conveys non-destructive, read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences plus a short postscript), front-loaded with purpose, and every sentence is meaningful with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists; the description explains that the tool returns best results to be opened by other tools. It covers search scope (item/NPC/event), but lacks explicit mention of result format (likely list of titles). Sufficient for agent to use correctly given sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters described). Description adds value by reinforcing the '1-3 words' and 'NOUN' constraints, and warns against natural-language questions. Provides examples, which goes beyond schema baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds wiki page titles when the name is unknown, specifies the verb (search/resource: wiki page title), and differentiates from sibling tools like how_to_obtain, wiki_infobox, wiki_page by advising direct calls if the name is known.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('when you don't already know it') and when not to ('If you already know the name, skip this'). Provides query format constraints ('1-3 words', 'NOUN', not natural-language questions) and recommends alternatives (prefer how_to_obtain for price queries).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![sdv-mcp MCP server](https://glama.ai/mcp/servers/vehemont/sdv-mcp/badges/card.svg)](https://glama.ai/mcp/servers/vehemont/sdv-mcp)

Score Badge

Copy to your README.md:

[![sdv-mcp MCP server](https://glama.ai/mcp/servers/vehemont/sdv-mcp/badges/score.svg)](https://glama.ai/mcp/servers/vehemont/sdv-mcp)

Latest Blog Posts

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

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/vehemont/sdv-mcp'

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