Skip to main content
Glama
Sign In
Ramen

Ramen

by bkraad47
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

demo_calculator_tool

Add, subtract, multiply, or divide two numbers to get an exact numeric result. Use for a single binary arithmetic operation where a precise computed value is needed.

Instructions

Add, subtract, multiply or divide two numbers and return the result as a number. Pure and stateless: no side effects, no network, no auth beyond the group's key, no rate limit of its own. Division by zero returns a tool error (isError) with a one-sentence message instead of a value. Use it when an exact arithmetic result matters; for anything beyond one binary operation, chain calls or compute in the model.

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": {
      "var1": "<var1>",
      "var2": "<var2>",
      "func": "<func>"
    },
    "name": "demo_calculator_tool"
  }
}

Input Schema

NameRequiredDescriptionDefault
funcYesoperation to apply as var1 <func> var2
var1Yesfirst operand (left-hand side); any finite number
var2Yessecond operand (right-hand side); must be non-zero for divide

Output Schema

NameRequiredDescriptionDefault
resultYesvar1 <func> var2

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.7.1
    • changedInput schema / properties / func / description
      Previous value: -"operation"New value: +"operation to apply as var1 <func> var2"
    • changedInput schema / properties / var1 / description
      Previous value: -"first operand"New value: +"first operand (left-hand side); any finite number"
    • changedInput schema / properties / var2 / description
      Previous value: -"second operand"New value: +"second operand (right-hand side); must be non-zero for divide"
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "description": "var1 <func> var2",
+      "type": "number"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "type": "object"
+}
  2. First observedv0.1.0

TDQS

A4.7/5.0
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: pure/stateless, no side effects, no network, auth only via the group key, no own rate limit, and the division-by-zero path returns isError with a one-sentence message rather than a value. That is exactly the behavioral context an agent needs.

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

Conciseness5/5

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

Four short sentences, front-loaded with purpose, then behavior, then the error case, then routing guidance. Every sentence earns its place with no 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?

An output schema exists so return values need no explanation, and the description still covers the one non-obvious edge case (division by zero producing a tool error). Nothing needed to call this tool 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 description coverage is 100%, so the schema already documents func's enum and both operands (including the non-zero constraint for divide). The description adds only the 'two numbers' framing and the left/right ordering implied by var1 <func> var2, so baseline 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?

States a specific verb set (add, subtract, multiply, divide) plus the resource (two numbers) and the return type. It is trivially distinguishable from the arithmetic-free siblings unit_convert and word_count.

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?

Explicitly names when to use it ('when an exact arithmetic result matters') and when not to ('for anything beyond one binary operation, chain calls or compute in the model'). The alternative path is stated, not implied.

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