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 only states the basic retrieval action and does not mention read-only behavior, error handling, precedence when both parameters are provided, or what happens if neither is provided. This lack of behavioral context is a significant gap.

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

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

The description is a single sentence that front-loads the verb 'Get' and immediately specifies the resource and identifiers. There is no wasted wording, making it exceptionally 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 absence of annotations and an output schema, the description is minimal. It explains how to identify the customer but does not elaborate on what 'full record' includes, behavior with missing or conflicting parameters, or return format. For a simple get tool it is adequate but leaves several contextual gaps.

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

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

The input schema already covers both parameters with descriptions ('Customer GUID id' and 'Customer No., e.g. C00120'), giving 100% schema coverage. The description adds the 'or' relationship between the two parameters but does not clarify whether at least one is required or what happens if both are supplied. Baseline 3 is appropriate since the schema does the heavy lifting.

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

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

The description clearly states the action ('Get') and the specific resource ('one customer's full record'), and distinguishes itself from siblings like bc_list_customers by emphasizing 'one' customer. The identifiers (customer number and GUID id) are explicitly mentioned, making the purpose 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 implies usage for retrieving a single customer, but it does not explicitly state when to use this tool versus alternatives like bc_list_customers or bc_query. There are no exclusions or alternative recommendations, so the usage context is only implied rather than explicitly guided.

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 notes that the response includes invoice lines, which is a behavioral detail. It also discloses the two identifier options. It doesn't mention error handling or permissions, but for a simple GET operation this is sufficient.

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, front-loaded sentence with no filler words. It conveys the core purpose, the identifier options, and the inclusion of lines efficiently.

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, the description is complete: it identifies the target resource, how to select it, and what is included in the result. It lacks an explicit fallback for the case where neither id nor invoice_number is provided, but the phrase 'by invoice number or GUID id' implies a requirement to provide one.

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 already documents all three parameters with descriptions (100% coverage). The description adds minimal new meaning beyond the schema—it restates that lookup can be by invoice number or GUID id, and that lines are included, which slightly reinforces the include_lines parameter.

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

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

The description clearly states the action ('Get'), the target resource ('one sales invoice'), and the scope ('by invoice number or GUID id, including its lines'). This distinguishes it from list-like siblings such as bc_list_sales_invoices.

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 this tool: when you have a specific invoice number or GUID id and need a single invoice with its lines. It does not explicitly contrast with alternative tools (e.g., list all sales invoices), but the context of siblings makes the distinction clear.

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 burden of behavior disclosure. It communicates that this is a fetch operation (get) and that it can include lines, which conveys the main behavioral aspect. It does not mention error handling or response format, but acknowledges the read-only nature implicitly.

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

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

The description is a single, well-structured sentence that immediately states the action and key parameters. It is concise with no redundant words.

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

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

Given the tool's simplicity (3 optional parameters, no output schema), the description adequately covers the main usage and expected result (sales order with lines). Minor gaps exist around parameter interaction (e.g., precedence if both are provided), but overall it's sufficient for an agent to select and invoke 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?

Schema coverage is 100%, so the baseline is 3. The description adds meaning by clarifying that either id or order_number can be used, and provides an example order number format (S-ORD101001), which goes beyond the schema's field descriptions.

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 specifies a clear action: 'Get one sales order' by two possible identifiers (order number or GUID), and notes that lines are included. This clearly distinguishes it from sibling tools like bc_list_sales_orders (listing) and bc_get_sales_invoice (different resource).

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 establishes a clear context: use this when you need a single sales order by ID or number. However, it does not explicitly mention when to use list tools instead or any exclusions, so it falls short of full explicit guidance.

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

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

The description adds the behavioral detail that only companies visible to the current connection are returned, which is useful context. However, it does not mention read-only status, return format, or error behavior, which would be valuable given no annotations 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 description is a single, focused sentence that immediately conveys the tool's purpose without redundancy.

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

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

The tool is simple with no parameters or output schema, so the description provides the core purpose and scope. It lacks details on the return structure (e.g., fields, pagination), which is a minor gap for an agent.

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

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

There are zero parameters, so the description needs to explain no parameter semantics. The baseline score of 4 applies.

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

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

The description clearly states the action ('List'), the resource ('Business Central companies'), and the scope ('visible to this connection'), distinguishing it from sibling tools that list other entity 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?

No guidance is provided about when to use this tool versus the sibling list tools. It simply states its function without mentioning alternatives or exclusions.

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

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

With no annotations, the description carries the full burden. It adds behavioral details by explaining that `search` performs a name substring match and `filter` takes a raw OData $filter, which goes beyond the schema. However, it does not mention pagination default/limits (top/skip) or the output shape, which are left to the 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?

The description is two sentences long, with the first sentence stating the purpose and the second providing parameter usage. Every sentence earns its place; no fluff or repetition.

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 and full schema coverage, the description adequately covers the core functionality and parameter behavior. It lacks explicit mention of alternative tools (e.g., bc_get_customer for a single customer) and output details, but these are not critical for a straightforward list operation.

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 baseline is 3. The description adds 'Use `search` for a name substring match, or `filter` for a raw OData $filter,' which reinforces the schema but does not introduce new information about the parameters beyond what the schema already provides.

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

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

The description clearly states 'List customers' with a specific verb and resource, and the phrase 'in the working company' adds useful context. It distinguishes itself from sibling tools like bc_list_items, bc_list_vendors, and bc_get_customer by focusing on the customer list resource.

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 guidance on using the `search` and `filter` parameters, but does not explicitly mention when to use this tool over alternatives like bc_get_customer or bc_query. The usage context is implied by the tool's name, but no exclusions or alternative tool recommendations are given.

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 does not mention pagination behavior, default limits, or the return format, although top/skip schema descriptions hint at paging. The description only provides parameter semantics without deeper 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 two concise sentences: the first states the purpose, the second gives parameter usage guidance. Every word earns its place, with no redundancy or fluff.

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 and parameter usage well, but lacks details on return values and behavioral traits like pagination or default limits. Since there is no output schema, the description should at least mention what is returned, but it only implies a list of inventory items.

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 100%, so the baseline is 3. The description adds practical guidance by explaining that `search` performs a substring match on displayName (already in schema) and providing a concrete OData filter example (`inventory lt 10`), which enriches the schema's bare description.

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 lists inventory items in the working company, using the specific verb 'List' and resource 'inventory items'. This distinguishes it from sibling tools that list other entities (companies, customers, sales orders).

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 guidance on how to use the parameters: use `search` for substring match and `filter` for OData filtering with an example. However, it does not explicitly compare against alternatives like bc_query or other list tools, though the purpose clearly delineates when to use this 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?

There are no annotations, so the description must disclose behavior. It mentions it lists invoices and the available filters, but it doesn't confirm read-only behavior, describe the response structure, or explain pagination behavior beyond what the schema implies. The 'posted/draft' wording is slightly ambiguous compared to the listed statuses, but overall it gives moderate 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, well-structured sentence that front-loads the core action ('List posted/draft sales invoices') and then efficiently compacts the optional filters. No words are wasted.

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 8 parameters, all documented, but no output schema and no annotations. The description covers the core listing and filtering capabilities adequately; however, it doesn't specify the return type or any additional usage context like paging, which is left to the schema. Given the simplicity of a list operation, this is reasonably 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 coverage is 100%, with each of the 8 parameters having a description. The tool description summarizes the filter concepts in natural language but doesn't add meaning beyond the existing parameter descriptions, so a baseline score of 3 is appropriate.

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

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

The description uses a specific verb 'List' and clear resource 'sales invoices', and further specifies 'posted/draft' and the filtering dimensions (customer number, status, date range, unpaid balance). This clearly distinguishes it from siblings like bc_list_sales_orders and bc_get_sales_invoice.

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: this tool lists sales invoices in bulk with optional filters. It doesn't explicitly state when not to use it or point to alternatives such as bc_get_sales_invoice for single invoices, but the plural 'invoices' and filter options make its role clear.

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 filtering is optional and lists filter categories, but it does not mention pagination behavior, default/max record counts, response shape, or the raw OData filter semantics. The 'List' verb implies a read-safe operation, but deeper behavioral context is missing.

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?

A single, well-structured sentence begins with the verb 'List', names the resource, and lists optional filter categories. There is zero redundancy, and every part of the sentence contributes to understanding the tool's purpose.

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 moderate complexity of a list tool with 7 parameters, the description provides a sufficient overview of purpose and filtering. Combined with the fully described schema, an agent can likely invoke the tool correctly. The only missing context is response format and pagination defaults, but these are not critical for a list operation.

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 100% for all 7 parameters, so the baseline is 3. The description adds a high-level grouping of filters (customer, status, date range) and repeats the status values, but it does not introduce any new details beyond what the schema already provides.

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

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

The description clearly states the tool lists sales orders, with the specific verb 'List' and resource 'sales orders'. It distinguishes from the sibling tool 'bc_get_sales_order' by implying a list versus single-record operation, and it enumerates key filter options (customer number, status, date range).

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

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

The description implies usage for retrieving sales orders with optional filters, but it does not explicitly state when to use this tool over alternatives like bc_get_sales_order or bc_list_sales_invoices. No exclusions or alternative recommendations are given, leaving the agent to infer context from the tool name.

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 but only adds that listing is scoped to the working company and that search does substring matching. It does not disclose pagination behavior, default limits, or return format, but the read-only nature is reasonably implied by 'List'.

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 consists of two concise sentences with no redundant filler. The main purpose is front-loaded, and the search usage note is useful and directly actionable.

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, combined with the fully documented schema, is adequate for basic invocation of listing vendors. However, there is no output schema and no annotations, and the description does not mention default paging, response shape, or when to use bc_query for more flexible queries, leaving some gaps for a tool with four parameters.

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 for all four parameters, so the baseline is 3. The description adds only a redundant hint about search, which the schema already documents as 'Substring match on displayName', so no additional parameter semantics are provided.

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 uses the specific verb 'List' with the resource 'vendors' and scopes it to the working company, making the tool's purpose immediately clear. This distinguishes it from sibling tools like bc_list_customers and bc_list_items.

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 gives some parameter guidance ('Use `search` for a name substring match') and implies the tool is for listing vendors in the working company. However, it does not explicitly discuss when to prefer this tool over alternatives like bc_query or other list tools, nor does it state exclusions.

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

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

The description explicitly labels the tool as read-only and shows a GET pattern, which is transparent about its safe operation. However, it does not mention potential response size limits, pagination, or error behavior, though these are less critical for a read-only escape hatch.

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: it opens with the purpose, then scope, then custom API usage, then a clarifying example. Every sentence contributes meaningful information without redundancy.

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

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

Given the tool's generic nature and lack of output schema/annotations, the description covers the essential aspects: what it does, when to use it, and how to use it with concrete examples. Minor gaps exist around response format and pagination, but these are not critical for an escape hatch.

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 100%, and the description adds practical value by showing the combination of path and params with a real OData filter example, plus explaining how api_route is used for custom APIs. This goes beyond the schema alone.

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 'Read-only escape hatch: GET any Business Central API entity set or record', providing a specific verb and resource. It distinguishes itself from sibling tools by explicitly covering entities not exposed as dedicated tools and custom APIs via api_route.

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 clearly states it covers 'standard v2.0 entities not exposed as dedicated tools' and custom APIs via api_route. This implies use when no dedicated tool exists, and the example provides a concrete pattern for invoking it.

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