Skip to main content
Glama

geometry

Compute area, perimeter, volume and surface area for common shapes. Pure CPU, instant.

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": {
      "shape": "<shape>"
    },
    "name": "geometry"
  }
}

Input Schema

NameRequiredDescriptionDefault
aNoPrimary dimension
bNoSecondary dimension
shapeYescircle, square, rectangle, triangle, sphere or cylinder

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added
  2. Removed
  3. Changed4 schema fields changed
    • addedInput schema / properties / a
      Added value: +{
      +  "description": "Primary dimension",
      +  "type": "number"
      +}
    • addedInput schema / properties / b
      Added value: +{
      +  "description": "Secondary dimension",
      +  "type": "number"
      +}
    • addedInput schema / properties / shape
      Added value: +{
      +  "description": "circle, square, rectangle, triangle, sphere or cylinder",
      +  "type": "string"
      +}
    • addedInput schema / required
      Added value: +[
      +  "shape"
      +]
  4. Added

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden. 'Pure CPU, instant' usefully signals a side-effect-free, deterministic local computation with no network or auth dependency, but nothing is said about the return shape, how an unrecognized shape is handled, or what the tool does when required dimensions are missing.

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?

Two short sentences, front-loaded with the capability, followed by a compact behavioral qualifier. No filler or redundancy.

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?

With no output schema and no annotations, the description is close to sufficient for a simple arithmetic helper: it states the outputs, the shape family, and the local/instant behavior. The remaining shortfall is the absence of any mapping between the a/b parameters and specific shapes, which is where miscalls are most likely.

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 the baseline is 3. However the schema's own wording ('Primary dimension', 'Secondary dimension') is generic, and the description does not explain which dimensions map to which shape (e.g. radius for circle, radius+height for cylinder), so it adds no compensating meaning.

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?

Names a specific verb (compute) and the exact set of derived quantities (area, perimeter, volume, surface area), which distinguishes it from the sibling converters like area_convert and volume_convert. It does not enumerate the supported shapes, but the shape parameter does, so the agent can still identify the tool.

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 statement of when to use this versus the many adjacent numeric/conversion tools (area_convert, volume_convert, evaluate_math, math_eval). The agent must infer that this computes geometry rather than converting units, and no prerequisites or exclusions are given.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources