Skip to main content
Glama
laszlopere

mcp-gnu-units

find_units

Search a database of 3000+ units for any whose name or definition contains a keyword. Get details including dimension and base value to triage results.

Instructions

Search the GNU units database for units whose name or definition contains a keyword.

Basic substring search over the 3000+ unit GNU units database (TODO ยง14.1). A hit is any unit whose name OR definition text contains query (case-insensitive); prefixes are excluded. Results are returned in the database's native order and capped at limit. Use this to discover the exact spelling of a unit before calling a conversion tool.

Returns: query (echoed), count (number of results returned), and results, a list of objects each carrying:

  • name : the unit's name.

  • definition : its definition text (the source line with the leading name token removed, so the name is not repeated).

  • kind : "unit" | "primitive" | "function" | "table".

  • dimension : the unit reduced to base-unit signature, e.g. "kg m^2 / s^3" for power โ€” use it to check whether two units are conformable without a second call. Omitted for hits that do not reduce (functions, tables).

  • base_value : the unit reduced to base/primitive units, coefficient included, e.g. "745.699 kg m^2 / s^3". Omitted alongside dimension when the hit does not reduce.

Enriching each hit lets you search AND triage in a single call instead of a follow-up lookup per unit. Example: find_units("horsepower") -> {"query":"horsepower","count":9,"results":[{"name":"horsepower", "definition":"550 foot pound force / sec","kind":"unit", "dimension":"kg m^2 / s^3","base_value":"745.7 kg m^2 / s^3"}, ...]}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of matches to return (results are in the database's native definition order; the scan stops once this many are found).
queryYesCase-insensitive substring to search for. Matches against both the unit NAME and its DEFINITION text, so 'meter' finds the `meter` unit itself as well as units defined in terms of it (e.g. `micron`). Use a short keyword like 'byte', 'pressure', or 'newton'.
Behavior5/5

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

With no annotations, the description fully carries the burden. It clearly explains behavior: substring search, case-insensitive, excludes prefixes, returns in native order, capped at limit. It also details the return structure comprehensively, including which fields are omitted for non-reducing hits.

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 lengthy but well-structured: a lead sentence, then details on search behavior, result fields, and an example. Every sentence contributes meaning. Slight redundancy could be trimmed, but it remains clear and organized.

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?

Given no output schema, the description provides a complete specification of the return format, including an example. It covers search behavior, parameters, and all result fields with edge cases. For a search tool, this is fully comprehensive.

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

Parameters4/5

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

Schema coverage is 100%, baseline is 3. Description adds value by explaining that 'query' is a case-insensitive substring matching both name and definition, with a concrete example. For 'limit', it clarifies default, maximum, and stopping condition, going beyond the schema's basic description.

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 uses a specific verb ('search') and clearly identifies the resource ('GNU units database'). It states the action: find units whose name or definition contains a keyword. This distinguishes it from siblings like 'convert' or 'info', which are for different tasks.

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?

The description explicitly tells when to use the tool: 'Use this to discover the exact spelling of a unit before calling a conversion tool.' It implies context but does not explicitly state when not to use it or list alternatives, though the sibling list provides some context.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/laszlopere/mcp-gnu-units'

If you have feedback or need assistance with the MCP directory API, please join our Discord server