Skip to main content
Glama
Sign In
Supplyline MCP

Supplyline MCP

by saundaryaverma
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

bom_cost

Calculate total bill-of-materials cost for a product and identify the largest cost drivers, helping supply managers see where material spend is concentrated.

Instructions

Roll up the bill of materials cost for a product and show the biggest cost drivers.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "product": "<product>"
    },
    "name": "bom_cost"
  }
}

Input Schema

NameRequiredDescriptionDefault
unitsNo
productYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description carries full behavioral burden. It hints at the return content ('biggest cost drivers') but does not disclose that this is a read-only/non-mutating operation, what happens for an unknown product, or data freshness — all of which an agent needs given zero annotation coverage.

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

Conciseness5/5

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

A single front-loaded sentence with zero waste; the core action and the key output are both stated efficiently.

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 2-parameter tool with no output schema, the description conveys purpose and rough return content adequately, but leaves parameter meaning and behavioral traits undocumented with no annotations to fill the gap.

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 coverage is 0% and there are 2 parameters. The description implies 'product' is the subject but never clarifies its expected format (ID, SKU, name), and never mentions the 'units' parameter at all — so it fails to compensate for the documentation gap.

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 verb and resource ('Roll up the bill of materials cost for a product') plus an output behavior ('show the biggest cost drivers'). It is clearly a compute/analysis tool distinct from the sibling set (search_parts, supplier_scorecard, etc.), though it does not explicitly name or route against 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?

There is no guidance on when to use this tool versus alternatives, or any prerequisites (e.g., whether the product must already exist, whether it requires a BOM to be defined). The agent must infer usage entirely from the purpose sentence.

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

Deploy Server

Other Tools