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

With no annotations provided, the description carries the full burden, and it does a good job by explicitly framing the tool as explanatory rather than data-mutating: it describes schema, business purpose, key fields, and relationships, not row data. It does not disclose error behavior or unsupported table handling, but for a non-destructive metadata-explanation tool the key behavioral traits are communicated.

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 compact and front-loaded: the main purpose comes first, followed by a practical use-case sentence and a minimal parameter definition. There is no fluff or repetition, and the example list earns its place by making the parameter concrete.

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 only one required parameter and an output schema, the description is nearly complete: it names what the output covers and what values table_name should take. A small gap is the lack of explicit guidance on unsupported table names or case sensitivity, but this is minor for a low-complexity explanatory tool.

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

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

The input schema only provides a title ('Table Name') with 0% schema description coverage, so the parameter description must compensate. The description defines table_name as 'Nombre de la tabla' and gives concrete examples ('MULT', 'INVE', 'ALMACENES', 'MINVE', 'FACTF'), which is sufficient for an agent to correctly supply the single required argument. It does not enumerate all valid values, but the examples plus 'etc.' give adequate guidance.

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 a specific verb ('Explica') and a clear resource ('la estructura, propósito de negocio, campos clave y relaciones de una tabla de Aspel SAE'), including concrete examples like MULT, INVE, and FACTF. This clearly distinguishes it from the sibling data-retrieval tools such as get_stock_by_warehouse or search_products, which operate on data rather than explaining table 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 phrase 'Útil para comprender tablas...' provides clear context for when to use the tool: when an agent needs to understand the structure, business purpose, or relationships of an Aspel SAE table. It does not explicitly name alternatives or state when not to use it, so it misses the full when/when-not guidance, but the intended use is unambiguous.

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. The description indicates it is a read operation (consultar) but does not state whether any side effects occur, if authentication is required, or how it behaves with invalid input. It also does not disclose if there are rate limits or if the client info might be stale.

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 very concise, consisting of two sentences and a parameter list in Args. It is front-loaded with the main purpose and lists parameters clearly. Every sentence adds value, and there is no redundancy or filler.

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?

The tool has a clear purpose and simple parameters, but the description lacks important usage context such as prerequisites (e.g., valid company key) and behavioral notes. Although an output schema exists to describe return values, the description does not mention any limitations or edge cases. For a simple read tool, it is adequate but not fully complete.

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 explain parameters. The description mentions 'clave_cliente' as the client key in Aspel SAE, adding a bit of context, but it does not elaborate on the format, length, or how to obtain it. The 'empresa' parameter is only named, with no guidance on required values or defaults beyond 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 retrieves commercial data, tax ID (RFC), address, balance, and credit limit for a client. It names a specific resource (client) and lists the key data fields, distinguishing it from sibling tools that focus on products or documents.

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 explicit guidance on when to use this tool versus alternatives. It lacks information about prerequisites, such as the need for a valid client code, or scenarios where other tools might be more appropriate. Implied usage is that it is for client-related queries, but exclusions or alternatives are not mentioned.

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

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

With no annotations provided, the description carries the full burden. It uses the verb 'Consulta' which strongly implies a read-only operation, and it discloses the output focus (line items and warehouse). However, it does not explicitly state that the tool has no side effects, mention permission requirements, or describe behavior on missing documents. The disclosure is moderate but leaves some behavioral aspects unaddressed.

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

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

The description is two sentences of purpose followed by a compact Args list. It is front-loaded with the primary action and resource, uses no filler, and each sentence earns its place. The structure is clean and scannable for an agent.

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 that an output schema exists (so return values are already documented) and the parameter set is small and simple, the description is sufficient for correct invocation. It covers the tool's purpose and all parameters clearly. Minor gaps like explicit side-effect declaration or failure behavior are mitigated by the 'consulta' wording and the presence of the 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?

Schema description coverage is 0%, so the description must compensate, and it does. The Args section explains every parameter: cve_doc with an example ('1024' or 'A1024'), tipo_doc with its allowed values ('factura', 'pedido', 'remision', 'cotizacion'), and empresa marked as optional. This adds meaning well beyond the bare schema titles and defaults, though it doesn't dive into edge cases like format constraints for empresa.

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 starts with a specific verb and resource: 'Consulta un documento comercial' and enumerates the four document types (factura, pedido, remisión, cotización). It also states the key output component (desglose de partidas with warehouse identification), which makes it clearly distinct from sibling tools like get_stock_by_warehouse or get_product_kardex that operate on stock or product data rather than commercial documents.

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 when to use the tool (when you need details of a specific commercial document and its line items/warehouse assignment), but it gives no explicit comparison with alternatives, no 'use X instead' guidance, and no exclusions. An agent must infer the routing from the purpose statement alone, which is acceptable but not actively guiding.

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 burden. It discloses that the tool returns the full technical sheet and detailed stock per active warehouse, and mentions the CON_CTRL_ALM flag. However, it doesn't disclose whether the operation is read-only, whether it requires specific permissions, or what happens if the article doesn't exist. The description adds some behavioral context but not comprehensive.

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

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

The description is concise and front-loaded with the main purpose, followed by parameter explanations. It's two sentences plus an Args block, with no wasted words. The structure is clear and scannable.

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?

The tool has an output schema, so return values are presumably covered there. The description covers the main purpose and parameters. However, given the sibling tools like get_stock_by_warehouse and get_warehouse_summary, the description could be more explicit about how this tool differs (e.g., it returns the full technical sheet plus stock, not just stock). Also, no mention of error cases or optional empresa behavior. Adequate but with gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It explains cve_art as 'Clave del artículo' and empresa as 'Clave de empresa (opcional)', which adds meaning beyond the bare schema titles. However, it doesn't provide format details, examples, or clarify how empresa affects the result (e.g., filtering warehouses). This is adequate but not rich.

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 retrieves the complete technical sheet of an article, including multialmacén flag and detailed stock per active warehouse. It uses a specific verb ('Obtiene') and resource ('ficha técnica completa de un artículo'), which distinguishes it from siblings like get_stock_by_warehouse or get_warehouse_summary, though it doesn't explicitly name them.

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

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

The description implies usage context: it's for fetching full product detail with stock per warehouse. However, it doesn't explicitly state when to use this tool versus alternatives like get_stock_by_warehouse or get_warehouse_summary, nor does it mention exclusions or prerequisites. The context is clear but the guidance is 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 of behavioral disclosure. It indicates the operation is a query ('Consulta') and mentions a limit cap (max 200), but does not explicitly confirm read-only nature, error conditions, or potential performance considerations. It adds some value but leaves key safety and behavior traits unstated.

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, front-loads the core purpose in the first sentence, follows with a use case, and then lists parameter semantics clearly. No redundant or fluff content, and it is appropriately sized for the tool's complexity.

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?

The description covers purpose, parameter meanings, and optional filters. With an output schema present, return values need not be explained. It could mention pagination behavior beyond the limit (e.g., if limit is only the maximum, are there multiple pages?), but it is mostly complete for a read-only query 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?

Given the schema description coverage is 0%, the description compensates fully by explaining each parameter in the Args section: 'cve_art' as product key, 'cve_alm' as optional warehouse filter, 'fecha_inicio' with format constraints, 'limit' including the maximum, and 'empresa' as optional. This goes beyond the schema and provides practical usage details.

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

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

The description clearly states the tool queries inventory movement history (Kardex) for a product, specifying it audits entries and exits by sales, purchases, and transfers. This distinct resource and operation set it apart from siblings like get_stock_by_warehouse or get_product_detail.

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

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

The description provides no guidance on when to use this tool versus alternatives, such as get_stock_by_warehouse for current stock or get_product_detail for product attributes. It neither implies nor explicitly states selection criteria, leaving the agent to infer that historical movement queries belong here.

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 indicates a read operation via 'Consulta', implying no side effects, and mentions internal table joins ('Cruza la tabla MULT[EE] con ALMACENES[EE]'). However, it does not disclose any behavioral traits like auth requirements, rate limits, or potential side effects, which are expected for a tool with no annotation coverage.

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

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

The description is highly concise: one sentence for purpose, one for implementation detail, and a clean Args list. It front-loads the main purpose and scope without any fluff, and every sentence earns its place.

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 an output schema exists, return format is not the description's responsibility. The description covers all parameter semantics, scope, and a high-level idea of the underlying joins. It is missing edge-case details (e.g., behavior for invalid article codes) but these are not essential for selection and invocation.

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 fully compensates. It explains each parameter: cve_art is the article key in SAE catalog, cve_alm is a numeric warehouse key with behavior (if omitted, returns stock in all warehouses), and empresa is a company key. This adds meaning beyond the plain schema types and defaults.

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 a specific verb ('Consulta'), a clear resource (existencias y stocks mínimo/máximo de un producto), and a scope distinction ('en un almacén específico o en todos'). It clearly differentiates from siblings like get_warehouse_summary (which is warehouse-level, not product-level) and get_product_kardex (which is movement history, not current stock).

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

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

The description implies usage for querying stock by product and optionally warehouse, but does not explicitly compare against alternatives or state when not to use it. It provides context on the scope (all warehouses if cve_alm omitted) but no exclusions or guidance on when to prefer a sibling tool.

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?

Without annotations, the description carries the behavioral burden. It does frame the operation as read-only by using 'Obtiene' and describes the returned summary/alert behavior, including counts of items below minimum stock. However, it does not disclose permissions, pagination, empty-result behavior, or failure modes, so transparency is only partial.

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 main purpose is front-loaded in two tightly written sentences, followed by a minimal Args section. There is no filler or redundant restatement of the tool name, and the size is appropriate for the tool's simplicity.

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

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

The output schema already covers return shape, so the description need not repeat it; it still adds the parameter meanings and low-stock alert behavior that are absent from structured fields. It is slightly incomplete only where usage differentiation and behavioral caveats are missing, but those gaps are already reflected in the corresponding dimension scores.

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 Args section must compensate. It gives helpful context by naming cve_alm as a numeric warehouse key and empresa as an optional company key, which goes beyond the bare schema. Yet the descriptions largely restate the parameter names/types and provide no constraints, format examples, or explanation of how empresa affects the summary.

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 names a specific verb ('Obtiene') and resource ('resumen cuantitativo y alertas de un almacén'), and enumerates specific outputs such as total de artículos, piezas acumuladas, and low-stock list. It is clear, but it does not explicitly contrast with sibling tools like get_stock_by_warehouse, so it stops short of full sibling differentiation.

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?

There is no guidance about when to use this tool versus get_stock_by_warehouse or list_warehouses. The description gives no scenarios, exclusions, or alternative recommendations, and this gap is material because sibling tools share warehouse/stock semantics.

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, the description carries the full burden of behavioral disclosure. It does reveal the source table (ALMACENES) and the default-value behavior for empresa, which is useful. However, it does not state whether the operation is read-only, what permissions are required, whether pagination or limits apply, or what happens when no warehouses exist.

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 purpose is front-loaded in the first sentence and the parameter explanation is compact and directly relevant. Every sentence earns its place; there is no filler or redundant restating of information already present in the schema.

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 list operation with an output schema available, the description covers the core purpose and parameter semantics completely. The only gap is the absence of usage guidance and safety/permission context, but those are addressed in other dimensions and are less critical for a simple listing tool.

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

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

The schema only names 'Empresa' with a null default and no description. The tool description adds that it is a company key, supplies a concrete example ('01'), and clarifies that omission falls back to the default company. This fully compensates for the 0% 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 opens with a specific verb ('Lista'), a concrete resource ('todos los almacenes registrados en ASPEL SAE'), and names the underlying table ALMACENES. This makes the tool's scope explicit and distinguishes it from siblings like get_stock_by_warehouse or get_warehouse_summary, which target individual or summarized warehouse 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?

No statement tells an agent when to choose list_warehouses over its siblings or when not to use it. The only additional context is the optional empresa fallback, which is parameter behavior rather than use-case guidance. Without exclusions or alternative routing, usage guidance is missing.

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 and does well by disclosing automatic protections: AST validation, rejection of INSERT/UPDATE/DELETE/DROP/ALTER/EXECUTE, rejection of semicolon-based multi-statement injection, and automatic injection of Firebird 2.5 'FIRST N' to prevent overflows. This is meaningful behavioral context beyond the basic 'read-only' label.

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 well-structured with a clear opening purpose, a concise protections list, and an args section. It is appropriately sized and front-loaded with the most important behavioral constraints. Minor redundancy exists between 'SOLO LECTURA' and the protections list, but it does not hurt clarity.

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?

The description is adequate for a two-parameter raw query tool with an output schema present, and the safety protections are well covered. However, it lacks explicit usage guidance against siblings, a precise explanation of max_rows behavior (especially null/default semantics), and any example or error-handling hint, which weakens completeness for an agent deciding how to invoke it.

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 compensate, but it only gives minimal, partly ambiguous semantics. 'sql_query' is described as a SELECT statement, which is helpful, but 'max_rows: Límite de filas (máx 200 por defecto)' is unclear and appears inconsistent with the schema default of null, leaving the agent unsure whether null means no limit, a default of 200, or a cap.

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 a specific action ('Ejecuta una consulta SQL SELECT arbitraria') on a specific resource ('base de datos Firebird 2.5') with an explicit read-only scope. This clearly distinguishes it from the sibling tools, which are fixed-purpose warehouse/product/document endpoints.

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: run arbitrary SELECT queries when standard tools are insufficientestrategia. However, it does not explicitly say when not to use it or compare it to the sibling tools, so the guidance remains implicit rather than direct.

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 must carry the full burden of behavioral disclosure. It mentions the inclusion of stock breakdown for multi-warehouse products, which is a useful behavioral trait. However, it does not explicitly state that the operation is read-only, nor does it disclose potential limitations such as pagination behavior beyond the limit parameter, error handling, or permission requirements.

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 well-structured with a brief two-sentence purpose statement followed by an Args list. It is appropriately sized for a tool with six parameters, and the key information is front-loaded. It is not overly verbose, though the Args block is necessary for completeness.

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

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

The description covers the core purpose, all parameter semantics, and the stock-breakdown behavior. An output schema exists, so return values are documented elsewhere. However, it lacks explicit usage guidance (when to prefer this tool over siblings) and does not state that the operation is read-only, which is important for an agent to know. Overall it is adequate but has notable gaps 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?

The description fully compensates for the 0% schema description coverage by providing clear explanations for every parameter in the Args block. For example, query is defined as 'Término de búsqueda (clave o texto descriptivo)', cve_alm includes filtering logic ('stock > 0'), and status lists allowed values with defaults. This goes well beyond the bare schema and adds meaningful semantic context.

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 searches products in the ASPEL SAE catalog by key or description, and mentions the inclusion of stock breakdown per warehouse for multi-warehouse products. This is a specific verb and resource. It does not explicitly contrast with sibling tools like get_product_detail or query_sae_read_only, but the general search function is unambiguous.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention any conditions for choosing search_products over get_product_detail, get_stock_by_warehouse, or other siblings. There is no explicit when-to-use or when-not-to-use instruction.

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