Skip to main content
Glama
GautamVhavle

Universal JSON Agent MCP

by GautamVhavle

unique_values

Extract distinct values matched by a JSONPath expression from a loaded JSON document and return each unique value with occurrence counts for data profiling.

Instructions

Get distinct values matched by a JSONPath expression.

Args: alias: The alias of the loaded document. expression: A JSONPath expression (e.g. "$.users[*].role").

Returns: A list of unique values with count information.

Input Schema

NameRequiredDescriptionDefault
aliasYes
expressionYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.3/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 conveys that this is a read operation ('Get') and that results include count information, but says nothing about failure behavior for an unknown alias or malformed JSONPath expression, which are the realistic failure modes for this tool.

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 purpose sentence is front-loaded, and the Args/Returns sections are terse and structured with zero filler. Every line adds information rather than restating the schema.

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?

Output schema exists, so return-value explanation is not required. For a two-parameter read tool the description is mostly adequate, but it omits how errors are surfaced and how 'count information' differs from the value_counts sibling, leaving the agent to guess at call conditions.

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 coverage is 0%, so the description must compensate. It does add real meaning for both parameters: 'alias' is tied to a loaded document, and 'expression' gets a concrete JSONPath example ("$.users[*].role"). However, it doesn't state that alias must come from list_loaded/load_json or give guidance on expression syntax scope beyond one example.

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?

States a specific verb and resource: 'Get distinct values matched by a JSONPath expression.' That is clearly distinguishable from get_value (single value) and distinct_paths (paths, not values), though it never explicitly names those siblings or how it differs from value_counts.

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

Usage Guidelines2/5

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

There is no guidance on when to use this over the near-identical value_counts or distinct_paths siblings, nor any stated prerequisites such as the document needing to be loaded first via load_json. The Args section documents inputs but not selection criteria.

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