SAP Business One Order-to-Cash MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation2/5
Many tools overlap heavily: get_sales_analysis, get_top_*, get_sales_by_period, query_sml_view, call_service_layer, query_sql_direct, and query_hana_direct can all retrieve the same underlying sales data, and calc_reorder_point, monitor_reorder_items, and aggregate_procurement_demand all serve replenishment/ordering decisions. With 65 tools, an agent would often struggle to choose between near-equivalent read/query paths.
Naming Consistency4/5
Names mostly follow a clear snake_case verb_noun pattern: create_* for documents, get_* for reads, and calc_*/analyze_*/detect_*/forecast_* for analytics. Minor deviations break the pattern, such as run_three_way_match, check_atp, confirm_delivery_pod, generate_draft_pos vs create_purchase_order, and a mix of query_/cal_/ist_ verbs for generic access.
Tool Count1/5
65 tools is an extreme count for a server advertised as Order-to-Cash, especially since it also covers procurement, inventory, GL/finance, and direct SQL/Service Layer access. Many query/analytics tools duplicate each other and could be consolidated, so the surface is bloated rather than well-scoped.
Completeness3/5
The core quote-to-order-to-cash lifecycle (quotation, order, delivery, invoice, payment) and procure-to-pay flow are well represented, but notable operations are missing as dedicated tools: document cancellation/update, returns, and credit memo creation. Generic call_service_layer / direct SQL tools provide workarounds, so the gaps are not fatal but are still obvious.
Average 3.7/5 across 64 of 65 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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, but it does not state whether this is a read-only operation, how results are ordered beyond 'rank', whether it returns a limited list, or what the output contains. The tool name 'get' weakly implies read-only, but the description itself provides no such guarantee.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise, front-loaded sentence with no filler words. It communicates the core purpose efficiently, though the brevity contributes to the completeness gaps penalized in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a low-parameter-documentation schema, the description is insufficient on its own. An agent still needs to know how optional parameters behave (e.g., defaults, limits), what date semantics apply, and how this differs from get_ar_aging.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only asOfDate has a format hint), and the description does not explain topN, overdueMoreThanDays, or their defaults and interactions. 'Overdue receivables' only vaguely hints at overdueMoreThanDays; the agent gets no meaningful parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Rank') and identifies the resource ('overdue receivables') and the ranking criterion ('customer risk score') for collections prioritization. It is clear on what the tool does, though it does not explicitly differentiate it from similar receivables/aging tools like get_ar_aging.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for collections prioritization' implies a use case, but there is no guidance on when to use this tool versus siblings such as get_ar_aging or get_top_customers. No exclusions, prerequisites, or alternative conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only says 'uses SMLSVC POST,' which reveals transport but not whether the operation is read-only, whether it has side effects, what it returns, or any rate-limit/auth concerns. This is insufficient for an agent to understand the call's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the essential purpose. The only slightly questionable addition is 'uses SMLSVC POST,' but it does not make the description bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and no parameter guidance, this description is underspecified for confident invocation. An agent can guess that two dates are involved, but it cannot tell what granularity/aggregation, what item-group data is returned, or how this call differs from other sales-analysis tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 by explaining the date parameters, but it says nothing about toDate/fromDate, their meaning, range behavior, or optionality. The description adds no parameter semantics whatsoever.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the specific metric ('Sales performance') and the grouping dimension ('item group/category'), so an agent can tell this from sales-period or salesperson tools. It lacks an explicit verb like 'get' or 'returns', but the tool name and phrasing are clear enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 any of the many sales-analysis siblings such as get_sales_by_period, get_warehouse_sales, or get_salesperson_performance. The resource name implies a use case, but no explicit context or alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 'Uses SMLSVC POST aggregation,' which is a useful implementation detail, but does not explain whether the operation is read-only, how empty results are handled, or what behavior to expect beyond aggregation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded: the core purpose appears first, followed by the period options and a brief technical note. No filler is present, though it could trade the SMLSVC detail for more user-facing guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is under-specified. It omits return format, date-range requirements or defaults, and the scope of sales data included, so an agent cannot fully predict the tool's behavior before calling it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, with toDate and fromDate lacking descriptions. The description repeats the periodType enum but adds nothing about the meaning of the date range parameters, their requiredness, or any default behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear function: 'Sales trend by period' with explicit granularity options (day/week/month/quarter/year). It does not explicitly contrast with siblings like get_sales_analysis, but the period-based scope makes its purpose identifiable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_year_over_year or get_sales_analysis. The description implies use for period-based sales trends, but gives no context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, but it only says 'List' and gives output scope. It does not disclose whether the operation is read-only, how topN and search affect behavior, what happens when no parameters are passed, or any pagination/default limits. Basic safety is implied by 'List', but meaningful behavioral detail is absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or repetition. It front-loads the main action and resource, then adds the key returned fields. It could have been more informative without being bloated, but as written it is tight and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter list tool, some gaps are acceptable, but with no parameter documentation, no output schema, and no annotations, the description leaves critical operational details unexplained. An agent knows what comes back in broad terms but not how to control the result set or interpret the output reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention or explain 'topN' or 'search' at all. The property names give weak hints, but an agent cannot know what topN limits, how search matches, or whether parameters are optional in effect. The description must compensate for the empty schema and does not.
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 uses a specific verb ('List'), identifies the resource ('suppliers/vendors'), names the source system ('SAP B1'), and states the included fields ('balance and contact info'). This clearly distinguishes the tool from siblings like get_customer_list and vendor analytics tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, nor any exclusions. The description implies 'use when you need a vendor list with balance and contact info', but it never names sibling tools or conditions for choosing among get_vendor_list, get_customer_list, or the many vendor-related analytical tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only says 'Create', which signals mutation, but it does not disclose side effects, document status, validation rules, numbering behavior, permission requirements, or what happens after creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is concise and easy to parse, though the brevity comes at the cost of behavioral and parameter detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with 6 parameters, no output schema, and no annotations, so one sentence is not enough for an agent to invoke it correctly. The description omits return behavior, meanings of optional fields, and any caveats around dates, pricing, or warehouse codes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, so the description must compensate for the missing parameter documentation. It names 'customer and line-item inputs', which roughly maps to cardCode and lines, but it does not explain optional parameters like docDate, comments, docDueDate, or discountThresholdPct, leaving the agent without sufficient semantic information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the specific resource 'SAP Business One sales quotation', and it mentions the core inputs: customer and line-item inputs. It does not explicitly distinguish this tool from sibling tools like create_sales_order or create_purchase_quotation, but the resource is specific enough to be understandable.
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?
The description implies the tool is used when creating a sales quotation from customer and line-item data, but it gives no explicit guidance on when to prefer this tool over alternatives such as create_sales_order or create_purchase_quotation. There are no stated prerequisites, exclusions, or follow-up recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 'uses SMLSVC POST' but does not clarify whether this is a read-only operation or if it has side effects, and the POST reference could even be misleading. It also does not disclose return behavior, required permissions, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise: two short sentences with the primary purpose front-loaded. However, the phrase 'uses SMLSVC POST' is an implementation detail that adds little operational value for an agent, slightly weakening the justification for every sentence earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and only a minimal description, this is incomplete. It fails to explain parameter semantics, the nature of the returned data, whether the operation is safe, or what 'GP' means. An agent would need additional inference or external knowledge to invoke and interpret the result correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description makes no mention of the two parameters, fromDate and toDate, or their roles in filtering the sales performance data. With no compensation in the description, an agent cannot understand what date range to supply or whether the parameters are optional.
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 'Sales and GP by sales employee' and further specifies 'Groups by SalesEmployeeOrBuyerNumber,' which names the metric and the grouping dimension. This differentiates it from sibling tools like get_sales_by_period or get_warehouse_sales, which use different grouping dimensions.
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?
The intended usage is implied by the phrase 'Sales and GP by sales employee' — an agent can infer this is for retrieving employee-level sales data. However, there is no explicit guidance about when to use this tool versus alternatives such as get_sales_by_period or get_sales_analysis, and no mention of exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. It states it calculates and tiers but does not disclose whether it is read-only, what outputs are returned, how missing data is handled, or any performance constraints. The behavior is stated but not elaborated.
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?
A single, information-dense sentence that includes the formula and tier names. Every word serves a purpose, and the core definition is front-loaded with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the calculation logic and tier names, which helps an agent decide to call it. However, without an output schema or annotations, it omits the output structure (e.g., whether it returns a table or summary) and does not clarify scope (e.g., whether it covers all customers). These gaps are moderate for a two-parameter analytical tool with no output schema.
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% and both parameters have descriptive text with defaults, so the schema already provides adequate meaning. The description's formula references the parameters implicitly, reinforcing their role, but adds no new syntax or format details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Calculate' and names the resource 'Customer Lifetime Value' along with a clear formula and tiering scheme. It distinguishes itself from generic analytics tools by specifying the exact calculation, though it doesn't name a sibling to contrast with.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no mention of when to use this tool versus alternatives like segment_customers_rfm or detect_customer_churn. Given the many overlapping analysis tools, the absence of any usage direction or exclusions leaves the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It only states that proof-of-delivery information is appended, but does not say whether repeated calls overwrite or add additional POD data, what happens when the delivery note does not exist, whether document status changes, or what side effects occur.
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 a single, front-loaded sentence with no filler. Every word contributes to stating the action and the target resource, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with three parameters, no annotations, and no output schema, the description is too thin. It does not explain how to identify the delivery note via deliveryDocEntry, what podReference should contain, what exceptions represents, or what the call returns or changes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 does not explain deliveryDocEntry, podReference, or exceptions. The phrase 'proof-of-delivery information' hints that podReference is the POD reference, but no formats, meanings, or relationships between parameters are provided.
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 uses a specific verb and resource: 'Append proof-of-delivery information to a delivery note.' This clearly indicates a modification of an existing delivery note, and the word 'append' distinguishes it from sibling tools like create_delivery that create new documents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool instead of alternatives, nor any exclusions such as 'do not use for creating delivery notes.' The only implied usage is that a delivery note already exists, but prerequisites and relationship to other delivery-related tools are not explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries a heavier burden but only reveals two implementation details: it uses SMLSVC POST ParamList and aggregates by BusinessPartnerCode. It does not disclose whether the operation is read-only, what output shape to expect, or any side effects or assumptions, which is a significant gap for a tool with no structured safety metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. The phrase 'uses SMLSVC POST ParamList' adds some jaron and is not essential, but the overall length is appropriate and every other sentence contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description has notable gaps: it does not explain what the response contains, whether it is sorted, or how it relates to alternative revenue analytics tools. The parameters are documented, but the description alone is insufficient for a agent to fully predict the tool's behavior.
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%: topN, fromDate, and toDate are all described with defaults. The description adds no meaning beyond the schema, so the baseline of 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 clearly identifies the resource ('top customers'), the metric ('net sales'), and the aggregation key ('BusinessPartnerCode'). It distinguishes this from sibling tools like get_customer_list or get_top_items by focusing specifically on net-sales ranking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as get_top_items, get_customer_list, or get_sales_by_period. There is no explicit or implicit exclusion or comparison with sibling tools, leaving the agent to rely on 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only states the creation intent and does not mention whether the PO is posted or draft, whether an existing vendor/cardCode is required, what side effects occur, or what the response contains. For a mutation tool, this is a significant transparency gap.
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 a single, front-loaded sentence that conveys the action, system, and core entities without redundant content. Every word adds signal, and there is no wasted phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is operationally incomplete. An agent cannot tell what result to expect, whether the document is saved as draft or posted, or what practical constraints apply beyond the required schema fields. The definition leaves too much unstated for reliable invocation in an ERP context.
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?
The description adds some parameter context by mapping 'vendor' to cardCode and 'line items' to lines. However, it provides no semantic detail for docDate, unitPrice, taxCode, warehouseCode, or itemCode, and schema description coverage is only 60%, so the description does not fully compensate for the schema's gaps.
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 uses a specific verb ('Create') and names the exact resource ('SAP Business One purchase order for a vendor with line items'). This clearly distinguishes it from sibling tools like create_purchase_request, create_purchase_quotation, and create_sales_order, because 'purchase order' plus 'vendor' is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 create_purchase_request, create_purchase_quotation, create_po_from_quotation, or create_goods_receipt_po. There is no when/when-not context or mention of alternatives, so the agent must infer the correct use case from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses that the tool 'uses SMLSVC POST', but does not state whether this is a read-only operation, whether special permissions are required, or what the response shape looks like. For a tool with no safety annotations, this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core purpose. The trailing 'uses SMLSVC POST' clause is somewhat opaque and arguably not essential, but it does not bloat the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, the parameters are fully documented, and the purpose is clear. However, with no output schema and no behavioral annotations, the description leaves the return format and operational behavior partially to inference. It is adequate but not complete.
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 input schema already documents both parameters and their defaults. The description adds no new parameter meaning beyond indicating that the two years are compared, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Compare') and resource ('total sales and GP between two years side-by-side'), which makes the tool's purpose immediately understandable. It does not explicitly name a sibling tool for differentiation, but the year-over-year comparison scope is distinctive enough among the listed sales tools like get_sales_by_period.
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?
The use case is implied: use this when comparing total sales and gross profit across two years. However, there is no explicit guidance about when to prefer this over similar analytics siblings, no mention of prerequisites, and the 'uses SMLSVC POST' note is more implementation detail than usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full disclosure burden. It reveals the tool creates an A/R invoice, but gives no information about side effects (e.g., posting to accounting, document status changes), prerequisites, or reversible behavior. For a mutation tool, this is a meaningful gap.
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?
A single sentence with no filler, front-loading the verb and object. Every word carries meaning and there is no wasted content, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and only 33% parameter documentation, the description is too sparse. It omits return values, error conditions, prerequisites, and behavioral details necessary for an agent to invoke the tool correctly in a real workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, with only docDate having a format hint. The description does not explain that deliveryDocEntry identifies the source delivery document or what dueInDays controls, although 'from a delivery document' hints at deliveryDocEntry. This partial hint is insufficient for the low coverage.
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 ('Generate'), resource ('A/R invoice'), and source ('delivery document'), making the tool's function immediately clear. The explicit 'A/R' distinguishes it from create_ap_invoice and other document-creation siblings without needing to inspect schemas.
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?
The use case is implied: generate a customer invoice from an existing delivery document. However, there is no explicit guidance on when to prefer this tool over alternatives, no exclusions, and no mention of prerequisites such as delivery confirmation. The context is clear enough to infer, but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosure. It adds genuine scope information ('open' invoices only, grouped 'by overdue days'), but it does not explicitly state that this is a read-only, side-effect-free report, and it does not disclose what the bucketed result actually contains (amounts, per-vendor, period ranges).
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?
One compact front-loaded sentence with zero waste. 'AP aging report' leads, followed by the scope (open purchase invoices) and the grouping key (overdue days); every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Because there is no output schema and no annotations, the description should convey more about return shape and safety. It states the domain and grouping but not the bucketing convention, the contents of the output, or that the call is non-destructive. Adequate for a one-optional-parameter read report, but with clear gaps.
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%: the single parameter asOfDate is fully documented with format (YYYY-MM-DD) and default (today). The description adds nothing about the parameter beyond the implied notion that aging is computed relative to a date, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource (open purchase invoices) and behavior (bucketing by overdue days), anchored by the clear noun phrase 'AP aging report'. It implicitly separates itself from the sibling get_ar_aging through 'purchase invoices', but does not explicitly name that alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this tool over the 60+ siblings. No when/when-not conditions, no exclusions, and no mention of alternatives such as get_ar_aging or get_purchase_analysis; the only routing signal is the tool name itself, which the agent already possesses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses that the tool returns lines and that results are sorted by bin location, which is useful. It does not explicitly state whether the operation is read-only, what happens when no pick list exists, or whether any authorization or side effects are involved, but 'Return' suggests a read operation.
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 a single compact sentence that front-loads the action and object. Every word earns its place, and the sort behavior is included without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read tool, the description covers the core purpose and a useful behavioral detail. However, with no annotations and no output schema, it leaves the parameter semantics and the decision between this tool and related siblings under-specified, so the definition is only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and one required numeric parameter, salesOrderDocEntry. The description only refers to 'a sales order,' which maps loosely to the parameter but adds no meaningful detail about the expected identifier format, whether it is the internal document entry key, or any constraints. With no schema descriptions available, this leaves the parameter under-explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Return pick list lines for a sales order, sorted by bin location.' It is specific and easy to understand. However, it does not explicitly distinguish itself from sibling tools or clarify that it returns line-level details rather than order headers.
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?
The intended use is implied: when you need pick list lines for a given sales order. There is no explicit guidance about when to choose this tool over alternatives or when not to use it, but the resource and context are clear enough to infer the primary use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no output schema, the description carries the behavioral burden. It clearly implies a read-only analytical query and names the underlying HANA view plus grouping/filtering behavior. However, it doesn't disclose result shape, pagination/limits, default date-range behavior, or access requirements.
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 sentences with no filler: the first states operation and resource, the second summarizes the docType filter, and the third gives an actionable example. The content is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter analytical tool with no output schema, no annotations, and many siblings, this description is minimally viable but not complete. It lacks return-value shape, default date/period handling, and explicit differentiation from the spezialized sales-analysis siblings.
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 only 63%, and the description mostly repeats the groupBy field codes and docType values already present in the schema. It does add useful extra grouping dimensions (salesperson, warehause, period) and one concrete example, but it leaves topN, cardCode, and itemCode unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific verb ('Query'), a specific resource ('SAP HANA Sales Analysis via sml.svc'), and distinctive capabilities (group by customer/item/salesperson/brand and filter by doc type). It moves clearly beyond the tool name and gives an agent enough to distinguish it from generic query tools and specialized sales-report siblings, even though it doesn't explicitly name those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It supplies one concrete usage rule ('Use groupBy='CogsOcrCod' for brand-wise analysis') and mentions docType filtering, but with a large sibling set it never states when to prefer this tool over get_sales_by_period, get_top_customers, get_item_group_sales, or query_sml_view. The routing decision is largely left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It does reveal that the tool uses SMLSVC POST and aggregates by ItemCode, which is useful context, but it does not state whether the call is read-only, what the response shape is, or whether there are side effects or limits.
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 a single focused sentence, front-loaded with the core behavior and followed by the aggregation detail. Every phrase earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list-style tool, the description plus schema is mostly usable, but the lack of annotations and output schema means an agent still has to guess at the return shape and exact date-range semantics. It would also benefit from routing guidance among the many sales-report siblings.
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?
The schema already documents topN's default and sortBy's candidate values, and the description adds some human-readable meaning by referring to 'sales amount or quantity'. However, fromDate and toDate receive no semantic explanation beyond their format, so the 50% schema coverage gap is not compensated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning top-selling items ranked by sales amount or quantity, and it adds the useful aggregation detail 'by ItemCode'. It does not explicitly contrast this with sibling tools like get_top_customers or get_sales_by_period, but the item-level sales focus is clear enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus the many sibling sales-analysis tools, and no exclusions or alternative tool names are mentioned. The intended usage is only implied by the phrase 'Top selling items'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 does disclose the read-only nature ('Retrieve') and the four quantity categories returned, but it omits operational traits such as result-set size when topN is omitted (returning ALL items), pagination, data freshness, or whether values are aggregated across warehouses. These gaps are mitigated by the tool being a simple, clearly read-oriented list operation.
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?
A single, efficient sentence front-loads the verb and resource, then compactly enumerates the output categories. Every element earns its place and nothing repeats the schema's parameter documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple filtered-list tool with all parameters fully documented in the schema, so the baseline burden is modest. However, with no annotations and no output schema, the description should clarify the return format and the scale implication of omitting topN ('return ALL items' per the schema hint), as well as warehouse aggregation semantics. Adequate, but with identifiable gaps.
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% — all three parameters (topN, search, inStockOnly) are already documented in the schema, so the baseline of 3 applies. The tool description adds no parameter-level meaning; the useful 'recommended' hint on topN lives in the schema, not the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve') with a clear resource ('total stock levels for all inventory items in SAP B1') and enumerates the returned quantity categories (on-stock, committed, on-order, available). The 'all inventory items' scope distinguishes it from item-specific siblings like check_atp, though it does not explicitly name any alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus siblings such as check_atp, monitor_reorder_items, or get_open_orders. There are no exclusions, prerequisites, or selection criteria stated — usage context is only weakly implied by the described purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the transparency burden. 'Return' signals a read-only operation, and the description names the returned information. However, it does not disclose behavior when no active company is available, any authentication/connection requirements, or the exact meaning of 'server info.'
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 a single concise sentence with no filler. The core purpose is front-loaded and every word adds meaningful detail about the returned company-related information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool, the description is minimally viable: it lists the main output categories and implies the current/active context. However, without an output schema, more detail about 'server info' and explicit usage context would make the tool fully unambiguous.
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 tool has zero parameters and the schema already reflects that completely. With a 0-parameter baseline, the description does not need to document parameters and appropriately focuses on what information the tool returns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Return') and a specific resource ('active SAP B1 company database name, namespace, and server info'), so an agent can identify what the tool provides. It is distinguishable from most sibling get_* tools because none of them target company database/server info, though it does not explicitly contrast with switch_company.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to use this tool versus alternatives. It only implies that the 'active' company is the current context, but it does not state when to call this, what prerequisites exist, or that a sibling like switch_company should be used for changing the active company.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full behavioral disclosure burden. It states the tool lists open orders but does not disclose topN semantics, ordering, pagination, what 'open' means, or whether the operation is a safe read. This leaves material behavior undocumented.
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?
One sentence with no filler. The action, resource, and optional filter are front-loaded, making it easy to skim and immediately actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation, the description is minimally viable but not complete. Missing topN semantics and any description of return behavior; without an output schema, the agent has to assume reasonable defaults for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description only explains 'cardCode' as a customer filter. The 'topN' parameter is entirely unexplained in both schema and description, so an agent cannot know its meaning or constraints without external knowledge.
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 a specific verb ('List'), a precise resource ('open sales orders from SAP B1'), and an optional filter ('by customer'). This distinguishes it from sibling tools like create_sales_order and get_open_quotations without requiring schema inspection.
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 is implied: use when you need open sales orders, optionally for a customer. However, no explicit when-to-use guidance or contrast with alternatives is provided, so an agent must infer the tool's role from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the behavioral burden. It discloses a meaningful non-obvious behavior: the amount is distributed proportionally across open invoice balances. However, it does not describe side effects such as whether the payment is fully posted, how overpayments or underpayments are handled, or whether the operation is reversible.
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 two sentences with no filler. The primary action and the proportional-distribution behavior are front-loaded, so an agent can immediately understand the tool's core function without parsing unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a financial mutation tool with no annotations, no output schema, and eight parameters, this description is too incomplete. It lacks prerequisites, guidance on which accounts to use, and the post-application financial effects, so an agent would need to guess at significant business context before invoking it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 13%, with only 'docDate' described, and the description barely compensates for the other parameters. It connects 'amount' to the payment and 'invoiceDocEntries' to invoices, but it leaves 'cardCode', 'cashAccount', 'transferAccount', and 'transferReference' unexplained, making it hard for an agent to populate most parameters confidently.
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 uses a specific verb, 'Apply', with a clear resource: an incoming payment against one or more invoices, and it adds the business goal of reconciling A/R. This clearly differentiates it from the sibling 'apply_outgoing_payment' by payment direction.
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?
The description implies this is for incoming payments and A/R reconciliation, but it never explicitly says when to use this tool versus alternatives like 'apply_outgoing_payment' or 'create_ar_invoice'. The usage context is inferable but not directly stated, and there are no exclusion criteria or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 one important behavior—proportional distribution across open invoice balances—but says nothing about whether the action is irreversible, posts to ledgers, requires approvals, or how partial or excess payments are handled. For a financial mutation tool, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, and the most important operation and allocation behavior are front-loaded. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter financial action with no output schema and no annotations, the description lacks essential context such as the meaning of account fields, required prerequisites, return behavior, and side effects. An agent would have to infer too much to invoke this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 38%, and the description adds little parameter-level meaning. It mentions 'amount' and 'open invoice balances,' but does not explain key parameters like cashAccount, transferAccount, or transferReference, leaving the caller to guess their roles.
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 uses a specific verb ('apply') and a precise resource ('outgoing payment to one or more A/P invoices') and adds the outcome of reconciling vendor payables. The focus on outgoing payments and A/P invoices clearly differentiates it from sibling tools like apply_incoming_payment and the various create_* tools.
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 clearly implies this tool is for applying outgoing payments to vendor invoices, which is a distinct context among the siblings. It does not explicitly name alternatives or exclusion criteria, so it falls short of a 5, but the intended use case is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 does disclose one meaningful behavioral trait beyond the schema: omitting warehouseCode aggregates totals across all warehouses. However, it does not disclose what the response contains, whether partial shortfalls are reported, or confirm this is a non-mutating read.
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 zero waste: the first states the verb and resource, the second front-loads the parameter nuance. Every word earns its place and the key behavioral caveat is placed inline where the agent will read it first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple single-parameter tool with no output schema and no annotations, so the description is the only source of runtime behavior. It adequately explains the core call semantics but leaves gaps: no indication of return shape, no error behavior for unknown items or insufficient ATP, and no differentiation from get_total_stock, which sits adjacent in the sibling list.
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 0%, so the description must compensate for documented parameters. It adds real meaning for warehouseCode by explaining its optionality and aggregation effect, but it says nothing about itemCode or requiredQty semantics, leaving the core of the items array to be inferred from names and types alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and a precise resource ('available-to-promise stock'), expanding the abbreviated tool name and clarifying it is an ATP lookup rather than a generic stock query. The concept of available-to-promise implicitly separates it from the sibling get_total_stock, though it never names an alternative explicitly.
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?
The description gives clear operational guidance on the warehouseCode parameter and what happens when it is omitted, which is useful call-time context. However, it provides no guidance on when to choose this tool over similar inventory siblings like get_total_stock or predict_stockout, leaving tool-selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It says this is a create/write operation and mentions attaching carrier references in comments, but it does not explain effects on the sales order, reversibility, required permissions, or failure behavior.
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 a single sentence with no filler. It front-loads the core action and adds only meaningful detail about the source and side effect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no annotations, no output schema, and low schema coverage, the description is too thin. It omits any guidance on return values, expected behavior when the sales order is not open, and how optional parameters affect the resulting delivery note.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, so the description should compensate for the undocumented parameters. It loosely maps 'carrier references' to carrierName and trackingNumber, but it never clarifies salesOrderDocEntry as an internal identifier or explains how scheduledDate relates to the delivery note.
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 states a specific verb ('Create'), a distinct resource ('delivery note'), and the source ('open sales order'). It also adds the side action of attaching carrier references in comments, which makes it clearly distinguishable from sibling tools like create_sales_order or confirm_delivery_pod.
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 context by specifying the prerequisite that the sales order must be open. It does not explicitly name alternatives or state when not to use this tool, but the intended usage is evident from the domain and the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses the two creation paths and implies data copying behavior when purchaseRequestDocEntry is provided, which adds value. However, it does not explain side effects, success/failure behavior, authorization needs, or what happens if both lines and purchaseRequestDocEntry are supplied.
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 two sentences, front-loads the core purpose, and each sentence earns its place. There is no redundant or filler wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 the two creation modes, and the schema fills in parameter details. However, with no output schema and no usage-vs-sibling guidance, an agent is left without important context about expected return values, edge cases, or when this tool is the appropriate choice.
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 83%, so the schema already explains most parameters. The description reinforces the relationship between lines and purchaseRequestDocEntry, but it does not add meaningful parameter-level meaning beyond what is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Create') and resource ('purchase quotation (RFQ) for a vendor'), and the two primary creation modes are explicitly outlined. It is distinct from siblings like create_purchase_order or create_purchase_request, though it does not explicitly name a differentiating alternative.
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?
The description provides internal usage guidance: create from scratch with line items or copy from an existing purchase request using purchaseRequestDocEntry. However, it does not state when to choose this tool over its siblings, nor does it mention any exclusions or prerequisites beyond the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It implies a read-only operation via 'Retrieve', but it does not disclose ordering, pagination behavior, output field set, or what happens when no filters are applied. It is not misleading, but it leaves room for more transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loaded with the main purpose and followed by the key capabilities. It is appropriately compact, though it could add sibling differentiation without much cost.
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 straightforward read-only list tool with a fully documented schema, the description is mostly sufficient: it names the resource, source, and available filters. There is no output schema, so some return-shape detail is missing, but the core information an agent needs to select and invoke the tool is present.
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?
The input schema has 100% description coverage: topN, search, and activeOnly are all individually documented, including defaults and matching semantics. The description's mention of filtering by name/code search, active status, and result count adds no new semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Retrieve'), resource ('a list of customers (business partners)'), and source system ('SAP B1'). It differentiates from get_customer_details and get_top_customers by being a list operation with filtering, but it does not explicitly name sibling alternatives.
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?
The description implies when to use it: when you need a filtered customer list from SAP B1. It does not provide explicit when-not-to-use guidance or mention alternatives like get_customer_details for single-record lookups or get_top_customers for rank-based selection, leaving some routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It adds some value by revealing it uses SMLSVC POST and groups by WarehouseCode, but it does not state whether the operation is read-only, what output shape to expect, or how the date parameters affect results.
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 compact and front-loads the core purpose. Both sentences earn their place, and there is no redundant or generic filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity, there is no output schema and no annotation coverage. The description omits return-value details, date-range semantics, and any caveats about the SMLSVC POST call, leaving an agent without sufficient context to confidently invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention toDate or fromDate at all. The parameter names and date format are somewhat self-explanatory, but the description fails to compensate for the lack of schema descriptions or clarify date-range behavior.
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 resource and operation: 'Sales breakdown by warehouse' and 'Groups by WarehouseCode.' This clearly differentiates it from sibling sales tools like get_sales_by_period or get_item_group_sales on the basis of grouping dimension.
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?
The description implies usage: an agent should call this when warehouse-level sales breakdown is requested. However, it does not explicitly name alternative tools or conditions for avoiding it, so the routing guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 does this well by revealing the matching heuristic ('closest Purchase Order due date') and the outputs computed. It does not explicitly state that the tool is read-only or describe data prerequisites, but the analytical nature and detail are sufficient for a low-risk analysis tool.
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 two focused sentences with no wasted words. The first sentence states the domain, and the second provides the methodology and outputs. It is well front-loaded and easy to scan.
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?
Given the tool's low complexity, a single documented parameter, and no output schema, the description is largely complete: it states the analysis method, grouping, and calculated metrics. It could be more explicit about the return format, but it provides enough for an agent to invoke the tool and interpret the likely result.
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?
The schema already documents the only parameter, months, with its default and maximum value, so the description need not add parameter details. There is no extra semantic value about how months affects the analysis, but 100% schema coverage makes this acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (vendor on-time delivery) and explains the exact method: matching Goods Receipt POs to the closest Purchase Order due date and computing on-time%, early/late counts, and average delay days per vendor. This distinguishes it from sibling tools like analyze_vendor_lead_time or analyze_vendor_concentration, though it does not explicitly name an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for assessing vendor delivery punctuality, but it gives no explicit when-to-use guidance, prerequisites, or contrast with related analysis tools. An agent must infer the appropriate context rather than being told when this tool is preferred over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 explains the formula and the calculation outputs, but it does not explicitly state that this is a read-only analytical operation with no side effects, which matters given the many create_* and apply_* siblings.
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 compact, front-loaded with the core formula, and every sentence serves a purpose: defining the calculation, its variables, and its outputs. There is no filler or repetition.
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 tool has only four optional parameters, all documented in the schema, and the description covers the formula and return values. It lacks an explicit statement about data sources or when to prefer this over similar tools, but for a calculation tool this is mostly complete.
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% with each parameter already described, so the baseline is 3. The description adds useful formula-level context by mapping holdingRate to H and orderingCost to S, but it does not add meaning beyond the schema for topN or demandMonths.
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 names the exact calculation ('Economic Order Quantity'), provides the formula, defines each variable, and states what it returns ('optimal order quantities and expected orders per year'). This clearly distinguishes it from related inventory tools like calc_reorder_point or predict_stockout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as calc_reorder_point or monitor_reorder_items. The formula implies inventory optimization, but no explicit context, exclusions, or sibling comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 states it pulls open AR, AP, sales, and inventory from SAP B1, indicating a read operation, but it does not describe the output format, potential side effects, or whether any state changes occur. It adds context about the data source but omits return details, so it's only partially transparent.
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 two efficient sentences: the first lists the computed metrics and their formula, the second names the data source. It is front-loaded with the core purpose, avoids fluff, and every sentence adds value. Length is appropriate for a simple calculation tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description could be more explicit about what is returned (e.g., a record of DSO, DPO, DSI, CCC values). It states the metrics but not the return structure. Given the simplicity and the schema explaining periodDays, this is a noticeable but minor gap. Overall, it is adequate but missing a clear declaration of the output.
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%: the periodDays parameter is already described in the schema with meaning and default. The description does not add any additional semantic detail about periodDays or its interaction with the metrics, so it relies entirely on the schema. This meets the baseline for a fully documented 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 clearly states a specific task: calculating working capital efficiency metrics (DSO, DPO, DSI, CCC) from SAP B1 data. The verb 'pulls' and the resource 'SAP B1' make the purpose unmistakable. It is distinct from siblings like forecast_cash_flow or analyze_vendor_lead_time, which target different financial areas.
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?
The description implies usage context—when working capital efficiency metrics are needed—but does not explicitly state when to use it vs. alternatives, nor does it mention any exclusions or prerequisites. The context is clear that it's a calculation tool, but there is no explicit guidance on when to prefer it over other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 indicates that an AP invoice is created, but it does not disclose whether the invoice is posted, whether it validates the GRPO state, whether duplicates are prevented, what side effects occur in accounting, or whether the action is reversible. For a mutation tool, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that names the action, the source document, and the purpose in order of importance. Every phrase earns its place and there is no extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a moderate-complexity creation action with complete parameter schema coverage, but no output schema or annotations. The description gives enough to invoke it with grpoDocEntry, but it does not explain what the caller should expect in return, what happens if the GRPO is already fully invoiced, or any posting/approval behavior. Some of these gaps are acceptable for a simple creation tool, but at least one statement about side effects or output would make it more complete.
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; the schema already explains grpoDocEntry, docDate, and dueInDays. The description adds the conceptual link that grpoDocEntry refers to the source GRPO, which helps map the parameter to the workflow, but it does not add detail 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 states a specific action ('Generate an A/P invoice'), the source resource ('Goods Receipt PO (GRPO)'), and the business purpose ('record the vendor payable'). This clearly differentiates it from siblings like create_ar_invoice, which is for customer receivables rather than vendor payables.
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 phrase 'from a Goods Receipt PO (GRPO)' clearly signals when this tool should be used: after a goods receipt exists and the vendor payable needs to be recorded. It implies the workflow stage and distinguishes it from earlier procurement steps like create_purchase_order or create_goods_receipt_po, though it does not explicitly name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of explaining behavior. It conveys that the tool is a non-mutating aggregation/read operation, which is useful. But it does not disclose how 'top suppliers' is determined (by total amount, invoice count, etc.), whether dates are inclusive, or what the output shape is.
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 a single, front-loaded sentence with no filler. Every word contributes meaning: action, resource, grouping, filter, and purpose. This is an ideal length for a tool definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple and has only three optional parameters, and the description covers the core idea. But with no output schema and no annotations, the description still leaves ambiguity around the ranking metric and return format, so it is adequate for selection but not fully complete for reliable 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 0%, so the description must compensate. It does partially: 'date range' maps to fromDate/toDate and 'top suppliers' maps to topN. However, it doesn't clarify defaults, date inclusivity, or whether topN limits the number of suppliers or the number of invoices.
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 says exactly what the tool does: 'Aggregate purchase invoices by vendor for a date range to show top suppliers.' It names a specific action (aggregate), resource (purchase invoices), grouping dimension (vendor), filter (date range), and output intent (top suppliers). This clearly separates it from sales-side siblings like get_sales_analysis and get_top_customers.
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?
The intended use is implied: call this when you need a supplier ranking from purchase invoices over a date range. However, there is no explicit guidance about when not to use it or which sibling tool might be a better fit, such as analyze_vendor_concentration or get_ap_aging.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior. It does so unusually well, listing the actual algorithm steps: additive decomposition, ACF to lag 24, seasonal strength score, peak/trough months, dominant cycle period, and model recommendation. It does not discuss edge cases or minimum data requirements, but the core behavioral contract is transparent.
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 two sentences with no filler. It front-loads the primary purpose, then compactly lists the analytical outputs and the supported inputs. Every clause contributes either to what the tool does or what it can be applied to.
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?
Given the absence of an output schema, the description does a good job listing what the agent can expect: decomposition components, ACF, Fs, peak/trough months, dominant cycle, and a model recommendation. It is less explicit about minimum history requirements, result formatting, and how to interpret the recommendation, but it is sufficient for an agent to select and invoke the tool correctly in most situations.
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?
The input schema already provides full descriptions for all four parameters, including defaults and allowed values, so the baseline is 3. The description restates that it works on revenue, quantity, or gross profit and can be filtered by customer or item, but adds little semantic value beyond the schema. historyMonths is not elaborated in the description, though the schema documents it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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: 'Analyse a historical monthly time series for seasonal patterns.' It clearly identifies the analytical task and lists concrete outputs, making the tool's purpose unmistakable. It does not explicitly name or contrast sibling tools like forecast_sales, but the content is specific enough to distinguish it from forecasting and sales aggregation tools.
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?
There is no explicit 'when to use this vs. alternatives' guidance, but the phrase 'recommends which forecast model to use' implies this is a precursor to forecasting. The description also states valid measures and optional filters, giving practical context. However, it never says 'use this instead of forecast_sales' or 'use this before forecasting,' leaving the routing decision partly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the behavioral burden. 'List' implies a read-only operation, but the description does not mention pagination, default limits, result ordering, or any data-freshness caveats. It adds some useful behavioral context with the optional customer filter, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the action and resource, adds the key filtering option, and contains no filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with only two optional parameters and no output schema, but the description still leaves topN semantics and the expected return shape undefined. It is adequate for a basic list operation, but not fully complete without those details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 correctly explains that cardCode filters by customer, but it gives no meaning to topN beyond the property name; a number called 'topN' is not enough to know whether it limits rows, controls sort order, or applies some other behavior.
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 uses a specific verb ('List'), a clear resource ('open sales quotations from SAP B1'), and notes an optional customer filter. This clearly distinguishes it from siblings like create_sales_quotation (creation) and get_open_orders (orders, not quotations).
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 primary use case explicit: retrieving open sales quotations, optionally narrowed by customer. It provides clear context for when to call it, though it does not 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.
Behavior4/5
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 clearly explains that customers are scored 1-5 on recency, frequency, and monetary value, and then classified into named segments. It doesn't mention side effects, but this is clearly an analytical, read-only operation and the scoring behavior is well disclosed.
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 consists of one tight sentence that front-loads the tool's purpose ('RFM customer segmentation') and then packs in highly specific details: the 1-5 scoring scale, the RFM dimensions, and the full list of segment classifications. There is no filler or redundancy.
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 one-parameter analytical tool with no output schema, the description is largely complete. It explains the methodology, scoring scale, and result categories. The main gap is that it doesn't describe the exact return structure or how lookbackDays influences the segmentation, but the schema covers the parameter and the core behavior is clear.
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?
The single parameter lookbackDays is fully described in the input schema with its default and maximum values, so schema coverage is 100%. The tool description adds no additional parameter-level detail beyond the schema, which is covered by the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: RFM-based customer segmentation, with a specific verb ('scores') and resource ('customers'), plus the scoring scale and segment names. It is distinguishable from siblings by its RFM focus, but it does not explicitly name or contrast any alternative tools.
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?
The description implies when to use the tool: when RFM segmentation is needed. However, it gives no explicit guidance on when to choose this over similar analytics siblings like detect_customer_churn, calc_customer_clv, or analyze_abc_xyz, and it mentions no exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 reveals OData usage and status value mappings, but it does not disclose that this is an unvalidated, low-level REST escape hatch capable of arbitrary mutations (POST/PATCH/DELETE) with potentially irreversible effects. Given its power and breadth, this lack of caution is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but each section earns its place: purpose front-loaded, followed by representative examples, common parameters, and status codes. The formatting is scannable and avoids filler. Slightly more compact could be possible, but the breadth of a generic tool justifies the length.
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 REST call tool with no output schema and no annotations, the description covers invocation essentials: method, endpoint, params, and examples. It lacks guidance on response handling and error behavior, but these vary per endpoint, so the examples and OData hints are reasonably complete for the tool's generic role.
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%, so the baseline is 3. The description adds value beyond the schema by showing concrete endpoint examples with realistic $filter expressions and mapping DocumentStatus and CardType values to their meanings. This helps an agent construct valid param values without needing domain knowledge.
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 ('REST call') and a clear resource ('SAP B1 Service Layer'). Explicitly frames itself as a generic fallback for 'ANY endpoint not covered by other tools', which distinguishes it from the many specialized sibling tools like create_sales_order or get_ar_aging.
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?
Gives an explicit usage rule: 'Use this for ANY endpoint not covered by other tools.' This tells the agent when to select this tool. It does not explicitly name a sibling alternative, but the condition is clear and the siblings are specialized. Could be stronger with explicit 'do not use for...' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the core classification logic: how average order interval and churnThreshold produce medium/high risk labels. It does not, however, disclose the output form (e.g., returns flagged customer list?) or any data prerequisites/side effects. Since the tool is clearly analytical, the missing output semantics are the main transparency gap.
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 sentences with no waste: purpose, mechanism, application. The most decision-relevant information (purpose + logic) comes first. Front-loaded and appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only analytic tool with two fully documented optional parameters and no output schema, the description is close to sufficient but stops short: it never states what the tool returns (e.g., a list of at-risk customers, risk levels). It also lacks any note on prerequisites such as requiring order-history data. Still minimum viable for safe 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?
The schema already describes both parameters (lookbackDays: 'History window for purchase pattern learning'; churnThreshold: 'Days of silence = high churn risk'), so baseline is 3. The description adds that churnThreshold gates high risk and lookbackDays bounds interval computation, but not much beyond the scheaa.
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?
Opens with a direct verb-resource statement: 'Predict customer churn risk.' It then specifies the exact mechanism (average order interval, overdue→medium, ≥churnThreshold→high), distinguishing it from siblings like calc_customer_clv and segment_customers_rfm. This is specific enough for an agent to know what it does and how.
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?
States a concrete use context: 'Helps target re-engagement campaigns.' It does not name any alternatives or specify when not to use it, so the agent must infer selection from the purpose rather than explicit routing. The context is clear, but there are no exclusions/alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It clearly signals a read-only reporting operation and defines the output categories (Current, 1-30, 31-60, 61-90, 90+), which is strong context. It does not explicitly state side-effect-free behavior, but the report wording makes that evident.
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?
A single, front-loaded sentence that identifies the report, the underlying data, and the exact buckets. Every element carries meaning and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one optional parameter covered fully by the schema, and the description explains what the report contains and how the buckets are structured. For a simple read-only report, nothing essential is missing.
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 asOfDate's format and default. The description adds no additional parameter meaning, matching the baseline for high schema coverage.
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 states a specific resource (open AR invoices) and a specific action (bucketing by overdue days). The AR vs AP wording clearly distinguishes it from get_ap_aging and other report tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like get_ap_aging or get_collections_worklist. The intended context is clear from the name, but the description never states exclusions or alternative conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It clearly implies a read-only analytical operation through verbs like aggregate, group, cross-reference, and compute, but it does not explicitly state that no data is modified or that this is a snapshot view. This leaves some room for interpretation for a cautious agent.
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 well-structured sentences with no redundant detail. The first sentence names the action and sources; the second explains the computation and practical purpose. Every clause earns its place, and no filler is present.
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 tool with one optional parameter and no output schema, the description is nearly complete: it identifies inputs, logic, and the resulting shortfall metric. It does not enumerate the exact return fields, but those are easy to infer from the described grouping and cross-referencing logic.
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%, and the sole parameter topN is already well documented in the schema with its default and sort behavior. The description adds no extra parameter context, but none is really needed, so the baseline of 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 states a specific action (aggregate) and resource (open procurement demand from open sales orders and released/planned production orders). It clearly describes the grouping, cross-referencing, and net-shortfall calculation, which sharply differentiates it from sibling planning tools like calc_reorder_point or get_open_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 context: use this when you need an aggregated picture of procurement demand and net shortfall for all open sales and production orders. It does not explicitly name alternatives or exclusisons, but the context is concrete enough to guide an agent toward it and away from pure sales or stock reporting tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 does well by explaining the exact thresholds and scoring logic: A=top 80%, B=next 15%, C=bottom 5%, and XYZ based on coefficient of variation. It does not explicitly state that the tool is read-only or describe output format, but the analytic, non-mutating nature is strongly implied.
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 tight, information-dense sentences with no filler. It front-loads the core purpose, then provides essential methodological context and a brief application note.
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 low-complexity, read-only analysis tool with two optional parameters, the description is nearly complete: it explains the classification scheme and intended use. The main remaining gaps are the exact return shape and an explicit statement that no data is mutated, but these are minor given the nature of the tool.
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%—both topN and historyMonths are fully described in the input schema. The tool description adds no parameter-specific detail beyond what the schema already provides, so the baseline of 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 opens with a precise statement—'ABC-XYZ inventory classification'—and then gives exact definitions for each class, making it unmistakable what the tool does. This clearly distinguishes it from sibling tools like segment_customers_rfm or analyze_revenue_concentration by specifying method and resource.
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?
The description includes a useful purpose statement—'prioritising stock holding and replenishment policies'—which implies when it would be used. However, it never explicitly contrasts this tool with alternatives like calc_reorder_point, detect_stockout, or forecast_item_demand, so the agent must infer when this is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral transparency burden. It clearly discloses that the tool calculates and reports metrics rather than mutating data, and it adds interpretive context by explaining that high HHI signals single-customer dependency risk. It does not explicitly state read-only behavior or describe output formatting, but the analysis-oriented language makes the non-destructive nature sufficiently clear.
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 compact and front-loaded: the first sentence names the analysis type, the second lists concrete outputs, and the third supplies interpretation guidance. Every sentence earns its place with no filler or redundant restatement 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?
For a read-only analysis tool with no required parameters, the description covers the key outputs and the meaning of HHI, which is enough to invoke the tool confidently. It is slightly incomplete in not explaining whether the 'top N' is configurable or what the exact response shape looks like, but the lack of required parameters and clear analytical intent make this a minor gap.
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?
The input schema already covers both parameters with descriptions and default values at 100% coverage. The tool description adds no additional parameter semantics, so it adds no value beyond the schema. A baseline of 3 is appropriate because the schema fully documents the parameters.
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 identifies the tool as revenue concentration/Pareto analysis and lists the specific computations it performs (top-N revenue share, HHI, and 80% revenue customer count). This differentiates it from siblings like analyze_vendor_concentration by focusing on revenue, and from get_top_customers by providing concentration metrics rather than a simple customer list.
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?
The description implies the tool is for assessing customer dependency risk via HHI, but it does not explicitly state when to use this tool versus related alternatives such as analyze_vendor_concentration or get_top_customers. There are no when-not-to-use conditions or direct comparisons to siblings, leaving the selection context mostly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It states the tool 'shows' specific outputs, implying a read-only analysis, but it does not explain date-range behavior, aggregation level, or interpretation of the HHI index. The output-oriented disclosure provides some transparency but leaves significant behavioral details implicit.
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 a single, tightly written sentence that front-loads the tool's purpose, then explains what it shows and why it matters. Every clause adds value, and there is no redundant or filler content.
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 analysis tool with two fully documented optional parameters and no output schema, the description covers the core purpose, key outputs, and use case. Minor gaps remain around date-range semantics and how exactly the HHI index is computed or interpreted, but the tool is reasonably understandable and invocable as described.
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?
The input schema already fully describes both parameters (toDate, fromDate) with format and defaults, so description-level parameter documentation is not necessary. The baseline of 3 applies because the description adds no parameter semantics 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 clearly states the tool analyzes vendor spend concentration, specifically for AP spend, and names concrete output metrics (top vendor spend%, cumulative spend%, HHI index). This makes the tool's purpose distinct from general purchase analysis or revenue-focused tools in the sibling list.
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 context: it is used to assess supply-chain dependency risk through vendor spend concentration. It also distinguishes itself from the customer revenue concentration model by explicitly saying it applies to AP spend, but it does not name alternative tools 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.
Behavior3/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 does convey the core effect—recording physical receipt into the warehouse—which goes beyond merely restating the tool name. However, it does not mention side effects such as inventory posting, stock updates, or validation against the purchase order status.
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?
A single sentence that front-loads the action, specifies the source document, and states the operational purpose. Every part earns its place and there is no redundancy.
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 low-complexity tool with only two parameters and no output schema, the description provides sufficient context: it identifies the trigger (open purchase order), the action (goods receipt), and the domain (warehouse receipt). It could add information about required business documents or inventory effects, but the core calling context is adequately covered.
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 both parameters are already explained in the input schema. The description adds no new parameter-level detail, making the baseline 3 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 uses a specific verb-object pair ('Create a Goods Receipt PO') and clarifies the source ('from an open purchase order') and purpose ('records physical receipt of goods into warehouse'). This clearly distinguishes it from sibling tools like create_purchase_order or create_delivery.
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 identifies the appropriate condition for use: goods have been physically received against an open purchase order. It does not explicitly name alternatives or state when not to use it, but the context is clear enough for an agent to route correctly among the many procurement-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 does disclose useful side effects: it copies open lines and records a vendor commitment. However, it does not reveal what happens to the source quotation after the PO is created, what response/status is returned, or what happens if no open lines exist.
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?
A single, front-loaded sentence with no filler. It names the action, source, and key behavior in a compact way, and every clause contributes useful information.
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 4-parameter tool with one required parameter, the description is largely complete: it identifies the required source document, the accepted-status precondition, and the core behavior. Absent output schema and annotations make it slightly less complete around return values and post-conditions, but the tool is still usable confidently for the main use case.
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 75%, so the schema already documents most parameters. The description adds meaning to purchaseQuotationDocEntry by explaining that the quotation's open lines are copied, but it adds no semantics for docDate, docDueDate, or comments beyond what the schema provides.
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 states a specific verb ('Create') and resource ('purchase order'), and clearly specifies the source ('from an accepted purchase quotation') and what it does ('copies all open lines from the quotation and records the vendor commitment'). This distinguishes it from the sibling create_purchase_order, since this tool is explicitly a quotation-derived creation flow.
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?
It gives clear context for when to use the tool — when an accepted purchase quotation exists — and describes the underlying behavior as derived from that quotation. However, it does not explicitly name alternatives or state when not to use it, such as distinguishing from the general create_purchase_order tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 discloses meaningful behavior: the tool creates a persisted document (implied by the instruction to confirm the full request before calling), requires warehouse codes sourced from a separate endpoint, and applies defaults like requiredDate falling back to docDueDate. It does not describe what happens after a successful call (response shape, document status, error conditions), which keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded in the first sentence, and the subsequent workflow detail is dense but logically organized: prerequisite, per-line collection order, defaulting options, and confirmation steps. The length is justified by the tool's interactive multi-line complexity, though the single long procedural sentence could be tightened into bullet-like structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a document-creating tool with no output schema and no annotations, the description thoroughly covers the input-gathering workflow but omits post-call behavior such as the returned document number, whether the request is posted or draft, and which sibling (create_purchase_order) should be used for downstream steps. The invocation path is well specified, but the aftermath is left to inference.
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 67%, and the schema already documents the key parameter semantics (warehouseCode required from get_warehouse_list, requiredDate defaulting to docDueDate, requester defaulting to the logged-in user). The description adds value by specifying the collection order (item code, quantity, warehouse, required date) and the prerequisite list call, but it does not clarify the undocumented itemCode, quantity, unitPrice, or comments semantics beyond what the schema provides.
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: 'Create an SAP Business One purchase request (internal requisition) for required goods or services.' The parenthetical clarifies the document type, which distinguishes it from siblings like create_purchase_order and create_purchase_quotation, so an agent can route to the right tool without opening any schema.
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 operational context: call get_warehouse_list first, collect inputs one at a time, offer docDueDate as the default required date, confirm each line, and confirm the full request before invoking the tool. However, it never states when to use this tool versus alternatives such as create_purchase_order, so exclusions and alternative-selection criteria are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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: it reveals auto-backtesting across 9 models, MAPE-based recommendation, and the output content (per-period forecasts plus accuracy table). This is meaningful behavioral context beyond the input schema.
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 two sentences, front-loads the core purpose, and packs in substantial detail without redundancy. The model list is long but earns its place by clarifying scope and methodology.
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 forecasting tool with no output schema, the description covers purpose, method, model evaluation, and return contents well. It does not mention data requirements or failure modes, but given the schema documents all parameters and everything is optional, the remaining gaps are minor.
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 parameters are already well documented. The description adds no additional meaning beyond naming sales measures that match the schema's 'measure' values, which is not enough to raise the score above baseline.
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 names a specific verb ('Predict'), a clear resource ('future sales revenue, quantity, or gross profit'), and enumerates the statistical modeling approach. It is easily distinguishable from forecasting siblings like forecast_cash_flow and forecast_item_demand because it explicitly scopes to sales metrics.
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?
The description clearly implies the tool is for sales forecasting but never explicitly states when to use it over alternatives such as forecast_item_demand or detect_seasonality. There is useful context but no explicit when-to-use/when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. 'Fetch' signals a read operation and 'full master data record' suggests broad scope, but there is no disclosure about error behavior, authorization needs, or handling of invalid card codes.
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?
One compact sentence that front-loads the action and result, with no filler or repetition of schema information.
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 1-parameter fetch-by-ID tool, the description covers the core calling contract: what resource is returned and which key identifies it. However, without an output schema or annotations, an agent gets no detail on response shape or edge cases.
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 has one required cardCode string with 0% coverage; the description identifies it as the business partner card code and clarifies it applies to both customers and suppliers. This compensates for the bare schema, though it does not mention format or expected source.
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 uses a specific verb ('Fetch') and resource ('full business partner master data record') and scopes it to both customers and suppliers keyed by cardCode. This clearly distinguishes it from list-style siblings like get_customer_list and get_vendor_list.
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?
The description implies usage when a single record is needed by card code, but it never names alternatives or states when not to use it. There is no explicit guidance such as 'for a list, use get_customer_list', so usage context is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining the operation. It discloses the key behavioral output: conversion rate, average deal value, open/won/cancelled counts, and a by-customer breakdown. The verb 'Shows' implies a read-only analytical report, which is a sufficient behavioral cue for this type of tool. It does not detail edge cases or data freshness, but the core behavior is transparent.
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 waste. The first sentence is front-loaded with the tool's core purpose and output details; the second provides a practical use case. Every clause adds useful information.
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 two-parameter read-only report with no output schema, the description enumerates the returned metrics and explains why it would be used. It lacks explicit statement of read-only safety and does not mention how the date range interacts with the grouping, but these are minor given the 100% schema coverage and simple parameter object.
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%, with both toDate and fromDate clearly documented including defaults. The description does not add any parameter nuance beyond the schema, so the baseline score of 3 is appropriate because the schema carries the semantic burden.
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 names a specific resource (sales quotations) and a specific analytical verb (Shows win-rate/conversion analysis), then enumerates the exact metrics returned. This clearly differentiates it from broader siblings like get_sales_analysis or get_open_quotations.
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?
It gives an implied use case ('sales pipeline and forecast accuracy assessment') but does not state when to prefer this over alternative sales-analysis siblings, nor when not to use it. No exclusions or alternative tool names are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 clearly explains what the tool computes and what it returns, including days-of-stock-remaining and the risk-level thresholds. It does not explicitly state that it is read-only, but the 'predict' and 'returns' wording strongly implies a non-mutating analytical operation.
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 a single, information-dense sentence that front-loads the main purpose and immediately follows with the return format and thresholds. Every clause adds value, with no filler or repetition 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 is largely complete for a simple prediction tool: it explains what inputs matter, what the output looks like, and how risk levels are classified. Because there is no output schema, the explicit description of return values is valuable. Still, it does not address when not to use it or how it relates to closely related inventory tools, which leaves a small contextual gap.
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?
The input schema already documents both parameters (topN and demandDays) with 100% coverage, so the baseline applies. The description reinforces the meaning of demandDays through 'recent daily demand' but does not add meaningful new detail beyond the schema, and it does not mention topN at all.
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 identifies the tool's purpose: predicting stockout risk for inventory items based on stock levels and daily demand. It also specifies the exact output format, days-of-stock-remaining per item, with concrete risk thresholds, which distinguishes it from related inventory tools like detect_dead_slow_stock or calc_reorder_point.
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?
The description implies this tool should be used when an agent needs to assess stockout risk using current stock and recent demand. However, it does not explicitly state when to prefer this over sibling tools such as calc_reorder_point, detect_dead_slow_stock, or monitor_reorder_items, so the usage context is clear but the exclusion guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations supplied, the description carries the transparency burden. It discloses the HTTP method ('Simple OData GET'), service context, and provides concrete filter/status syntax examples. It could also mention pagination or server limits, but the schema already notes that omitting top returns all records; overall, enough behavioral context is provided for a read-only query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long, but the length is justified by the extensive catalog of valid view names and filter examples, which directly supports correct invocation. It is well-structured with clear section headers and front-loads the core purpose in the first sentence, keeping the important guidance easy to scan.
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?
Given the tool's complexity and absence of an output schema, the description is substantially complete: it covers available views, common fields, date-filter patterns, and status values. It lacks explicit guidance on when NOT to use it versus closely related query tools, but the provided context is sufficient for most analytics and reporting scenarios.
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 coverage is 100%, so the baseline is 3. The description adds meaningful value by enumerating valid view names, common fields per view type, and OData date-filter and status-filter patterns. This goes beyond the schema's plain parameter descriptions and helps construct correct 'filter' and 'viewName' values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the specific verb ('Query'), the resource ('SAP B1 Standard HANA Model view via sml.svc'), and the intended domain ('all analytics, reporting, and document queries'). It differentiates from raw query siblings by emphasizing the SML service and 'no namespace needed', though it does not explicitly name an alternative tool.
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 explicitly says 'Use this for all analytics, reporting, and document queries', giving a clear primary context. It does not provide explicit exclusions or name sibling alternatives like query_hana_direct or query_sql_direct, but the domain framing and view list guide appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It explicitly states side effects: logs out current session, logs in to new DB, and resolves namespace. This goes well beyond the tool name, though 'resolves namespace' remains somewhat vague.
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 short sentences front-load the core action and then add the key behavioral details. Every word contributes value, with no repetition or 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 single-parameter tool with no output schema, the description covers all required inputs and the critical session side effects. It could mention what the caller should expect in return or how to verify success, but the operational behavior is sufficiently complete 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 description coverage is 100%, and the parameter description in the schema already defines dbName with a clear example. The description adds no additional semantic meaning beyond the schema, so the baseline of 3 applies.
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 uses a specific verb ('Switch') and a clear resource ('different SAP B1 company database'), which distinguishes it from siblings like get_company_info that merely retrieve information. The first sentence fully states the tool's purpose without ambiguity.
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?
The description implies when to use the tool (when a different company DB is needed), but it does not provide explicit guidance about when not to use it or how it compares to alternatives such as get_company_info. The context is clear, but no exclusions or routing logic are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 data source, the calculation basis (creation to due date), the output metrics, and the reliability rating logic based on std dev. It does not explicitly state it is read-only, but the 'Analyse' verb and return-value framing strongly imply a non-mutating operation.
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 a single efficient sentence with zero filler. It front-loads the purpose, clarifies the data source in parentheses, and then lists the outputs and rating rule without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description fully explains the return values (average lead days, std dev, min/max per vendor, reliability rating). Combined with the fully documented parameter schema and the low complexity of the tool, an agent has everything needed to invoke it correctly.
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% for the only parameter (months, default 6, max 24). The description itself adds no parameter-specific semantics, so the baseline score applies.
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 uses a specific verb ('Analyse') and a clear resource ('vendor lead time reliability') backed by a specific data source (PO creation date → due date). It also enumerates the exact return metrics, making the tool's purpose unmistakable and distinct from sibling analytics tools.
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?
The description implies when to use this tool—when vendor lead time reliability is needed—but gives no explicit guidance on when not to use it or how it differs from related siblings like analyze_on_time_delivery. Context is present but no alternatives or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does well by explaining the z-score methodology and the exact flagging rule (|z| ≥ threshold). It could also mention whether the operation is read-only and what the return payload looks like, but the core behavior is transparent enough for a detection tool.
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 first front-loads the method and scope, the second states the criterion and use cases. Every phrase contributes to understanding the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, and the description does not state what the tool returns (e.g., a list of flagged transactions, a summary count, or scores). While the parameters are fully described and invocation is straightforward, the missing return semantics leaves a notable gap for an agent trying to use the result.
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?
The input schema already documents all three parameters with 100% coverage, including defaults and value formats. The description does not add significant parameter-level meaning beyond the schema; it only echoes AR/AP and threshold concepts. 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 names a specific statistical method (z-score analysis), a specific resource (AR/AP invoice amounts), and a specific outcome (flagging transactions with |z| above threshold). This clearly distinguishes it from sibling detection tools like detect_customer_churn or detect_seasonality, which target different resources.
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?
It gives explicit application contexts: fraud detection, data-entry errors, and pricing anomalies, and it clearly scopes the tool to AR/AP invoice transaction amounts. However, it does not name alternative tools or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It discloses the underlying data sources (open AR/AP invoices), the bucketing approach, and the returned value. The verb 'forecast' and the word 'returns' reasonably imply a read-only analysis tool, though it does not explicitly describe side-effect status or data freshness.
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 a single, well-structured sentence that front-loads the core action and resource, then uses a dash to state the output clearly. There is no filler, repetition, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is mostly complete for a simple one-parameter tool: it explains data sources and return buckets. However, it creates ambiguity by only mentioning 0-30,31-60,61-90 day windows while forecastDays can be up to 180 days, and there is no output schema to clarify whether longer horizons produce additional buckets. That gap should be resolved.
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?
The only parameter, forecastDays, is fully documented in the input schema with a description, default value, and maximum value, so schema description coverage is 100%. The tool description adds no additional parameter-level meaning beyond what the schema already provides, which aligns with the baseline of 3.
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 uses a specific verb ('Forecast') with a clear resource ('cash inflows from open AR invoices and outflows from open AP invoices') and defines the exact output ('net cash position for 0-30, 31-60, 61-90 day windows'). This clearly differentiates it from single-sided aging tools like get_ar_aging and get_ap_aging, as well as broader forecasting tools.
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 establishes clear usage context: this tool is for combining open AR and AP invoices into a future net cash position by due-date buckets. However, it does not explicitly name alternatives or state when not to use this tool, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full behavioral burden. It makes the non-mutating 'scan and return' nature evident and discloses useful behavioral detail: filtering against MinInventory, computing suggested replenishment to 2× minimum, and returning vendor/cost info. It does not mention performance limits or auth expectations, but the description adequately communicates the operation's core behavior.
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 compact and well-ordered: the main action and selection criterion appear first, followed by the optional filter and then the return fields. There is no filler or repetition of schema details, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter, read-only tool with no output schema, this description is complete enough. It explains the core logic, optional warehouse scoping, and the principal fields returned, while the schema covers topN defaults and sorting. An agent has sufficient context to invoke the tool correctly.
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?
The input schema already documents both parameters with 100% coverage, including topN's default and sorting and warehouseCode's restriction behavior. The description only restates the warehouseCode option ('Optionally restrict to a specific warehouse') and adds no new meaning for topN, so a baseline of 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 definition uses a specific verb ('Scan... return') with a clear resource ('inventory items') and states the exact selection rule: current stock below MinInventory. It also distinguishes itself from sibling inventory/ordering tools by listing unique outputs — deficit, suggested replenishment quantity to 2× minimum, preferred vendor, and estimated cost per item.
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?
The intended use case is implied clearly: use when you need to identify understocked inventory items and get replenishment recommendations. However, there is no explicit when-not-to-use guidance or named alternatives such as calc_reorder_point, calc_eoq, or get_total_stock, so the agent must infer the decision boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses a meaningful behavioral trait ('Validates customer credit before posting') and distinguishes conversion from direct creation. However, it does not mention whether the source quotation is consumed/closed, what authorizations are required, or what the tool 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?
Two sentences with no wasted words. The main action is front-loaded, the two parameter modes are stated compactly, and the credit-validation behavior is appended without redundant schema repetition.
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 mutation tool with no annotations and no output schema, it covers the essential call-shape information and a key business rule. It is light on post-conditions and return values, but the schema already documents field semantics, so an agent has enough context to invoke it correctly.
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%, so the baseline is already strong. The description adds value by grouping parameters into mutually exclusive paths ('Either supply quotationDocEntry ... OR supply cardCode + lines') and providing a real-world scenario ('from a purchase order') that the schema alone does not express.
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 action and object ('Create a sales order'), then defines two concrete creation paths: convert an existing quotation or create directly from cardCode + lines. The 'quotation' conversion phrasing clearly separates it from create_sales_quotation and other sibling tools.
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?
Provides unambiguous guidance on when to use each creation mode: quotationDocEntry for converting a quotation, and cardCode + lines for direct creation 'e.g. from a purchase order'. It does not explicitly name alternatives like create_sales_quotation or create_ar_invoice, but the internal mode guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 clearly explains that the tool analyzes a period, applies thresholds for dead and slow stock, and reports tied-up inventory value. It implies a read-only analytical operation through 'Identify,' and gives the key decision-oriented output. It could mention how results are grouped or returned, but it is not misleading.
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 a single, front-loaded sentence that defines the core behavior, then adds the decision context. Every phrase contributes: the detection criterion, the slow/good threshold, and the output value. There is no redundancy or 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 tool with two optional parameters and no required fields, the description plus schema is sufficient for an agent to invoke it correctly. It explains what the analysis identifies and what value it reports. The absence of an output schema is a minor gap, but the description names the core return concept (tied-up inventory value), and the tool complexity is low.
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 parameters are already well-documented in the schema. The description adds minimal extra meaning beyond referencing 'period' and 'average demand,' which maps to deadDays and slowFactor. Baseline 3 applies because the schema does the heavy lifting.
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 names a specific verb ('Identify'), a clear resource ('dead stock and slow-moving stock'), and precise definitions for each category (zero demand, demand < slowFactor × average). It also mentions tied-up inventory value as an output, which makes it clearly distinct from related siblings like predict_stockout or get_total_stock.
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 an explicit intended use case: 'Helps prioritise clearance or write-off decisions.' This provides clear context for when to apply the tool among the many inventory-related siblings. It does not name alternatives or state when not to use it, but the purpose is specific enough to disambiguate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses the analytical approach (linear regression on monthly GP%), the threshold-based flagging, and the output concept of 'at risk' items. It does not explicitly state whether the tool is read-only, but the detect/flag language strongly implies a non-mutating analysis tool.
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 concise sentences deliver the purpose, methodology, and outcome. No filler or redundant wording; the description is tightly structured and immediately useful for an agent.
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 covers what the tool does, how it does it, and what it produces. Without an output schema, it could go further in describing the exact return format, but for selection and basic invocation the details are sufficient. The absence of annotations is partially mitigated by the clear read-only analysis framing.
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%, and both parameters have clear descriptions with defaults and limits. The tool description itself does not add parameter-level detail, but it references the threshold and time window conceptually. Since the schema already documents parameters well, a 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 clearly states a specific verb and resource: detecting items whose gross profit percentage has declined by more than a threshold. It further distinguishes the tool by explaining the linear regression methodology on per-item monthly GP%, which separates it from sibling detect tools like detect_customer_churn or detect_seasonality.
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 implies clear usage context: use this when you need to identify margin erosion trends on items over time. It does not explicitly name alternatives or exclusions, but the methodology and objective are specific enough that an agent can infer when it applies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It does so by enumerating the 9 models, stating backtest-based auto-selection, and naming the exact outputs (monthly forecasts, MAPE/MAE/RMSE, procurement suggestion with 20% safety stock). It does not explicitly state that no records are written, but the 'Predict' and 'Returns' wording strongly imply a read-only analytic operation.
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?
A single dense sentence front-loads the main purpose and then efficiently lists models, selection method, and return values without any filler. Every phrase 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?
The description is strong for a tool with no output schema, explaining what the caller will receive: per-model forecasts, accuracy metrics, and a procurement suggestion. The input schema covers parameter meaning, so nothing critical is missing for selecting and invoking the tool. Minor gaps like edge cases or failure behavior exist, but they are not essential.
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. The description adds context around the forecast outputs and model selection, but it doesn't provide additional semantic detail about historyMonths or horizonMonths beyond what the schema already gives.
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 states the exact action ('Predict future demand quantity') and the resource ('a specific item'), then lists all 9 model names and the expected outputs. This is specific enough to distinguish it from sibling tools like forecast_sales or forecast_cash_flow.
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 use case clear: single-item demand forecasting with a procurement suggestion. It doesn't explicitly say 'use this instead of forecast_sales', but the item-level demand framing and safety-stock output imply the right context without ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It discloses the comparison logic, the configurable tolerances, and the flag names for missing or mismatched data (NO_GRPO, OVER_INVOICED, etc.), including that missing documents are flagged rather than causing a hard failure. It does not explicitly state that the tool is read-only or describe the result payload, but the flag list strongly implies a report-style output.
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 one dense sentence with no filler. It front-loads the core action, then gives the comparison dimensions and the flag vocabulary, so every clause earns its place and the agent can quickly parse the tool's function.
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 no annotations and no output schema, the description covers the essential behavior: what is compared, under what tolerances, and what flags are emitted. The main gap is the lack of explicit read-only/non-mutating confirmation and a precise description of the return shape, but the flag list largely compensates for the missing output schema.
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 input schema already documents all three parameters at 100% coverage, which sets a baseline of 3. The description adds meaning by explaining that PO lines carry committed quantity/price, that GRPO is the receipt and AP Invoice is the invoice, and that the tolerances apply to variance detection. This helps the agent understand how poDocEntry and the tolerance parameters fit into the match logic beyond their schema descriptions.
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 uses a specific verb ('Run') and resource ('three-way match for a Purchase Order'), then specifies exactly what is compared (PO committed quantity/price vs GRPO received and AP Invoice invoiced). It lists concrete flag outputs, making the tool's function unmistakable and distinct from siblings like create_goods_receipt_po or create_ap_invoice, which create documents rather than verify them.
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?
The description implies when to use the tool—when a PO needs three-way matching against its goods receipt and invoice—but it does not explicitly state a trigger condition or mention alternatives. There are no exclusions or 'use X instead' guidance, so the agent must infer the appropriate context from the tool's name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the behavioral disclosure burden. It usefully reveals that execution is a create-on operation, offers a dryRun escape hatch to avoid creating documents, and exposes the edge case that items without a preferred vendor are skipped and reported in skippedNoVendor. It does not state whether the resulting POs are draft/posted or what happens on partial failure, but the description is substantially transparent for a create-style tool.
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 sentences with no filler: purpose, dryRun behavior, and skip edge case are all front-loaded and necessary. Every sentence earns its place, and the structure makes the tool's core behavior easy to absorb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The central workflow, dryRun option, and one important edge case are covered. However, there is no output schema and the description only hints at return values via skippedNoVendor; an agent does not know what a successful run returns (e.g., PO identifiers or statuses). For a tool that creates multiple documents, missing return and failure semantics are a clear gap.
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 coverage is about 75% (items, dryRun, and docDueDate are described), so the baseline is already fairly high. The description adds real meaning by explaining that items are grouped by DefaultVendor and that dryRun previews grouping without document creation. It does not add detail for comments or warehouseCode, but those are straightforward and not a major gap.
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 names a specific action and result: group items-with-antities by preferred vendor and create one Purchase Order per vendor. It also states the grouping key (DefaultVendor on the item master), which clearly differentiates it from siblings like create_purchase_order and create_po_from_quotation. This is a concrete, non-tautological definition.
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?
It clearly defines the intended scenario: a list of items to procure that should be grouped by vendor, and it explicitly suggests dryRun:true for a non-destructive preview. It does not name create_purchase_order as an alternative or state when not to use the tool, so there are no explicit exclusions. Overall, the context is clear though routing guidance is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it states data source (SAP B1), scope (active warehouses only), and the actual payload fields (code, name, location). It is clearly a read-only list operation, though it does not elaborate on edge behaviors like pagination or result limits.
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: the first states the core function and return fields, the second states when to use it. All words earn their place and key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read/list tool with one optional parameter and no output schema, the description is complete: it tells the agent what data is returned, the source system, the active filter, and the intended use case. Nothing needed to invoke it correctly is missing.
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%, and the schema already describes 'search' as an optional filter by warehouse code or name. The description reinforces the warehouseCode connection but adds no new parameter-level meaning 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 uses a specific verb ('List') with a clear resource ('active warehouses from SAP B1') and names the returned fields (code, name, location). This distinguishes it from siblings like get_warehouse_sales or get_total_stock, which address different questions.
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 a concrete usage context: use it to let the user pick a valid warehouseCode before creating documents like purchase requests. It does not name explicit alternatives or when-not-to-use conditions, but the context is clear enough for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It fully discloses the computation logic (daily demand × (lead time + safety days)) and the decision rule (current stock ≤ ROP), making the tool's read/calculate behavior clear. It stops short of explicitly saying 'read-only, no side effects' or describing the return shape, but 'calculate' strongly implies a pure analysis operation.
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?
A single, well-structured sentence that front-loads the action, includes the formula as precise context, and finishes with the decision rule. There is no fluff or repetition; every clause adds useful information.
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 calculation tool with four optional parameters and no output schema, the description provides enough to invoke it correctly: the formula, the per-item scope, and the flagging condition. It does not detail the exact return fields or ordering, but agents can infer the tool returns item-level ROP and a 'needs ordering' indicator. This is complete enough for selection and reasonable invocation.
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 coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema by showing how leadTimeDays and safetyDays combine in the ROP formula and how demandDays relates to daily demand. It does not elaborate on topN, but the schema already describes that parameter well.
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 states a specific action ('Calculate Reorder Point'), identifies the resource ('each stocked item'), gives the exact formula, and names the output behavior ('flag which items need ordering now'). It clearly distinguishes from sibling tools like calc_eoq and predict_stockout because of the explicit threshold condition (current stock ≤ ROP).
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 conveys a clear usage context: whenever a reorder point needs to be computed and items below that point must be flagged for ordering. It does not explicitly mention alternatives or when-not-to-use, but the purpose is self-evident enough for an agent to select it from a crowded inventory-analysis sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: read-only SELECT-only enforcement, required HANA_* environment variables, the error if they are missing, the single-tenant multi-company visibility, and double-quoted case-sensitive schema qualification. It also discloses that non-SELECT statements are rejected, which is important 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is well front-loaded with purpose, usage, requirements, and constraints before the table reference. It is long, but the table earns its place for a SQL query tool; the main structural flaw is the slightly mismatched T-SQL / MSSQL heading on a HANA tool and some redundancy in the table block.
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?
It covers prerequisites, error behavior, schema discovery, and key table metadata, so an agent can invoke it correctly. It stops short of saying what the tool returns or whether result sets are limited, and with no output schema those details would round out the otherwise strong context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides a short example for query, but the description adds substantial meaning: mandatory fully qualified schema.table names, HANA double-quoting and case sensitivity, the SELECT-only constraint, and a large curated reference of SAP B1 table names and key columns. This is far more than the input schema alone provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action and resource: running a read-only SQL SELECT directly against an SAP B1 HANA database and bypassing Service Layer. It is clear about the target and mode, but it never explicitly contrasts this tool with sibling query_sql_direct, so an agent may need to infer the HANA-vs-SQL-database boundary.
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?
It gives explicit triggers: use when Service Layer is unavailable or misconfigured, or when an OData join/aggregation is awkward, and it tells the agent to call list_hana_schemas first if the schema is unknown. However, it does not state when not to use direct SQL or mention query_sql_direct as an alternative, leaving the choice between the two direct-query siblings implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 the important behavioral scope: it lists only company schemas and excludes system schemas, which is critical for interpreting the result. It does not mention authorization or output format, but for a simple read-only listing tool with zero parameters, these are minor omissions.
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, no wasted words. The main purpose and exclusion are front-loaded, and the secondary usage hint is placed after the core definition. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter discovery tool with no output schema, the description is fully complete: it defines the result, the exclusions, and the intended downstream use. An agent has all the information needed to call it correctly and interpret its output.
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?
There are zero parameters, so the baseline is 4 per calibration guidelines. The description adds no parameter-specific detail because none is needed; the behavior itself is fully described.
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 starts with a specific verb 'List' and a clear resource: 'company schemas available on this HANA tenant'. It also adds a precise exclusion ('excludes SAP/HANA system schemas') and distinguishes itself from query tools like query_hana_direct by framing itself as a discovery tool.
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 explicitly states a use case: 'Use this to discover valid schema names for query_hana_direct instead of guessing.' This provides clear when-to-use context and names the downstream tool. It does not discuss alternatives or when-not-to-use, but the guidance is strong enough for an agent to know when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden, and it delivers: it states the tool is read-only, rejects anything besides SELECT, errors when environment config is missing, and even warns about unused/UDF fields that could silently produce wrong results. This is unusually candid about failure modes and data caveats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is long, but it is logically structured and front-loaded: core purpose and usage come first, followed by environment requirements, database list, table/column references, and a domain-specific brokerage section. It is not concise in volume, but most content earns its place as a working reference for composing correct SQL.
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?
Given no output schema or annotations, the description is impressively complete: it covers invocation, target databases, allowed statements, environment prerequisites, key table schemas, and even field-level caveats. It omits result-format details, row limits, and timeout/performance behavior, which would make it fully complete for an unconstrained direct-SQL tool.
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 coverage is 100%, so the baseline is 3. The description adds real value beyond the schema by clarifying that 'database' overrides the connector default, providing concrete database names, and emphasizing that 'query' must be a single SELECT statement. It doesn't radically expand query semantics, but it enriches both parameters usefully.
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 precise verb-resource-scope statement: 'Run a read-only T-SQL SELECT directly against a SAP B1 SQL Server database, bypassing Service Layer entirely.' This distinguishes it from sibling tools like call_service_layer and query_hana_direct, and the 'Only SELECT statements are allowed' clause further nails its exact role.
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?
It gives explicit conditions for use: when Service Layer is unavailable/misconfigured, or when a join/aggregation is awkward via OData. It also documents required environment variables, how to target a specific database, and lists known databases, giving an agent everything needed to decide when this tool beats its alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![AgentSphere-MCP MCP server](https://glama.ai/mcp/servers/parmarnaresh86/AgentSphere-MCP/badges/card.svg)](https://glama.ai/mcp/servers/parmarnaresh86/AgentSphere-MCP)

Score Badge

Copy to your README.md:

[![AgentSphere-MCP MCP server](https://glama.ai/mcp/servers/parmarnaresh86/AgentSphere-MCP/badges/score.svg)](https://glama.ai/mcp/servers/parmarnaresh86/AgentSphere-MCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/parmarnaresh86/AgentSphere-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server