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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool analyzes portal structures and can obtain sample data, but doesn't describe what 'analyze' entails operationally (e.g., is it read-only, does it require specific permissions, what's the response format, are there rate limits?). For a tool with no annotation coverage, this leaves significant behavioral gaps, though it does mention Data API support as a minor contextual hint.

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

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

The description is appropriately sized with two sentences that efficiently convey the core functionality and technical context. It's front-loaded with the main purpose, followed by a supporting detail about Data API support. There's no wasted verbiage, though the second sentence could be more tightly integrated with the first for better flow.

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

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

Given the tool's complexity (analyzing portal structures with optional sample data), no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., read/write nature, error handling), output format, and how it differs from sibling tools. The mention of Data API support is insufficient to compensate for these gaps, making it inadequate for an agent to fully understand the tool's context and usage.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters (layout, includeSampleData, sampleLimit) with descriptions. The description adds marginal value by mentioning 'sample data (optional)' which aligns with includeSampleData, but doesn't provide additional semantics beyond what's in the schema. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.

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

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

The description clearly states the tool's purpose: analyzing portal structures within a specified layout, obtaining field definitions, inferred related table names, and optional sample data. It uses specific verbs like 'analyze' and 'obtain' with clear resources (portal structures, field definitions, table names, sample data). However, it doesn't explicitly differentiate from sibling tools like fm_get_layout_metadata or fm_infer_relationships, which appear related to metadata analysis.

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

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

The description provides no guidance on when to use this tool versus alternatives. It mentions that the feature is 'fully supported by the Data API,' but this is generic technical context rather than usage guidance. There's no indication of prerequisites, typical use cases, or comparisons with sibling tools like fm_get_layout_metadata or fm_infer_relationships, leaving the agent to infer usage context.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It effectively communicates important limitations: the export is not a true DDR, and specific elements like relationship definitions, calculation formulas, and script contents cannot be retrieved. This provides crucial context about what the tool can and cannot do beyond basic functionality.

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

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

The description is efficiently structured with two sentences: the first states the core functionality, and the second provides crucial limitations. Every sentence earns its place by adding essential information. The warning about API constraints is appropriately placed and necessary for proper tool understanding.

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

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

For a tool with no annotations and no output schema, the description does well in covering the essential behavioral context (limitations, scope). It explains what the tool does and what it cannot do. However, it doesn't mention authentication requirements, rate limits, or what the export output looks like, which would be helpful given the absence of output schema.

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 100% schema description coverage, the baseline is 3. The description doesn't add specific parameter semantics beyond what's already documented in the schema. While it mentions the types of information being exported (layouts, fields, scripts, value lists), this doesn't provide additional guidance about parameter usage beyond the schema's descriptions of includeLayouts, includeScripts, etc.

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

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

The description clearly states the specific action ('export'), resource ('database structural information'), and scope ('layouts, fields, scripts, value lists'). It distinguishes this tool from siblings like fm_get_layout_metadata, fm_get_scripts, and fm_list_value_lists by emphasizing aggregation and export functionality rather than individual retrieval.

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

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

The description provides clear context about when to use this tool by stating it aggregates multiple structural elements into a single export, which implies it's for comprehensive metadata extraction rather than piecemeal retrieval. However, it doesn't explicitly mention when NOT to use it or name specific alternatives among the sibling tools.

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

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It states the tool searches records but doesn't mention whether this is a read-only operation, what permissions are required, whether results are paginated, what happens with no matches, or any rate limits. For a search tool with 5 parameters and no annotation coverage, this is inadequate behavioral context.

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

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

The description is a single, efficient Japanese sentence that states the core purpose without unnecessary words. It's appropriately sized for a search tool and front-loads the essential information. Every word earns its place in this minimal description.

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 search tool with 5 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what constitutes a 'record' in this context, how results are returned, error conditions, or relationship to sibling tools. The agent lacks crucial context about this tool's behavior and integration within the FileMaker ecosystem.

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

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

Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain the query array structure, layout significance, or how sort/limit/offset interact. With complete schema coverage, baseline 3 is appropriate.

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

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

The description states the tool's purpose as '検索条件に一致するレコードを検索します' (searches for records matching search criteria), which is clear but generic. It specifies the verb (search) and resource (records), but doesn't differentiate from sibling tools like fm_get_records or fm_global_search_data, leaving ambiguity about when to use this specific search tool.

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

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

The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools that also retrieve records (fm_get_records, fm_get_record_by_id, fm_global_search_data), there's no indication of this tool's specific use case, prerequisites, or exclusions. The agent must infer usage from the parameter schema alone.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a retrieval operation but doesn't mention whether it requires authentication, has rate limits, returns structured data, or handles errors. For a metadata retrieval tool with zero annotation coverage, this leaves significant behavioral gaps that could impact agent decision-making.

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

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

The description is a single, efficient sentence that clearly states the tool's purpose. It's appropriately sized for a simple retrieval tool with one parameter. There's no wasted verbiage or unnecessary elaboration, though it could potentially benefit from slightly more context given the lack of annotations.

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 single-parameter retrieval tool with no output schema and no annotations, the description provides adequate but minimal information. It covers what the tool does but leaves gaps around authentication requirements, return format, error handling, and differentiation from sibling tools. The description meets minimum viability but doesn't fully compensate for the lack of structured metadata.

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

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

The schema has 100% description coverage with a clear parameter description ('レイアウト名' - layout name). The description doesn't add any parameter-specific information beyond what's in the schema, but with complete schema documentation, a baseline score of 3 is appropriate. The description does reinforce that the layout parameter is for specifying which layout's metadata to retrieve.

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

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

The description clearly states the action ('取得します' - retrieves) and the resources (field definitions, portal information, value lists) for a specified layout. It distinguishes this from general layout listing tools like 'fm_get_layouts' by specifying metadata retrieval rather than just listing layouts. However, it doesn't explicitly differentiate from other metadata tools like 'fm_export_database_metadata'.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (like needing a valid session), when this is appropriate versus using 'fm_get_layouts' for basic layout information, or how it differs from 'fm_export_database_metadata' which might provide broader metadata. The agent must infer usage context from the tool name alone.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves a list, implying a read-only operation, but doesn't specify whether it's paginated, sorted, or filtered, nor does it mention authentication requirements, rate limits, or error handling. The description is minimal and lacks behavioral details beyond the basic action.

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

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

The description is a single, clear sentence in Japanese that directly states the tool's purpose without any fluff or redundant information. It is front-loaded and efficiently conveys the essential action, making it highly concise and well-structured.

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

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

Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but minimal. It covers the basic purpose but lacks context on usage guidelines, behavioral traits, and integration with sibling tools. For a read operation in a database context, more details on authentication or output format would enhance completeness.

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

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

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here. A baseline of 4 is applied as it compensates adequately for the lack of parameters by not introducing unnecessary information.

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

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

The description clearly states the tool's purpose: 'データベース内のすべてのレイアウト一覧を取得します' (Retrieves a list of all layouts in the database). It specifies the verb (retrieves/get) and resource (layouts), but doesn't explicitly differentiate from sibling tools like fm_get_layout_metadata, which might retrieve metadata about specific layouts rather than listing them all.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like fm_get_layout_metadata or fm_get_records, nor does it specify prerequisites such as authentication or session validation, which are implied by the presence of fm_login, fm_logout, and fm_validate_session tools.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves a record, implying a read-only operation, but doesn't clarify permissions, error handling, rate limits, or what happens if the record ID doesn't exist. For a tool with no annotations, this leaves significant behavioral gaps.

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

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

The description is a single, efficient sentence in Japanese that directly states the tool's function. It's front-loaded with the core action and has no unnecessary words, making it highly concise and well-structured.

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

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

Given the complexity (a read operation with two required parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., record data, error messages), behavioral aspects like authentication needs, or how it differs from similar tools. This leaves the agent with insufficient context for reliable use.

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

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

The input schema has 100% description coverage, with clear documentation for both parameters ('layout' as layout name, 'recordId' as FileMaker record ID). The description doesn't add any semantic details beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: '指定されたレコードIDのレコードを取得します' translates to 'Retrieves the record for the specified record ID.' This is a specific verb+resource combination (retrieve + record). However, it doesn't explicitly differentiate from sibling tools like 'fm_get_records' (plural) or 'fm_find_records', which might have different scopes or filtering capabilities.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a layout name), exclusions, or comparisons to sibling tools like 'fm_get_records' or 'fm_find_records'. The agent must infer usage from the tool name and parameters alone.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool is read-only (取得/retrieve) and efficient (効率的に), but doesn't mention authentication needs, rate limits, error conditions, or what happens if the layout doesn't exist. For a tool with no annotations, this is a moderate disclosure level.

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

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

The description is two concise sentences that are front-loaded with the core purpose. Every sentence adds value: the first states what it does, the second clarifies what it doesn't do and its efficiency. There is zero waste or redundancy.

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

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

Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is adequate but not complete. It explains the purpose and efficiency but lacks details on authentication, error handling, or return format. For a simple read operation, this is minimally sufficient but could be more comprehensive.

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

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

The schema description coverage is 100%, with the single parameter 'layout' documented as 'レイアウト名' (layout name). The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 for high schema coverage.

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

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

The description clearly states the tool's purpose: '指定されたレイアウトの総レコード数を取得します' (get the total record count for a specified layout). It specifies the verb (取得/retrieve), resource (レコード数/record count), and distinguishes from siblings like fm_get_records or fm_get_record_by_id by emphasizing it only returns count, not record data.

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

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

The description provides clear context on when to use this tool: 'レコードデータは取得せず、カウントのみを効率的に返します' (does not retrieve record data, only returns count efficiently). This implicitly suggests using fm_get_records or fm_get_record_by_id when actual record data is needed, but it doesn't explicitly name alternatives or state 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.

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions pagination support, which is useful, but does not describe other critical behaviors: authentication requirements, rate limits, error handling, or what the return format looks like (e.g., structure of records). For a tool that likely interacts with a database or system, this leaves significant gaps in understanding how it operates.

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

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

The description is a single, efficient sentence that states the core action and includes pagination support. It is appropriately sized and front-loaded with the main purpose. However, it could be slightly more structured by separating key points, but it avoids unnecessary verbosity.

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

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

Given the complexity (a data retrieval tool with pagination), lack of annotations, and no output schema, the description is incomplete. It does not cover authentication needs, return format, error conditions, or how it differs from sibling tools. The description alone is insufficient for an agent to fully understand how to use this tool effectively in context.

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

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

Schema description coverage is 100%, so the schema already documents all parameters (layout, limit, offset) with descriptions and defaults. The description adds no additional meaning beyond what the schema provides—it does not explain the significance of 'layout' in context, how pagination works with limit/offset, or any constraints. Baseline 3 is appropriate as the schema does the heavy lifting.

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

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

The description states the purpose ('retrieve records from a specified layout') which is clear but lacks specificity about what kind of records or system this refers to. It distinguishes from some siblings like 'fm_get_record_by_id' (retrieval by ID vs layout) but not clearly from 'fm_find_records' or 'fm_global_search_data' which might have overlapping functionality. The purpose is understandable but could be more precise about the domain/context.

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

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

The description provides no guidance on when to use this tool versus alternatives. It mentions pagination support, but does not specify scenarios where this tool is preferred over siblings like 'fm_find_records' or 'fm_global_search_data', nor does it mention prerequisites (e.g., requires authentication). Usage context is implied but not explicitly stated.

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

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

No annotations are provided, so the description carries full burden. It states it retrieves a list but doesn't disclose behavioral traits like whether it's paginated, sorted, filtered, or if it requires specific permissions. The description is minimal and lacks context about what 'all scripts' entails or any limitations.

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

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

The description is a single, efficient sentence in Japanese that directly states the tool's purpose. It's front-loaded with the key information (retrieving all scripts) and has no wasted words, making it appropriately sized for a simple tool.

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

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

Given the tool has no parameters, no annotations, and no output schema, the description is adequate for a basic list operation but lacks completeness. It doesn't explain what the output looks like (e.g., format, structure) or any behavioral details, which could be important for an AI agent to use it 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?

The tool has 0 parameters, and schema description coverage is 100% (since there are no parameters). The description doesn't need to add parameter semantics, so it meets the baseline of 4 for having no parameters to document.

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

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

The description clearly states the action ('取得します' - get/retrieve) and resource ('データベース内のすべてのスクリプト一覧' - list of all scripts in the database). It's specific about what it retrieves (all scripts), but doesn't explicitly differentiate from siblings like fm_get_layouts or fm_get_layout_metadata, which handle different resource types.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (like needing authentication), nor does it compare with siblings like fm_global_search_data or fm_find_records that might retrieve different data. Usage context is implied but not explicit.

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

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

With no annotations provided, the description carries the full burden. It discloses the OR search behavior and performance implications (important for a search tool), but doesn't mention authentication needs, rate limits, pagination, or what the aggregated results look like. It adds some behavioral context but leaves significant gaps.

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

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

Three sentences that are front-loaded with the core functionality, followed by implementation details and a performance warning. Every sentence earns its place by adding distinct value: purpose, search behavior, and important constraint.

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 search tool with 3 parameters (including a nested options object), no annotations, and no output schema, the description is adequate but incomplete. It covers the cross-layout scope and performance warning well, but doesn't address authentication, error conditions, or result format. Given the complexity and lack of structured output documentation, it should do more.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema descriptions. It mentions 'text fields' which aligns with the searchText parameter but doesn't provide additional syntax or format details.

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

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

The description clearly states the specific action ('search data across multiple layouts'), resource ('text fields in layouts'), and scope ('OR search across layouts, aggregating results'). It distinguishes from siblings like fm_find_records (likely single-layout) and fm_global_search_fields (searching fields rather than data).

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

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

The description provides clear context for when to use this tool ('search across multiple layouts') and includes a performance warning about specifying too many layouts. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the siblings, though the context implies it's for cross-layout searches.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool is '便利です' (useful) but doesn't describe what the tool actually returns (field metadata, counts, etc.), whether it's read-only or has side effects, performance characteristics, or error conditions. For a search tool with 3 parameters and no annotation coverage, this is a significant gap.

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

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

The description is appropriately concise with two sentences. The first sentence states the core functionality, the second provides usage context. There's no wasted text, though it could be slightly more front-loaded with the most critical 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 search tool with 3 parameters, 100% schema coverage, but no annotations and no output schema, the description provides adequate purpose and usage context but lacks behavioral transparency about what the tool returns and how it behaves. The description mentions it's 'useful for investigating database structure' which helps, but doesn't complete the picture for an agent trying 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.

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

Schema description coverage is 100%, so the schema already fully documents all 3 parameters. The description adds minimal value beyond the schema - it mentions field name patterns and field type filtering, which the schema already covers. The baseline of 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the tool's purpose: '全レイヤウトを横断してフィールドを検索します' (search fields across all layouts). It specifies the resource (fields) and action (search) with filtering capabilities. However, it doesn't explicitly differentiate from sibling tools like 'fm_global_search_data' which searches data rather than fields.

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

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

The description provides implied usage context: 'データベース構造の調査やフィールド命名規則の確認に便利です' (useful for investigating database structure and checking field naming conventions). This gives general guidance but doesn't explicitly state when to use this vs alternatives like 'fm_get_layout_metadata' or 'fm_global_search_data', nor does it provide exclusion criteria.

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

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

With no annotations provided, the description carries the full burden. It effectively discloses key behavioral traits: the tool produces inferred results (not definitive), results may differ from actual FileMaker definitions, and confidence scores should be checked. This covers the speculative nature and reliability aspects. However, it doesn't mention performance characteristics, rate limits, or authentication needs.

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

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

The description is appropriately sized with two sentences: the first states the purpose, the second provides critical behavioral warnings. Every sentence earns its place by adding essential information. It's front-loaded with the core function and avoids unnecessary elaboration.

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

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

Given the tool's moderate complexity (inference-based analysis), no annotations, and no output schema, the description does a good job covering the core functionality and reliability caveats. However, it doesn't explain what the output looks like (e.g., format of inferred relationships, confidence scale) or potential error conditions, leaving some gaps for a tool without structured output documentation.

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

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

Schema description coverage is 100%, so the schema already documents both parameters (layout and depth). The description adds marginal value by mentioning 'portals and field name patterns' which relates to the layout parameter, but doesn't provide additional syntax or format details beyond what the schema provides. The baseline of 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the tool's purpose: 'infer relationships from specified layout's portals and field name patterns' (verb+resource). It distinguishes from siblings like fm_get_layout_metadata or fm_analyze_portal_data by focusing on relationship inference rather than metadata retrieval or data analysis. However, it doesn't explicitly contrast with all siblings (e.g., fm_export_database_metadata might also involve relationships).

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

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

The description implies usage context through the warning about results being 'inferences' that may differ from actual FileMaker relationship definitions and the instruction to check confidence. However, it doesn't explicitly state when to use this tool versus alternatives like fm_get_layout_metadata (which might provide actual relationship data) or fm_analyze_portal_data. No explicit exclusions or prerequisites are mentioned.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes a read operation ('取得します' - retrieves), which implies it's non-destructive, but doesn't address other behavioral aspects such as authentication requirements, rate limits, error handling, or response format. For a tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves beyond the basic read intent.

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

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

The description is concise and well-structured in two sentences: the first states the core action and resource, and the second adds practical context (checking dropdown options). There is no wasted text, and it's front-loaded with the main purpose. However, it could be slightly more efficient by combining ideas, but it remains clear and to the point.

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

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

Given the tool has no annotations, no output schema, and 1 parameter with full schema coverage, the description is incomplete. It adequately explains what the tool does but lacks critical behavioral details (e.g., authentication needs, response structure) and usage guidelines. For a tool in a context with sibling tools and potential complexity (e.g., related to layouts and value lists), more comprehensive information is needed to ensure the agent can use it effectively.

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

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

The input schema has 100% description coverage, with the single parameter 'layout' documented as 'レイアウト名' (layout name). The description adds minimal context by mentioning '指定されたレイアウトで' (in the specified layout), reinforcing the parameter's role but not providing additional semantics like format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't significantly enhance parameter understanding beyond the schema.

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

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

The description clearly states the tool's purpose: '取得します' (retrieves/gets) '値一覧(Value Lists)' (value lists) '指定されたレイアウトで利用可能な' (available in the specified layout). It specifies the verb (retrieve) and resource (value lists) with context (layout-specific). However, it doesn't explicitly distinguish this from sibling tools like fm_get_layout_metadata or fm_get_layouts, which might also retrieve layout-related information.

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

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

The description provides minimal guidance: it implies usage when you need to check dropdown options in fields for a layout. However, it doesn't specify when to use this tool versus alternatives (e.g., fm_get_layout_metadata might provide similar or overlapping data), nor does it mention prerequisites (e.g., authentication, session validity) or exclusions. No explicit when/when-not or alternative tool references are provided.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the authentication mechanism and optional parameter usage, but doesn't describe what happens on successful login (e.g., session token returned), error conditions, rate limits, or security implications. The description adds some value but leaves significant behavioral aspects unspecified.

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

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

The description is perfectly concise with just two sentences. The first sentence states the core purpose, and the second sentence provides important usage information about environment variables. Every word earns its place with zero wasted 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?

For an authentication tool with no annotations and no output schema, the description provides adequate basic information about what the tool does and parameter handling. However, it doesn't explain what the tool returns (session token, success indicator, etc.), error handling, or security considerations, which are important for a login operation. The description is minimally complete but has clear gaps.

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

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

The schema description coverage is 100%, so the schema already documents all four parameters with their types and descriptions. The description mentions that parameters can be omitted when using environment variables, which adds marginal context about parameter usage but doesn't provide additional semantic meaning beyond what's in the schema. This meets the baseline expectation.

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

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

The description clearly states the specific action ('ログインしてセッションを確立します' - login and establish a session) and the target resource ('FileMakerサーバー' - FileMaker server). It distinguishes itself from sibling tools like fm_logout or fm_validate_session by focusing on initial authentication rather than session termination or validation.

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

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

The description provides clear context about when to use this tool (to establish a session with FileMaker server) and mentions that parameters can be omitted if authentication credentials are loaded from environment variables. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools.

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

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

No annotations are provided, so the description carries full burden. '終了します' (ends) implies a destructive/mutative operation, but the description doesn't clarify what happens after logout (session invalidation, cleanup), whether authentication is required to call it, or what the expected outcome is. For a session management tool with zero annotation coverage, this leaves significant behavioral gaps.

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

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

The description is a single, efficient Japanese sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized for a simple logout operation and front-loads the essential information.

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

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

Given the tool's simplicity (0 parameters, no output schema) and the lack of annotations, the description provides the basic purpose but lacks important context. For a session management tool, it should ideally mention what happens post-logout, whether this affects other operations, or what confirmation/response to expect. The description is minimally adequate but has clear gaps.

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

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

The tool has 0 parameters with 100% schema description coverage. The description appropriately doesn't discuss parameters since none exist. It focuses on the tool's action rather than parameter details, which is correct for a parameterless tool.

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 '現在のセッションを終了します。' (Ends the current session) clearly states the tool's purpose with a specific verb ('終了します' - ends/terminates) and resource ('セッション' - session). It distinguishes itself from sibling tools like fm_login and fm_validate_session which handle session initiation and validation rather than termination. However, it doesn't explicitly mention what type of session (FileMaker session) or system context.

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

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

The description implies usage context - to end a current session - but doesn't provide explicit guidance on when to use this tool versus alternatives. No prerequisites (like requiring an active session first) or exclusions are mentioned. The agent must infer usage from the purpose statement alone.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('check if the session is valid') but doesn't add context such as what constitutes validity, authentication requirements, rate limits, or response behavior. This is a significant gap for a tool with zero annotation coverage, though not contradictory.

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

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

The description is a single, efficient sentence in Japanese that directly states the tool's purpose. It is front-loaded with the core action and has no wasted words, making it highly concise and well-structured for quick understanding.

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

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

Given the tool's complexity (simple validation with no parameters) and lack of annotations and output schema, the description is incomplete. It doesn't explain what 'valid' means, potential outcomes (e.g., boolean result, error codes), or integration with sibling tools. For a validation tool, more context is needed to guide an AI agent effectively.

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

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

The tool has 0 parameters, and schema description coverage is 100% (empty schema). With no parameters, the description doesn't need to add semantic details beyond the schema. It appropriately focuses on the tool's purpose without redundant parameter information, meeting the baseline for zero-parameter tools.

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 states the purpose ('セッションが有効かどうかを確認します' translates to 'Check if the session is valid') which is clear but vague. It specifies the verb ('check/confirm') and resource ('session validity'), but doesn't distinguish from siblings like fm_login or fm_logout beyond the basic action. No tautology or misleading elements are present.

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

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

No explicit guidance on when to use this tool versus alternatives is provided. The description implies usage for session validation, but it doesn't specify contexts (e.g., before other operations), exclusions, or comparisons to sibling tools like fm_login (for authentication) or fm_logout (for termination). This leaves gaps for an AI agent to infer correct usage.

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