OpenArx

get_chunks

Retrieve specific chunks from a known document with filters: by content type, section, or entity mention. Use after search or find_methodology returned a relevant paper and you want more chunks from it without re-running search. Direct PG fetch — no vector search latency.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`limit`	No	Max chunks to return. Default 100. No upper bound — use offset to read a document larger than one context in successive passes.
`detail`	No	'minimal' = section + summary only. 'standard' = + content. 'full' = + entities/selfContained/totalChunks
`offset`	No	Skip the first N chunks of the ordered set. Ordering is total, so pages neither skip nor repeat.
`run_id`	No	Optional. 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.
`section`	No	Section name or path prefix (e.g. "Methods" or "3.")
`entities`	No	Soft filter by entity (case-insensitive ANY match). Chunks mentioning a listed entity return first; chunks with NO entities recorded (legacy, ~23% of corpus) are included after as 'unknown' tier rather than dropped; only chunks that have entities none of which match are excluded.
`searchId`	No	searchId from a prior search / search_keyword / search_semantic response. Required when chunkOrder=importance.
`chunkOrder`	No	'position' (default): document order. 'importance': search relevance order — requires searchId from a prior search response; falls back to position with a note when searchId is missing or expired.	position
`documentId`	Yes	Document UUID (from a prior search result)
`contentType`	No	Soft filter chunks by type (methodology / results / theoretical / experimental / survey / background / other). Matched chunks return first; legacy chunks with NULL contentType are included as 'unknown' tier (sorted after matches) — they are not silently dropped. Chunks with an explicit different contentType are excluded. Response includes strictMatchedChunks + unknownChunksIncluded counts.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedSep 4, 2026

removedInput schema / properties / detail / default
```
Removed value: -"full"
```
removedInput schema / properties / limit / default
```
Removed value: -20
```

addedInput schema / properties / limit / description

Added value: +"Max chunks to return. Default 100. No upper bound — use offset to read a document larger than one context in successive passes."

removedInput schema / properties / limit / maximum
```
Removed value: -100
```

addedInput schema / properties / offset

Added value: +{
+  "description": "Skip the first N chunks of the ordered set. Ordering is total, so pages neither skip nor repeat.",
+  "minimum": 0,
+  "type": "integer"
+}

Changed1 schema field changedSep 4, 2026
- changedInput schema / properties / detail / default
```
Previous value: -"standard"New value: +"full"
```
First observedJul 28, 2026

TDQS

A4.2/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full behavioral burden. It discloses a concrete execution trait ('Direct PG fetch — no vector search latency') and implies a read-only safety profile via 'Retrieve' and 'fetch'. It does not explicitly state non-destructiveness or describe the response shape, but the schema's parameter notes thoroughly document filter fallback and tier-ordering behavior.

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 short sentences, each earning its place: purpose, usage context, and a behavioral/performance note. Purpose is front-loaded, and nothing repeats schema content or pads the definition.

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 a rich, 100%-covered schema, the description covers the selection and invocation essentials: what it does, when to use it, and which filter parameters matter. The only gap is that no output schema exists and the description doesn't summarize the response shape, though schema parameter notes do reference response counts (strictMatchedChunks + unknownChunksIncluded).

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%, so baseline is 3. The description adds only a high-level filter taxonomy (content type, section, entity mention) that maps to contentType/section/entities. All deeper semantics — soft-filter tiers, unknown-chunk inclusion, chunkOrder fallback, run_id attribution — are already fully documented in the schema, so no compensation is needed.

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?

States a specific verb+resource: 'Retrieve specific chunks from a known document' with explicit filter dimensions (content type, section, entity mention). The phrase 'known document' and the post-search framing clearly distinguish it from sibling search/find tools that discover documents rather than retrieve parts of an already-identified one.

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?

Explicitly names the triggering context — use after `search` or `find_methodology` returned a relevant paper, when you want more chunks 'without re-running search' — which routes agents away from the obvious alternative. It stops short of listing exclusions or naming other alternatives like get_document (whole-document retrieval) or paginate, so a full when-not-to-use boundary is missing.

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

All OpenArx 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.

get_chunks

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources