Skip to main content
Glama

OpenArx

by ai.openarx

methodist_find

Find scientific records related to a claim by its relations: the relations touching it + the connected records on the other endpoints. Scientific-only; process nodes never appear. Relations default to the epistemic §7 set (support/extend/qualify/refute/background/shared_evidence/same_as); pass relation_class="engineering" (or "all") to include the engineering dependency graph (ENG_* depends_on/satisfies).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
run_idNoOptional. The active methodist run_id (as returned by the methodist diagnose / get_current_dose door). Pass it whenever you call this tool while working inside a run, so the call is attributed to that run for the §8 usage crosscheck — attribution is run-anchored, so it stays correct even if your access token refreshes mid-run. Must be YOUR run: a run_id owned by a different principal, or a non-existent run_id, is rejected.
from_idYes
subtypeNonarrow to one relation subtype, e.g. support / extend / depends_on / satisfies
directionNo'out' = relations where from_id is the source; 'in' = from_id is the target. This filters the READ; it is not the `direction` field stored on a relation record, which is a different thing that happens to share the name — never copy in/out into a record you submit.
latest_onlyNodrop superseded records — return only current chain-heads (default off)
relation_classNorelation class scope — default epistemic (§7); engineering = ENG_* dependency edges; all = both
collapse_same_asNocollapse same_as-equivalent connected claims to one canonical (earliest), carrying same_as_members (default off)

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries full burden and discloses important behaviors: process nodes excluded, default relation set, direction parameter clarification, and run_id ownership validation. It does not cover pagination or rate limits, but overall transparency is good.

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 a single dense paragraph but front-loads purpose and efficiently covers key details. It could be slightly more structured with bullet points, but every sentence is informative and no words are wasted.

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?

Given the complexity (7 parameters, no output schema), the description adequately explains purpose, defaults, and parameter nuances. It conceptually describes the output (relations and connected records), though it lacks explicit return format details. Still, it is sufficiently complete for effective use.

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 description coverage is high (86%), so baseline is 3. The description adds value beyond the schema by clarifying the direction parameter's distinct meaning and explaining run_id attribution. This extra context justifies a score of 4.

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 clearly states the tool finds scientific records related to a claim via relations, specifying scientific-only and excluding process nodes. It distinguishes from siblings by detailing the default epistemic relation set and the option for engineering relations, making it distinct from related tools like find_related_claims.

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 explains default behavior and how to customize with relation_class, but does not explicitly state when to use this tool versus alternatives like find_evidence or find_related_claims. However, it provides clear context for its use within the methodist family.

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

All OpenArx toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.7/5.0
Disambiguation4/5

Most tools have clear distinct purposes, but some overlap exists between explore_topic and methodist_explore_topic, and between find_related and find_related_claims. Descriptions generally differentiate them well.

Naming Consistency4/5

Tool names follow a consistent verb_noun pattern with methodist_ prefix for research workflow tools, though 'paginate' and 'methodist' (without underscore) are minor deviations.

Tool Count2/5

35 tools is too many for a single server's scope, exceeding the 25+ threshold. The server combines two major workflows (literature search and research process guidance), which would be better split.

Completeness4/5

The tool set covers a wide range of operations: multiple search modes, document submission and versioning, topic exploration, evidence checking, methodology search, and research guidance. Minor gaps include lack of document deletion or metadata update without new version.

Resources