FFRS Wiki - FINAL FANTASY RESONANCE Database

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real behavioral content beyond that: the compared facets and the item-count bounds. It does not describe the response shape, which matters here because there is no output schema.

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

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

Two tight sentences that front-load the trigger before the mechanics, with no filler. The bilingual phrasing and embedded example earn their space by disambiguating intent.

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

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

With no output schema, the description carries the return-value burden, and it does so partially by listing the facets being compared. The unaddressed 'lang' parameter and the absent description of the report's shape are the remaining gaps for a 2-parameter read tool.

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

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

Schema coverage is 50%: 'ids' is already documented with an example and minItems/maxItems, and the description only restates the 2–8 range. The 'lang' parameter is unexplained in both the schema description and the description, leaving a real gap about whether it localizes labels or the whole report.

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

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

States a specific verb and resource ('Compare 2–8 equipment items') and enumerates the compared dimensions (raw parameter blocks, effects, price, type, source count). This is distinguishable from all siblings, which are find/lookup/search tools, though the description never says so explicitly.

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

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

Gives an explicit trigger condition and a concrete example ('轮回之翼和グレートボウ有什么区别'), so an agent knows exactly when to reach for this tool. It does not name alternatives or state when not to use it (for example, single-item lookups, which should go to get_entity).

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that two result sets are returned separately plus resistances, which is useful. It says nothing about what happens when the enemy is not found, how the query/id lookup resolves, or the effect of the lang default.

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

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

Two short sentences, with the trigger condition front-loaded and the output summary following. It is efficient, though the Chinese and English sentences partially duplicate each other rather than complementing, which costs a little space for no added information.

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

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

For a simple read-only lookup this is close to adequate: the output content is described and annotations cover safety. However, with no output schema and no required parameters, the definition should still clarify the query-vs-enemy_id selection and the no-match behavior, which it omits.

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

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

None of the three parameters is mentioned in the description. With zero required parameters, the agent needs to know that either query or enemy_id must be supplied and how they interact, but the description gives no such guidance, leaving 67% schema coverage to carry the load alone for a genuine ambiguity.

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

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

The description names a concrete verb and resource set: an enemy's drop table, steal table, and elemental resistances, with the notable detail that drop and steal results are returned separately. This is enough to distinguish it from siblings like find_sources (the inverse item-to-source lookup) or get_entity, though no sibling is named explicitly.

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

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

The Chinese lead sentence gives an explicit trigger condition (user asks about an enemy's drops, steals, rare drops, or elemental resistances), which is clear activation guidance. It does not state when to avoid this tool or which sibling to use for related but distinct questions, so it falls short of a full when/when-not treatment.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is known; the description adds that output is grouped and localized and claims completeness ("every acquisition route"). It does not say what happens when an id matches nothing, whether results span datasets, or how the localization is applied. Useful but thin context beyond the annotations.

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

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

Two sentences: trigger first, then behavior, with no filler. The mixed-language phrasing (Chinese trigger, English behavior) is slightly inconsistent but each part earns its place, and the route enumeration is compact rather than padded.

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

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

There is no output schema, three parameters at 0% description coverage, and two enums whose meaning is never explained. The description covers what the tool returns conceptually but leaves everything an agent needs in order to actually construct a correct call — id format, kind defaults, lang selection — undocumented.

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

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

Schema description coverage is 0% and the description explains none of the three parameters. "Grouped and localized" faintly implies the lang parameter, and the item-type list hints at kind, but id (string or integer), kind's enum and default, and lang's enum are left entirely to the schema. With zero coverage the description is responsible for compensating and does not.

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

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

The description gives a specific verb and resource ("Return every acquisition route for an equipment/item/vision") and enumerates the route types covered: event grants, chests, quest rewards, shop stock, recipes and map points. That is concrete enough to distinguish it from generic lookups. It does not, however, distinguish it from the sibling tool find_drops, whose name suggests overlapping drop-source behavior.

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

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

The Chinese trigger clause explicitly names the user question that should route here ("where is this equipment/item obtained", "how to get a vision"), which is genuine when-to-use guidance. It gives no when-not guidance and never mentions alternative tools or how to choose between this tool and find_drops when both may surface acquisition data. Usage is implied rather than routed.

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

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so the description's added value here is the localization behavior: all official strings are rewritten to lang, and all_languages returns every language at once. That is genuine behavioral detail not present in the schema, where all_languages has no description at all. It stops short of describing behavior for an unknown id/kind, which is the remaining gap.

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

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

Front-loaded with the action, and every clause carries information. The main inefficiency is that the Chinese and English sentences restate the same purpose, so roughly half the text is redundant to a bilingual reader, though the Chinese line does uniquely enumerate the field groups returned.

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

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

There is no output schema, so the description has to carry the return shape, and the Chinese line does exactly that by naming the field groups included in the record. Combined with the localization rules, an agent has enough to call this correctly and interpret the result.

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

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

Schema description coverage is only 25%, but the description compensates well: it defines what lang actually does (localizes all official strings) and what all_languages=true returns, the two parameters the schema leaves bare. kind and id need little extra explanation since the enum is self-documenting and id already carries an example.

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

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

The English sentence gives a specific verb plus resource ("Fetch the complete record for one entity"), and the Chinese line enumerates what "complete" means (attributes, effects, price, sources, resistance, drops, relations). It is clearly distinct from the sibling search/list tools, though it never names them to make the separation explicit.

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

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

"在已知数据集与 ID 后" implies a prerequisite (you must already know kind and id), which quietly routes an agent to search_ffrs/list_dataset when it lacks an ID, but the guidance is only implied. There is no explicit when-not or named-alternative statement.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=false, and the description adds genuine behavior beyond them: results are paginated, the caller must follow next_offset to continue, and keyword filtering can narrow the set. It does not disclose rate limits, auth needs, or what the payload of each page looks like, but for a read-only list tool the pagination contract is the critical piece and it is stated.

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

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

Two sentences: the first front-loads the trigger conditions, the second the capability and paging directive. Nothing is padded, though the bilingual split means the agent must read both halves to assemble the full picture rather than getting one coherent statement.

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

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

For a 5-parameter, no-output-schema tool, the essentials of browse-and-paginate are present, and the read-only annotations remove the need to discuss side effects. However, the exact pagination mechanics (offset vs next_offset relationship) and the meaning of limit/lang are left implicit, so an agent may still guess on the first call.

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

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

Schema description coverage is only 20% — just the query parameter is documented. The description covers the keyword filter and hints that next_offset is the paging cursor, but it says nothing about lang, limit, offset, or how to choose among the 14 kind enum values. With low coverage the description needed to compensate for those parameters and largely does not.

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

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

States a specific verb and resource ('Page through a dataset') and backs it with concrete scale examples (454 equipment, 979 abilities, 596 enemies), which tells an agent this is a bulk browse/list operation rather than a single-record fetch. The only blemish is that the examples ('abilities') don't all map cleanly onto the kind enum ('skills'), so an agent can't infer the enum from prose alone.

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

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

The opening clause gives explicit trigger conditions: call when the user wants a list of some data class, statistics, or an export. It also says 'optionally filtered by keyword', implying filtering is optional. It stops short of naming when to prefer a sibling such as search_ffrs or get_entity, so routing between browse-vs-search is left to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the agent knows this is a safe, closed-domain lookup. Beyond that, the description only adds that 9 languages exist; it does not say what happens when a key is not found, whether matching is case-sensitive, or what the return value looks like. Useful but thin on behavior beyond the annotations.

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

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

Two short sentences, front-loaded with the trigger condition, with no filler. Minor deduction because the Chinese and English sentences restate the same content rather than the second sentence adding information such as fallback behavior.

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

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

For a 2-parameter lookup with no output schema, the definition covers what to pass but not what comes back (single string vs. structured label) or how misses are handled. These are the details an agent would most want before invoking a translation tool.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It does well on `key`, clarifying that it is a raw internal key or UI string and giving examples. It adds nothing about `lang` beyond 'any official language' — no mention of accepted codes or that the default is English — leaving half the parameter space covered only by the enum.

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

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

The description names a specific verb+resource pair: looking up the official localized label for a raw game key, across 9 languages. It gives concrete example keys (Weapon, Weakness, PhysicalAttack, 宝箱), which makes the domain unambiguous. It does not explicitly differentiate itself from siblings like get_entity or search_ffrs, so it falls short of a 5.

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

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

The Chinese sentence states a clear triggering condition: call this when you need to translate an internal game key or UI string into an official language. There are no exclusions or named alternatives (e.g. when to prefer get_entity for entity metadata instead), so the guidance is clear but not routing-complete.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuine context beyond them: the search spans 14 datasets and 9 languages and yields ids rather than full records, which tells the agent how to chain into get_entity. It does not discuss result ordering or truncation behavior when limit is hit.

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

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

Two front-loaded sentences (bilingual) that lead with the trigger and end with the return-value contract; no filler. The Chinese and English halves are largely redundant, but that redundancy appears intentional for routing and does not obscure the content.

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

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

There is no output schema, and the description compensates by stating exactly what comes back (ids for get_entity), plus dataset and language scope. Combined with the schema documenting query/kinds/lang/limit, an agent has everything needed to call this search tool correctly.

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

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

With 75% schema description coverage the schema already documents query, kinds, and lang, so baseline 3 applies. The description adds a partial enumeration of the dataset kinds and emphasizes cross-language querying, but it says '9 game languages' while listing only seven and never explains the 'is' enum value in lang, leaving a small gap and a mild mismatch.

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

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

States a specific verb+resource ('search ... any FFRS equipment, skill, enemy, quest, item, vision, map, shop, trophy by name, ID or keyword') and scopes it to 'all 14 datasets across all 9 game languages'. It also distinguishes itself from the sibling get_entity by declaring that it 'Returns ids to feed into get_entity', so an agent can tell the two apart without opening schemas.

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

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

Provides a clear triggering condition ('Use when a user asks about any FFRS entity by name or keyword') and implies the follow-up flow via get_entity. It stops short of explicit exclusions or alternatives for siblings such as find_drops, find_sources, or lookup_label, which an agent would have to infer.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and scope are covered. The description's contribution beyond that is enumerating the three counter categories returned, with no note on freshness, units, or numeric formatting — adequate but thin for a statistics tool.

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

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

It is short and front-loads the trigger, but the Chinese sentence and the English sentence convey the same content, so roughly half the text is redundant restatement rather than added information.

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

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

With no output schema, the description must convey return values, and it does so at a category level (counts, languages, human vs AI visits). For a zero-parameter statistics tool this is nearly complete; the only gap is the shape or format of the returned counters.

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

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

There are zero parameters, so there is no parameter semantics to clarify; the baseline for a param-free tool applies. The description correctly implies no input is needed.

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

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

The description names the specific data returned — dataset counts, supported languages, and human vs AI visit counters — which clearly separates it from the unrelated sibling tools (find_drops, get_entity, lookup_label, etc.). It does not explicitly contrast with a named alternative, but no sibling overlaps enough to require that.

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

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

It gives a concrete trigger: call this when the user asks how large the dataset is, which languages are supported, or how many people/AI have visited. That is clear usage context, though no when-not-to-use condition or prerequisite is stated.

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