Skip to main content
Glama

geometry

Deterministic 1D/2D/3D geometry: distances, intersections, areas, volumes, angles, convex hull, point-in-polygon, rotations. Closed-form (not iterative), exact up to floating-point rounding, identical output for identical input. Use it instead of doing geometry yourself. Pass {op, ...args} with op one of: 1D: dist1,midpoint1,divide_point,divide_ratio,harmonic_conjugate,interval_length,interval_midpoint,interval_intersect,interval_union,interval_hull,interval_overlap_length,interval_contains,point_between | 2D: dist2,midpoint2,lerp2,line_from_points,point_line_distance,point_segment_distance,project_point_line,line_intersect,line_intersect_points,segment_intersect,segment_length,angle_3points,angle_vectors,line_angle,triangle_area,triangle_centroid,triangle_incenter,polygon_area,polygon_perimeter,polygon_centroid,point_in_polygon,convex_hull,polygon_is_convex,circle_from_3points,point_circle_position,circle_line_intersect,circle_circle_intersect,circle_measure,sector_area,rotate_point,reflect_point_line,scale_point,parallel_through,perpendicular_through,triangle_circumcenter,triangle_orthocenter,triangle_excenters,triangle_five_centers,euler_line,triangle_nine_point_circle,triangle_euler_inequality,triangle_medians,triangle_altitudes,triangle_bisector_lengths,cevian_concurrent,menelaus_collinear,power_of_point,radical_axis,polar_of_point,pole_of_line,ptolemy,miquel_point,napoleon_triangles,pick_theorem,cocircular_check,minimum_enclosing_circle,circumcircle | 3D: dist3,midpoint3,lerp3,plane_from_3points,point_plane_distance,project_point_plane,reflect_point_plane,coplanar,point_line_distance3,project_point_line3,line_plane_intersect,line_line_relation,plane_plane_intersect,tetra_volume,polygon_area3,face_normal,mesh_volume,sphere_from_4points,sphere_line_intersect,sphere_plane_intersect,sphere_measure,angle_vectors3,angle_line_plane,angle_plane_plane,rotate_axis,cross3,triple_product,tetrahedron_geometry,monge_point | any: distance,midpoint,lerp,norm,normalize,dot,cross,project,reject,translate,centroid,bbox,diameter,stewart_theorem,law_of_cosines,law_of_cosines_sas,law_of_sines,solve_triangle,heron_area,brahmagupta,golden_ratio,regular_polygon,regular_tetrahedron,newton_polytope,tropical_degree_bound,tropical_system_bound,regular_subdivision,bernstein_bound,tropical_bezout_bound,sphere_equation,polynomial_equation. The remaining args are passed flat and depend on op (p, q, a, b, c, d, r, poly, pts, angle, lambda, center, axis, segment, a1,b1,c1,a2,b2,c2, ...). Send an unknown op to receive the full catalog with every signature. READ trust.trustLevel: exact = safe to use directly; definitely_none = computed proof that there is NO intersection, safe to state as a conclusion; degenerate = the INPUT is degenerate (parallel / collinear / coplanar / coincident), do NOT invent a value — report the degeneracy instead.

Input Schema

NameRequiredDescriptionDefault
opYesGeometry operation name. See the tool description for the full list, or send an unknown value to receive the catalog with signatures.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/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 richly: it states the tool is closed-form, deterministic, exact to floating-point rounding, and returns identical output for identical input. It also explains the critical trust.trustLevel field with exact, definitely_none, and degenerate semantics, including what to report for degenerate inputs.

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 description is front-loaded with purpose, determinism, invocation pattern, and trust semantics before the long op catalog. The catalog is unusually long but necessary because the schema does not enumerate op values. It is dense rather than padded, though the length is significant.

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 complex computational tool with no output schema, the description supplies the op catalog, argument convention, and the important trust.trustLevel semantics. It does not fully describe the return shape or error behavior beyond trust, so an agent still has minor gaps about output structure, but the critical invocation and safety context are present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the schema only defines op as a string. The description goes far beyond it by listing the valid op values grouped by dimension, explaining that remaining args are passed flat and depend on op, and pointing to an unknown-op catalog for full signatures. This is essential parameter semantics not available in the schema.

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?

The description names a specific domain (deterministic 1D/2D/3D geometry) and enumerates concrete operations such as distances, intersections, areas, and hulls, so the tool's purpose is unambiguous. However, it does not distinguish itself from sibling tools like solve or poly_roots, leaving overlap for an agent to infer.

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?

It explicitly says to use the tool instead of doing geometry manually, and it explains how to invoke it via {op, ...args}. It also provides a routing fallback: sending an unknown op returns the full catalog with signatures. No when-not or sibling-alternative guidance is given, but the core usage context is clear.

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.