Skip to main content
Glama

response_slice

Read-onlyIdempotent

Extract targeted fragments from saved API response JSON files using logical jsonPath or line ranges, avoiding manual reads.

Instructions

response_slice

Extracts a specific fragment of a saved JSON response file by logical jsonPath or by line range.

When to use

Use this tool when you know which object, array, or field you want to inspect inside a large response. Prefer jsonPath over line numbers because it is stable and descriptive.

When NOT to use

  • Do NOT use bash, cat, head, tail, file, open, less, more, or any external command to read fileRef.path.

  • Do NOT read the file manually. This tool is the only allowed way to extract fragments from saved response files.

Parameters

  • path (required): The absolute file path from fileRef.path returned by invoke.

  • jsonPath (optional): Logical path such as data.0, users.3.name, or company.departments.engineering.employees.0. Use gjson dotted syntax. Leave empty (or use @this) to target the root value — for a root array this returns its first element.

  • line (optional): 1-based line number to center the fragment on. The tool returns around lines above and below.

  • range (optional): Exact line range as start-end (for example 120-240).

  • around (optional): Number of lines to include around line. Default is 20.

Returns

  • slice.lines: 1-based line range of the returned fragment.

  • slice.value: the extracted JSON value parsed into a structured object.

  • slice.fragment: raw JSON text when the fragment is small enough to include.

  • slice.context: object, array, or value describing what was extracted.

  • slice.isComplete: true when value is a valid JSON fragment.

  • slice.nextPath / slice.prevPath: suggested adjacent paths for array navigation.

  • slice.nextLine / slice.prevLine: suggested line numbers for line-based navigation.

  • fileRef: only present when the extracted fragment exceeded the size limit and was saved to disk.

Example

response_slice({
  "path": "/.../responses/...json",
  "jsonPath": "pets.0"
})

Then continue with pets.1, pets.2, etc. using slice.nextPath.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
lineNooptional,1-based line number to center the fragment on
pathYesrequired,Absolute path returned in fileRef.path
rangeNooptional,Line range as start-end (e.g. 120-240)
aroundNooptional,Lines to include around line (default 20)
jsonPathNooptional,Logical path to the value (e.g. data.3.name)
Behavior5/5

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

Beyond the readOnly/idempotent annotations, it documents return fields (slice.lines, slice.value, slice.fragment, slice.context, slice.isComplete, slice.nextPath/prevPath) and edge behaviors such as root array returning first element, default around=20, and fileRef only when size limit is exceeded.

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 well-structured with a clear purpose, usage criteria, parameter explanations, return values, and a concrete example. It front-loads the main purpose and keeps every section purposeful.

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?

For a tool with no output schema, the description fully explains inputs, defaults, return fields, and navigation. It also covers when not to use the tool and provides a working example, making it complete for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, yet the description adds gjson dotted syntax, @this sentinel, root-array behavior, line/range/around defaults, and example path expressions. This significantly exceeds the schema's brief property descriptions.

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 opens with 'Extracts a specific fragment of a saved JSON response file by logical jsonPath or by line range,' providing a specific verb, resource, and method. It clearly distinguishes itself from response_outline/response_filter by focusing on direct extraction of a known fragment.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Contains explicit 'When to use' and 'When NOT to use' sections. It instructs agents to use it when a specific object/array/field is already identified, prefer jsonPath over line numbers, and prohibits using shell commands to read the file.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mmadfox/swag2mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server