Skip to main content
Glama
Sign In
RushDB MCP Server

RushDB MCP Server

Official
by rush-db
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

getJoinCandidates

Read-only

Identify likely references between labels or within a label by matching property names and exact value containment, returning confidence and evidence to guide joins before relationship data exists.

Instructions

Which properties reference records of another label (or the same one), found from property names and exact value containment, with evidence (matched values and records, coverage). RushDB Cloud only. Use it to learn how labels connect when the data has no relationships yet, e.g. before joining in a query. Returns [{ source, target, reasons, relationshipType, confidence, evidence, rationale }].

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "getJoinCandidates"
  }
}

Input Schema

NameRequiredDescriptionDefault
labelsNoOnly candidates touching these labels.
minConfidenceNoLowest confidence returned (default 0.5).

Output Schema

NameRequiredDescriptionDefault
candidatesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.1.1

TDQS

A3.9/5.0
Behavior4/5

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

Beyond the readOnly/non-destructive annotations, the description discloses an availability constraint ('RushDB Cloud only') and reveals the heuristic nature of the output via confidence, evidence, and rationale, signalling these are inferred candidates rather than authoritative edges. It does not discuss cost, performance, or pagination behavior.

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 core capability is front-loaded in the first clause, with usage and availability following. The evidence concept is stated twice (once parenthetically, once in the returned field list), which is mild redundancy but not enough to hurt readability.

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 two-parameter, read-only discovery tool with a full output schema and annotations, this covers purpose, trigger, availability, and rough output shape. The remaining gaps (confidence scale, behavior when labels is omitted) are minor.

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 coverage is 100%, so both parameters are already documented, and the description only loosely echoes them ('another label (or the same one)' for labels, confidence for minConfidence). It does not explain the confidence scale or what filtering by labels actually excludes, so it adds little beyond 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 capability: finding which properties reference records of another (or the same) label via property-name matching and exact value containment. That is clearly distinct from sibling tools like findRelationships or analyzeRelationshipPatterns, though those siblings are never named for contrast.

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 concrete when-to-use: 'learn how labels connect when the data has no relationships yet, e.g. before joining in a query.' That is a clear situational trigger, but there is no explicit when-not or named alternative (e.g. when relationships already exist, use findRelationships).

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

Deploy Server

Other Tools