Skip to main content
Glama
Sign In

SCModeling

by com.scmodeling
OverviewDiscussionsAdmin

Get a saved optimization scenario

get_opt_result
Read-onlyIdempotent

Return the saved optimization result for one scenario of a demo, verbatim: sourcing, production and transport decisions, costs, and facility open/close decisions. Call describe_opt_demo first for the valid scenario keys. Quote the numbers verbatim.

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": {
      "demo_id": "<demo_id>"
    },
    "name": "get_opt_result"
  }
}

Input Schema

NameRequiredDescriptionDefault
demo_idYesWhich optimization demo
scenario_keyNoThe scenario key (describe_opt_demo lists them; ignored for sso-basic)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / scenario_key / description
      Previous value: -"Scenario key within the demo. Format varies per demo — call describe_opt_demo for the exact valid keys before guessing. Tariff uses 'APAC=<N>' where N is one of 0, 7.5, 25, 50, 100. Coffee uses '<configKey>|DSL=<N>' where configKey is T/TA/TS/TAS and N is 20-70 in steps of 5 (10c units of $/gal). sso-basic is single-scenario; scenario_key is ignored."New value: +"The scenario key (describe_opt_demo lists them; ignored for sso-basic)"
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "content": {
-      "description": "MCP content blocks — single text block with the response body",
-      "type": "array"
-    }
-  },
-  "type": "object"
-}New value: +null
  2. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered. The description adds real behavioral guidance beyond that: results are precomputed/'saved' (no run needed), returned unmodified, and the agent must not paraphrase the numbers. No gap that would cause a mis-call.

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?

Two sentences with the payload enumeration up front and the dependency call immediately after — well front-loaded and free of filler. Minor redundancy between 'verbatim' in sentence one and 'Quote the numbers verbatim' at the end.

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?

No output schema exists, and the description compensates by naming the categories of returned decisions and costs, which is enough for an agent to know what it gets. It doesn't say how an invalid or missing scenario_key behaves for non-sso-basic demos, a small remaining 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?

Schema coverage is 100%, so both parameters are already documented, including the enum and the 'ignored for sso-basic' caveat. The description only restates the demo/scenario relationship and points at describe_opt_demo, adding little beyond the schema. 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?

States a specific verb ('Return') and resource ('the saved optimization result for one scenario of a demo') and enumerates the payload (sourcing, production, transport decisions, costs, facility open/close decisions). The word 'saved' plus 'verbatim' distinguishes this retrieval tool from sibling explain_optimization, which presumably interprets rather than returns raw results.

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 prerequisite ordering: 'Call describe_opt_demo first for the valid scenario keys.' It also implies a usage constraint ('Quote the numbers verbatim'). It does not state when to prefer explain_optimization over this tool, so sibling routing is only partially covered.

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

All SCModeling toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources