Skip to main content
Glama
sushobhitrajan

My Learning MCP Server

calculator

Add, subtract, multiply, or divide two numbers to get their result.

Instructions

Perform basic arithmetic operations: add, subtract, multiply, or divide two numbers.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
aYesThe first number
bYesThe second number
operationYesThe arithmetic operation to perform

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.8/5.0
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. It clearly describes the core behavior (performs the selected arithmetic operation) but omits edge cases such as division by zero, error handling, or return type. For a pure computation tool, this is acceptable but not deeply 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 a single, tightly written sentence that front-loads the main verb and resource, then lists the operations. No filler words or unnecessary repetition; every word 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?

For a simple, stateless calculator with fully documented parameters, the description is sufficient for an agent to select and invoke it correctly. The absent output schema is not a gap here since the return value (the arithmetic result) is obvious, though the description does not mention division-by-zero 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?

The schema provides 100% coverage for all parameters, including descriptions for a, b, and operation. The tool description merely restates the operation names without adding meaning 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?

The description states a precise verb ('perform') with a resource ('basic arithmetic operations'), and enumerates the exact operations ('add, subtract, multiply, or divide'). It is unambiguous and clearly distinct from the only sibling tool, get_weather, making the tool's purpose immediately apparent.

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—whenever basic arithmetic on two numbers is needed—but it does not explicitly state usage context or exclusions. Since the only sibling is get_weather, no alternative routing is needed, but there is no explicit 'when to use' guidance beyond the obvious purpose.

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