Skip to main content
Glama
dfch

io.github.dfch/biz-dfch-asdste100mcp

Official
by dfch

word_fuzzy

Read-only

Find approximate matches for a term when an exact lookup returns no results. Use fuzzy sequence matching to suggest similar ASD-STE100 vocabulary entries.

Instructions

Search for a term with sequence-matching (Python difflib.get_close_matches).

Results may not be obvious — use when find returns nothing and you want suggestions.

Parameters

term: The word or phrase to search for approximately.

Returns

list[Word] A (possibly empty) list of similar vocabulary entries.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
termYesThe term to look up.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv3.0.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already indicate read-only and non-destructive behavior. The description adds useful behavioral context by naming the underlying algorithm (Python difflib.get_close_matches) and warning that 'results may not be obvious,' which helps set expectations for fuzziness and potential surprises.

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 compact and well-structured, with the core purpose in the first sentence, a usage hint in the second, and a clean Parameters/Returns layout. No redundant filler or restatement of the tool name.

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?

For a one-parameter, read-only fuzzy lookup tool with an output schema, the description provides everything needed: the search behavior, when to use it, parameter meaning, and a note that the result list may be empty. Nothing important is missing.

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?

The schema already documents 'term' at 100% coverage with 'The term to look up.' The description adds meaning by specifying 'word or phrase' and clarifying that the search is approximate, which is important behavioral nuance beyond the bare schema 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 states a specific action — search for a term with sequence-matching — and clearly identifies the resource as vocabulary entries. It also distinguishes itself from the exact-search sibling by describing approximate matching and 'similar' results, so an agent can tell this apart from word_find without inspecting schemas.

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 when to use the tool: 'use when find returns nothing and you want suggestions.' This is clear and actionable. It does not explicitly rule out word_match or word_synonym, but the condition and intent are specific enough for a competent agent.

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