3GPP Scout

Get Sections Batch

get_sections_batch

Read-only

Read up to 10 clauses in one call, from one or several documents.

Each clause comes back as get_sections returns it with latest=true (one version: the given version, else the newest of the given release, else the newest indexed), plus its sub-clauses as numbers and titles only (all of them up to 40, else the direct ones). Results are in request order and each has a status: a missing clause does not fail the call; it gets nearest_sections, the closest existing clause numbers.

Quota: for REST and MCP this call counts as one request per clause (requests_counted), the same as calling get_sections once per clause. If fewer requests remain than clauses asked for, it fails with 402 before reading anything.

Excerpt limit: each clause carries at most 2,000 words of spec text, cut like get_sections with truncated=true and truncation_reason="word_limit"; read the rest at official_url.

Dates for prior art: each clause has provenance (3GPP archive upload time and approving TSG plenary of its version). available_before applies to every clause, like get_sections with latest=true: a clause that only exists in later versions gets status no_version_before_cutoff.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`sections`	Yes	1 to 10 clauses, from one or several documents.
`available_before`	No	Only versions uploaded to the 3GPP archive before this date (YYYY-MM-DD; before 00:00 UTC, so the day itself is excluded), e.g. a patent application's priority date. A version whose upload time is unknown is left out. Usually one version per release of each spec is indexed (the newest in that release, Rel-15 onward), so a release appears only if that version predates the cutoff; older versions are in the 3GPP archive but not searchable here. Applies to every clause: a clause without version reads the newest version uploaded before the date.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`results`	Yes
`requests_counted`	Yes	API requests this call counted toward the monthly quota: one per clause for REST and MCP.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 8, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Discloses behavior well beyond the readOnlyHint/destructiveHint annotations: one-request-per-clause quota accounting, a pre-read 402 failure when quota is insufficient, per-clause status handling for missing clauses (nearest_sections), the 2,000-word excerpt cap with truncation flags, and provenance/available_before semantics. This is the kind of context an agent cannot derive from structured fields.

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?

Front-loaded with the core action, then organized under bold headers (Quota, Excerpt limit, Dates for prior art). It is dense and slightly long, but nearly every sentence carries behavioral detail that would otherwise be invisible.

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

Completeness5/5

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

An output schema exists and annotations cover the safety profile, yet the description still explains return shape (statuses, sub-clauses, truncation) sufficiently for correct invocation. Nothing an agent needs to call this batch tool correctly is missing.

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 100%, so the baseline is 3, but the description adds genuine semantics: the version-then-release-then-newest fallback chain, that available_before applies uniformly to every clause, and that results follow request order with per-clause statuses. This goes beyond restating the schema.

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 ('Read'), resource ('clauses'), and scope ('up to 10 in one call, from one or several documents'). The batching scope implicitly distinguishes it from the single-clause sibling get_sections_sections_get without needing to name it.

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 quota paragraph tells the agent the cost is identical to calling get_sections once per clause, which is useful decision context, but there is no explicit statement of when to prefer this batch call over the single-clause sibling or when-not to use it. Usage is only implied.

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

All 3GPP Scout 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.