Skip to main content
Glama
NicolaSpadari

rest-api-mcp

rest_extract

Execute an HTTP request to extract specific fields using dot-notation paths. Returns only the extracted data, simplifying response handling.

Instructions

Execute an HTTP request, then extract specific fields using dot-notation paths. Returns only the extracted data. Example: fields ["data.items[].name", "meta.total"]. Base URL: https://api.example.com/v1. AUTONOMOUS CONTEXT RESOLUTION — When the endpoint comes from code analysis (feature-port, migration, Vuex store dispatch, API service file): DO NOT call blindly with missing parameters. First investigate the source code context:

  1. Path params (:id, :slug) — find actual values in component data, props, route params, or hardcoded in the store action

  2. Query params — inspect the Vuex action, API service call, or component for the params/query object passed to the request

  3. Request body — check what payload is dispatched or composed in the action

  4. If a value is purely dynamic (e.g. user-selected at runtime), use a representative test value and document the assumption. The goal is to make a real API call that returns representative data for type extraction.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyNoRequest body (for POST/PUT/PATCH)
queryNoQuery string parameters
fieldsYesDot-notation paths to extract, e.g. ["data.id", "data.items[].name", "meta.total"]. Use [] to iterate array items.
methodYesHTTP method
headersNoAdditional request headers
endpointYesPath only (e.g. "/users")
Behavior2/5

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

No annotations exist, so the description bears full responsibility. It states the tool executes HTTP requests and extracts fields but fails to disclose that methods like POST/PUT/DELETE can create or modify data. No mention of authentication, rate limits, error behavior, or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and an example, but the 'AUTONOMOUS CONTEXT RESOLUTION' section is verbose (six bullet points). While informative, it could be more concise or separated as a usage note. The overall length is acceptable but not minimal.

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

Completeness2/5

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

With no output schema, the description should detail return format beyond 'Returns only the extracted data.' It omits error handling, authentication (likely relying on rest_set_token), status codes, and the structure of extracted results. The long resolution instructions do not compensate for missing behavioral and output details.

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 coverage is 100% so baseline is 3. The description adds value by explaining dot-notation syntax with an example, noting [] for array iteration, and specifying that endpoint is path-only. It also clarifies usage via the autonomous resolution block, though some parameter details remain schema-level.

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 clearly states the tool executes an HTTP request and extracts specific fields using dot-notation paths, distinguishing it from siblings like rest_request (full response) and rest_describe (schema). The example reinforces the purpose.

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 provides explicit guidance for autonomous context resolution when endpoints come from code analysis, including steps to investigate parameters before calling. It implies usage for field extraction rather than full responses, but does not explicitly contrast with siblings or state when not to use.

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/NicolaSpadari/rest_api_mcp'

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