DolfDarts Dart Game Encyclopedia

Define a darts term

define_term

Read-only

Look up a darts glossary term (bust, oche, checkout, madhouse, Shanghai, ...) and get its sourced plain-text definition, origin when a source states one, source links and the dolfdarts.com glossary URL with the term's #anchor. Optional locale (any of the 12 released language codes, default en). An unknown term returns found:false with up to 5 closest terms, not an error.

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": {
      "term": "<term>"
    },
    "name": "define_term"
  }
}

Input Schema

Name	Required	Description	Default
`term`	Yes	Darts term to define, e.g. 'bust', 'oche', 'madhouse', 'Shanghai'. Case and diacritics are ignored; the term name and its URL slug are matched.
`locale`	No	Language of the glossary to search and answer in (default 'en'). The term is matched against that locale's own wording.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 4, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the read-only and closed-world annotations, it discloses sourced plain-text output, conditional origin data, source and anchored glossary links, and a non-error unknown-term path returning found:false with up to five closest terms. These details are especially useful because there is no output schema, and nothing conflicts with the annotations.

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?

Three compact sentences front-load the operation and outputs, then cover localization and the important not-found behavior. The wording is dense, but each sentence supplies actionable information without a substantial digression.

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 simple two-parameter read-only lookup, the definition supplies scope, result contents, localization, and unknown-term behavior, compensating well for the absence of an output schema. Together with the fully documented schema and safety annotations, it gives an agent enough information to select and invoke the tool correctly.

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 description coverage is 100%, and both parameters already document matching behavior, examples, locale values, response language, and the default. The description's examples and "12 released language codes, default en" mostly restate that schema information rather than adding new invocation semantics, so the high-coverage baseline applies.

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 and resource—"Look up a darts glossary term"—and identifies the result as a sourced definition with origin information and links. That glossary-definition scope clearly separates it from siblings concerned with rules, checkouts, setups, and games.

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 gives a clear use context: defining a darts term, optionally in one of the released locales, and explains what happens for an unknown term. It does not explicitly say when not to use it or route agents to get_dolf_rules or get_checkout for non-glossary questions, so alternative-selection guidance remains incomplete.

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

All DolfDarts Dart Game Encyclopedia tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?