Skip to main content
Glama

OpenArx

by ai.openarx
OverviewDiscussionsAdmin

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
limitNoMax CONNECTED records to return — the claims, which are 99.96% of this response by measurement; `relations` keeps its own cap. ★ DEFAULT 20, chosen by measurement: 98.9% of documents carry 20 claims or fewer and so arrive complete in one call. It is a default, NOT a ceiling — ask for more and you get more. Every answer carries total / returned / complete (and nextOffset when there is more), so a defaulted read is never mistaken for an exhausted one.
detailNoHow much of each record to return — applies to `connected` AND to `relations`. Levels DROP WHOLE FIELDS and never cut a string: 'minimal' = identity + supersede state + verification_outcome + a 200-char text_preview (a separate field that names itself a preview, with text_length beside it — never quote from it); 'standard' = + the claim itself, whole, without evidence (relations: + citation_context); 'full' (default) = everything. Measured 2026-09-17 on a 20-edge claim: full 87 270 chars, standard 63 326, minimal 45 431 before relations were levelled — relations were 91 % of minimal, now they are not.
offsetNoSkip the first N connected records. Use nextOffset from the previous answer.
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)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / detail / description
      Previous value: -"How much of each connected record to return. Levels DROP WHOLE FIELDS and never cut a string: 'minimal' = identity + supersede state, no claim text; 'standard' = + the claim itself, whole, without evidence; 'full' (default) = everything. Measured ~145 / ~658 / ~1281 characters per record."New value: +"How much of each record to return — applies to `connected` AND to `relations`. Levels DROP WHOLE FIELDS and never cut a string: 'minimal' = identity + supersede state + verification_outcome + a 200-char text_preview (a separate field that names itself a preview, with text_length beside it — never quote from it); 'standard' = + the claim itself, whole, without evidence (relations: + citation_context); 'full' (default) = everything. Measured 2026-09-17 on a 20-edge claim: full 87 270 chars, standard 63 326, minimal 45 431 before relations were levelled — relations were 91 % of minimal, now they are not."
  2. Changed1 schema field changed
    • changedInput schema / properties / limit / description
      Previous value: -"Max CONNECTED records to return — the claims, which are 99.96% of this response by measurement; `relations` keeps its own cap. Omit for all of them. The answer always carries total / returned / complete, so a windowed read is never mistaken for an exhausted one."New value: +"Max CONNECTED records to return — the claims, which are 99.96% of this response by measurement; `relations` keeps its own cap. ★ DEFAULT 20, chosen by measurement: 98.9% of documents carry 20 claims or fewer and so arrive complete in one call. It is a default, NOT a ceiling — ask for more and you get more. Every answer carries total / returned / complete (and nextOffset when there is more), so a defaulted read is never mistaken for an exhausted one."
  3. Changed3 schema fields changed
    • addedInput schema / properties / detail
      Added value: +{
+  "description": "How much of each connected record to return. Levels DROP WHOLE FIELDS and never cut a string: 'minimal' = identity + supersede state, no claim text; 'standard' = + the claim itself, whole, without evidence; 'full' (default) = everything. Measured ~145 / ~658 / ~1281 characters per record.",
+  "enum": [
+    "minimal",
+    "standard",
+    "full"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / limit
      Added value: +{
+  "description": "Max CONNECTED records to return — the claims, which are 99.96% of this response by measurement; `relations` keeps its own cap. Omit for all of them. The answer always carries total / returned / complete, so a windowed read is never mistaken for an exhausted one.",
+  "exclusiveMinimum": 0,
+  "type": "integer"
+}
    • addedInput schema / properties / offset
      Added value: +{
+  "description": "Skip the first N connected records. Use nextOffset from the previous answer.",
+  "minimum": 0,
+  "type": "integer"
+}
  4. First observed

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the full burden of behavioral disclosure and does a solid job: it states the output shape (relations plus connected records), the exclusion of process nodes, the default epistemic relation set with examples, and the engineering edge expansion. It could go further by disclosing pagination limits or completeness semantics, but those are already covered in the parameter schema.

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 main description is three front-loaded, information-dense sentences with no wasted words. It packs purpose, return structure, a scope exclusion, the default relation set, and the override option. It is a model of concise, structured tool documentation.

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 10-parameter tool with no output schema, the description communicates the core contract well: what is returned, what is excluded, and how to expand the default behavior. The only real gap is that the required from_id parameter is not described anywhere, though the phrase 'related to a claim' makes its likely meaning inferable.

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 90%, so the baseline is 3. The description adds a bit beyond the schema by spelling out the default epistemic relation set and the specific engineering edge types (ENG_* depends_on/satisfies), but the bulk of parameter meaning — limit defaults, detail levels, direction semantics, run_id attribution — lives in the schema, not in the tool description. That matches the baseline rather than exceeding it.

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 opens with a specific verb and resource: 'Find scientific records related to a claim by its relations', and it explains that the result contains both the relations and the connected endpoint records. It also adds a clear scope constraint, 'Scientific-only; process nodes never appear.' It does not explicitly differentiate from sibling tools such as find_related_claims or methodist_traverse, so it stops short of 5.

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 description makes the intended use case clear — finding scientific claim relations — and even gives an exclusion: process nodes never appear. It also explains when to pass relation_class='engineering' or 'all' to expand the default epistemic set. However, it names no alternative tool or explicit 'use X instead' guidance, so routing among the many find_* siblings is left to inference.

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
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