Server Quality Checklist

Tool Scores

• get-purchase-ordersA
  4/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral burden and does useful work: it discloses that results are the first N records, that ordering is ascending by Purchase Order number, and that `fields` changes which columns are returned. It does not discuss auth or side effects, but the read-only nature is clear from 'List' and 'Returns'.

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

  Conciseness5/5

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

  Three short sentences, each earning its place: purpose, ordering behavior, and field customization. The most important information is front-loaded and there is no filler.

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

  Completeness4/5

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

  For a simple read-only list tool with three optional parameters and a rich schema, the description covers purpose, ordering, default columns, and field selection. It does not explain the exact return shape, but 'Returns the first N' plus the schema's empty-array note is sufficient for an agent to invoke and interpret results.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3 and the description need not repeat parameter details. The description adds useful context for `fields` by stating it returns different columns, but it does not add meaning beyond the schema for `top` or `supplier`.

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

  Purpose5/5

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

  States a specific verb and resource ('List Purchase Orders from SAP S/4HANA') and even names the default return content ('including supplier and address'). The resource is clearly distinct from sibling tools like get-sales-orders and get-business-partners.

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

  Usage Guidelines3/5

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

  Usage context is implied by the resource name and origin, but the description does not explicitly say when to use this tool versus alternatives or when not to use it. The `fields` schema hint mentions list-entity-fields, but no explicit routing guidance appears in the description itself.

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

• get-business-partnersA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the burden of behavioral disclosure. It states that results are limited to the first N records, ordered ascending by Business Partner ID, and describes the default field set and how to override it via the `fields` parameter. This is strong coverage of the tool's observable behavior, though it doesn't mention response envelope or failure semantics beyond what the schema covers.

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

  Conciseness5/5

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

  Two tight sentences front-load the core behavior and default output, then direct the user to `fields` for extensions. No filler or redundant restating of the tool name.

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

  Completeness4/5

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

  The description sufficiently covers the main return behavior, ordering, and default projection. Given the simple parameter set and lack of nested objects, it is adequately complete. A small gap is the lack of any explicit statement about empty results or pagination, but those are partially handled by the `top` parameter description.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all three parameters. The description adds context for `fields` ('pass fields for anything else') and implies `top` through 'Returns the first N', but it doesn't add meaningful semantics beyond the schema for `nameContains`. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description gives a specific verb ('List') and resource ('Business Partners from SAP S/4HANA'), clarifies that it covers customers, suppliers, and organizations, and notes the ordering by Business Partner ID. This clearly differentiates it from sibling tools like get-sales-orders and get-purchase-orders.

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

  Usage Guidelines4/5

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

  The description makes the intended use clear: retrieving business partner master data. While it doesn't explicitly say 'use get-sap-data for other entities,' the resource name and sibling tool names provide enough context for an agent to select it appropriately for business partner list queries.

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

• get-sales-ordersA
  4.2/5.0
  Behavior4/5

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

  No annotations are present, so the description carries the disclosure burden. It usefully states that results come back as the first N records in ascending Sales Order number order and explains the effect of the `fields` parameter. It does not cover pagination or error behavior, but for a list operation it discloses the key non-obvious behaviors.

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

  Conciseness5/5

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

  The description is three concise sentences: the first states the core purpose, the second adds ordering and limit semantics, and the third flags column customization. Every sentence earns its place and there is no redundant restating of schema details.

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

  Completeness4/5

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

  For a read-only list tool with three optional parameters and no output schema, the description covers the resource, notable output fields, ordering, and limiting behavior. Parameter specifics are fully delegated to the schema, so nothing essential is missing for correct invocation.

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

  Parameters3/5

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

  Schema coverage is 100%, so the baseline is 3. The description adds only a brief note that `fields` changes returned columns; the schema already explains `top` and `soldToParty` thoroughly. This meets the minimum but does not go far beyond the schema.

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

  Purpose5/5

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

  The description opens with a specific verb and resource: 'List Sales Orders from SAP S/4HANA.' It also names concrete included data (net value, currency, processing status), which makes the tool's purpose unmistakable and distinguishes it from siblings like get-purchase-orders.

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

  Usage Guidelines4/5

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

  The description gives clear usage context: use this tool when you need Sales Orders from SAP S/4HANA. It does not explicitly name alternative tools or exclusion conditions, but the resource-specific language makes selection unambiguous relative to the sibling tools.

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

• get-sap-dataA
  4.6/5.0
  Behavior4/5

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

  With no annotations present, the description carries the full burden. It discloses the operation is read-only and GET-only, warns that output is raw SAP JSON including __metadata, and advises keeping $top small. This covers the main safety and payload traits an agent needs; it does not mention error behavior or pagination, but those are less critical here.

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

  Conciseness5/5

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

  Four dense, purposeful sentences with no filler. The core purpose and safety trait are front-loaded, and every sentence adds either a routing rule, a usage case, or an important behavior warning.

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

  Completeness4/5

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

  For a generic OData fetch tool with a single parameter and no output schema, this description is nearly complete: it names when to use alternatives, enumerates intended use cases, describes the return shape, and warns about response size. The only notable omissions are error handling or pagination details, which are minor for this tool's purpose.

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

  Parameters4/5

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

  The schema already documents the endpoint parameter at 100% coverage, so the baseline is 3. The description adds value by giving concrete endpoint examples and usage patterns such as A_BusinessPartner('1'), navigation properties, $expand, $count, and $metadata, which clarify what belongs in the parameter.

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

  Purpose5/5

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

  Description opens with a specific action on a concrete resource: 'Fetch data from any SAP S/4HANA OData path (read-only, GET only).' It also explicitly distances itself from sibling tools by name, so an agent can tell exactly what this generic endpoint tool is for.

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

  Usage Guidelines5/5

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

  The description gives explicit routing guidance: prefer get-business-partners, get-sales-orders, or get-purchase-orders when applicable because they return less data, and use get-sap-data for other entities, key reads, navigation, $expand, $count, and $metadata. This is a clear when-to-use vs. alternatives statement.

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

• list-entity-fieldsA
  4.6/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses the read-only, metadata-listing nature ('List the field names') and the intended sequencing ('before passing fields to get-* tools'). It does not mention return format or error behavior, but for a simple enum-limited tool this is adequate.

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

  Conciseness5/5

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

  Two sentences with no filler. The core purpose is front-loaded in the first sentence, and the second sentence adds immediate actionable usage guidance. Every word earns its place.

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

  Completeness4/5

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

  For a tool with one parameter and no output schema, the description covers what it does and when to call it. It could be more complete by stating the return shape explicitly, but the phrase 'List the field names' sufficiently conveys the output, and the sibling references orient the agent well.

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

  Parameters4/5

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

  Schema description coverage is 100% since the 'entity' parameter includes an enum and its own description. The tool description adds context beyond the schema by explaining that the parameter selects which entity's field names to retrieve for use with get-* tools, enriching the parameter's semantic role.

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

  Purpose5/5

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

  The description clearly states the tool's function with a specific verb and resource: 'List the field names available on a SAP entity.' It distinguishes itself from sibling data-retrieval tools by positioning itself as a helper for the get-* tools, so an agent immediately understands this returns metadata, not entity data.

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

  Usage Guidelines5/5

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

  Explicit usage guidance is given: 'Call this before passing `fields` to one of the get-* tools, instead of guessing field names.' This tells the agent when to invoke the tool and frames it as the alternative to guessing, which is clear direction for tool selection.

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