Skip to main content
Glama

persian_fuzzy_search

Fuzzy-match a query against candidate strings while treating Persian/Arabic letter variants, diacritics, ZWNJ, and digit styles as equal; get ranked matches with scores.

Instructions

Fuzzy-match a query against candidate strings, treating Arabic/Persian letter variants (ي/ی, ك/ک, آ/ا), diacritics, ZWNJ and digit styles as equal. Returns ranked matches with scores.

Input Schema

NameRequiredDescriptionDefault
limitNo
queryYes
thresholdNo
candidatesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.0

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It does disclose a meaningful trait — that variant characters, diacritics, ZWNJ and digit styles are treated as equal, i.e. matching is deliberately lenient — and hints at output ordering (ranked with scores). It omits error behavior, defaults, and any performance constraints for the 5000-item candidate cap.

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 tight sentences: the matching semantics and normalization rules come first, the return shape second. No filler, no restatement of the tool name, and every clause carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The core semantic contract (what counts as a match, what comes back) is covered, but for a 4-parameter tool with 0% schema coverage and no output schema or annotations, the description should at minimum explain threshold/limit semantics and the score range. Adequate but with a clear documentation gap on the tuning parameters.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate, but it only obliquely covers 'query' and 'candidates'. It says nothing about 'threshold' (the 0–1 match cutoff) or 'limit' (max results returned), which are the two parameters most likely to be misused.

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+resource ('Fuzzy-match a query against candidate strings') plus the exact normalization scope (Arabic/Persian letter variants, diacritics, ZWNJ, digit styles) and the return shape (ranked matches with scores). This is clearly distinguishable from siblings like normalize_persian_text, which transform a single text rather than rank a candidate list.

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 use case is implied by the phrasing 'query against candidate strings', so an agent can infer this is for matching/searching rather than normalizing. However, there is no explicit when-to-use guidance, no statement about when to prefer normalize_persian_text, and no mention of prerequisites or limits on candidate size.

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