Query JSON with JSONPath-lite ($.a[*].b, ..key). One of url or json.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | JSON URL (alt. to json). | |
| json | No | Raw JSON (alt. to url). | |
| limit | No | Max results. | |
| query | Yes | e.g. '$.users[*].name'. | |
| headers | No | Headers to forward (Authorization, Cookie…). |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Input schema / properties / headers / descriptionAdded value: +"Headers to forward (Authorization, Cookie…)."Input schema / properties / json / descriptionAdded value: +"Raw JSON (alt. to url)."Input schema / properties / limit / descriptionAdded value: +"Max results."Input schema / properties / url / descriptionAdded value: +"JSON URL (alt. to json)."Input schema / properties / headersAdded value: +{
+ "type": "object"
+}Input schema / properties / json / descriptionRemoved value: -"Raw JSON string to query (alternative to url)."Input schema / properties / limit / descriptionRemoved value: -"Max number of results to return (default 100, max 1000)."Input schema / properties / query / descriptionPrevious value: -"JSONPath-lite expression. Examples: '$.users[*].name', '$..price', '$.items[?(@.stock > 0)].id', '$.store.books[0].title'"New value: +"e.g. '$.users[*].name'."Input schema / properties / url / descriptionRemoved value: -"URL returning JSON to query (http/https)."Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a safe read operation. The description adds that JSONPath is 'lite' and requires either a URL or raw JSON, but does not disclose behavior like error handling, return format, or pagination. It adds some context beyond annotations but not rich behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the core action ('Query JSON with JSONPath-lite') and includes essential usage constraints without redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters and no output schema, the description provides minimal but sufficient context for basic usage, but omits details about return values, error behavior, or handling of limits/headers. Given the tool's simplicity and read-only annotation, the gap is acceptable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful syntax examples for the 'query' parameter and clarifies the mutual exclusivity of 'url' and 'json' beyond the schema's 'alt' note, effectively enhancing parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries JSON with JSONPath-lite, providing specific syntax examples ($.a[*].b, ..key). This distinguishes it from siblings like csv_query and fetch_extract by focusing on JSON-specific querying with a clear verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description notes 'One of url or json' as an input requirement, it provides no explicit guidance on when to choose this tool over alternatives such as csv_query or fetch_extract. No exclusions or compared contexts are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Several tools overlap in fetching and processing web content (fetch_extract, fetch_html, fetch_metadata, html_to_markdown), which could confuse an agent. However, descriptions clarify output types, so most tools are distinguishable.
Names follow mixed conventions: verb_noun (fetch_html, remove_background), noun_verb (csv_query, rss_parse), and noun_noun (tool_catalog, screenshot_url). Each name is descriptive, but the lack of a consistent pattern makes it harder to guess tool names.
With 17 tools, the count is slightly above the ideal 3-15 range but still manageable. The inclusion of 5 meta-tools (pricing, tool_catalog, task_recipes, memory_snippet, use_tool) inflates the count but serves a discovery purpose.
The toolkit covers a broad range of web and data tasks (fetch, parse, query, convert, image, SEO). Minor gaps exist (e.g., no OCR, no image editing), but use_tool can dynamically access additional tools, mitigating incompleteness.