Skip to main content
Glama

propose_sourcing_remediation

Read-only

Proposes remediation for a flagged sourcing part, recommending what to do about it and optionally using design-role geometry to suggest a substitute with a re-derived bore fit.

Instructions

Close the loop on a flagged part: propose what to do about it.

Free door, tiered answer — Free: nothing computed · Pro: nothing computed · Business: nothing computed · Enterprise: ✓.

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": {
      "component": "<component>"
    },
    "name": "propose_sourcing_remediation"
  }
}

Input Schema

NameRequiredDescriptionDefault
componentYesThe flagged part, a dict in the shape ``assess_bom_sourcing_risk`` takes (``ref``, ``manufacturer``, ``mpn``, ``category``). Empty or not a dict answers ``MISSING_COMPONENT``.
design_roleNoOptional geometry context for re-cutting the bore: ``thing_diameter_mm``, ``thing_type`` (e.g. ``"bearing"``), ``fit`` (e.g. ``"press"``), ``material``, ``printer_id`` and ``load_bearing``. Omitted, a substitute is proposed without a re-derived bore.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.5.1
    • addedInput schema / properties / component / description
      Added value: +"The flagged part, a dict in the shape ``assess_bom_sourcing_risk`` takes (``ref``, ``manufacturer``, ``mpn``, ``category``).  Empty or not a dict answers ``MISSING_COMPONENT``."
    • addedInput schema / properties / design_role / description
      Added value: +"Optional geometry context for re-cutting the bore: ``thing_diameter_mm``, ``thing_type`` (e.g. ``\"bearing\"``), ``fit`` (e.g. ``\"press\"``), ``material``, ``printer_id`` and ``load_bearing``.  Omitted, a substitute is proposed without a re-derived bore."
  2. Addedv1.5.0

TDQS

B3.2/5.0
Behavior4/5

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

Beyond the annotations, the description discloses a significant tier gate: Free, Pro, and Business compute nothing while Enterprise returns a result. It does not explain what 'nothing computed' returns operationally, but the entitlement behavior is substantive context not present in annotations.

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 one short sentence, followed by the tier gate. The middot-delimited tier line is somewhat cryptic but compact, with no 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?

With no output schema, the description should clarify what a proposal contains and what lower tiers return. It never describes the proposal payload or the 'nothing computed' response, leaving a meaningful gap for a read-only advisory tool with nested inputs.

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 includes detailed nested descriptions for component and design_role. The description adds no parameter meaning beyond calling the input a 'flagged part' and does not explain design_role's bore-recutting context.

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

Purpose3/5

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

The description says to 'propose what to do' about a flagged part, which signals a remediation proposal. However, 'what to do' and 'close the loop' are vague, and it never explicitly states sourcing remediation or distinguishes itself from assess_bom_sourcing_risk.

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 implies use after a part has been 'flagged,' giving some contextual guidance. It does not specify when to use this versus assess_bom_sourcing_risk or substitution-oriented siblings, and provides no exclusions or prerequisites.

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