Skip to main content
Glama

OpenArx

by ai.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
NameRequiredDescriptionDefault
limitNo
detailNo'minimal' = section + summary only. 'standard' = + content. 'full' = + entities/selfContained/totalChunksstandard
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.
sectionNoSection name or path prefix (e.g. "Methods" or "3.")
entitiesNoSoft 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.
searchIdNosearchId from a prior search / search_keyword / search_semantic response. Required when chunkOrder=importance.
chunkOrderNo'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
documentIdYesDocument UUID (from a prior search result)
contentTypeNoSoft 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.

TDQS

A3.7/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It mentions 'Direct PG fetch — no vector search latency' but does not explicitly state read-only behavior, error handling, or authentication needs. The schema parameter descriptions add some behavioral context, but the main description lacks comprehensive disclosure.

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 description is two sentences, front-loading the purpose and usage. Every sentence adds value with no redundancy. It is appropriately sized and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description provides usage context and performance note, but lacks information about the return value (no output schema). Given the complexity (9 parameters), the description should be more complete. It does not explain what the response looks like or how to interpret results.

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 89%, so the schema already documents parameters well. The description mentions filters (content type, section, entity mention) but does not add significant meaning beyond the schema. Baseline 3 is appropriate.

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 clearly states 'Retrieve specific chunks from a known document with filters', indicating the verb (retrieve), resource (chunks), and context. It mentions specific filters but does not explicitly differentiate from sibling tools like get_document, though the name and context imply the difference.

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 explicitly says 'Use after search or find_methodology returned a relevant paper and you want more chunks from it without re-running search', providing clear when-to-use guidance. It does not mention when not to use or alternatives, but the context is sufficient.

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