Skip to main content
Glama

hypertune

by io.usefulapi

Run a raw GraphQL query

hypertune_query
Read-only

Run an arbitrary GraphQL query (and optional variables) against the Hypertune edge endpoint. Power-user escape hatch for full control — each Hypertune project has its own generated schema, so this handles any flag shape, nested selections, inline enum literals, or variables the convenience tools can't express. The query root field is root(context: ...).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesA complete GraphQL query string, e.g. `query { root(context: {environment: "production"}) { myFlag } }`.
variablesNoOptional GraphQL variables object matching the query's declared variables.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

readOnlyHint=true already establishes safety, and the description adds meaningful context: each Hypertune project has its own generated schema, and the query root field is root(context: ...). It does not describe error behavior or response shape, but the annotation covers the safety profile.

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?

Three sentences with no filler: the core action is front-loaded, the second sentence justifies its role as an escape hatch, and the third provides the essential root-field detail. Every sentence earns its place.

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

Completeness4/5

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

For a deliberately unconstrained raw GraphQL tool, the description explains why no fixed output shape is possible and gives the key entry-point detail. It could mention the raw response/error behavior more explicitly, but given the project-specific schema and readOnly annotation, the coverage is solid.

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 description coverage is 100%, so the parameters are already well documented. The description adds minor color about nested selections and enum literals but does not materially change how an agent should fill in query or variables beyond 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 concrete action ('Run an arbitrary GraphQL query') and a clear resource ('Hypertune edge endpoint'), then labels itself a 'power-user escape hatch'. This makes its purpose distinct from the convenience sibling tools without needing to open their schemas.

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?

Explicitly frames when to use this tool: for anything the convenience tools cannot express, such as nested selections, inline enum literals, or unusual variables. It does not name the specific sibling alternatives, but the exclusion logic is clear.

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

All hypertune toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0
Disambiguation4/5

Evaluate and get_logic are clearly distinct (resolved values vs raw logic), and query is positioned as an escape hatch. The only mild overlap is introspect and list_flags, both derived from introspection, though descriptions distinguish broad schema discovery from a flag-focused convenience list.

Naming Consistency4/5

All tools share the hypertune_ prefix and use snake_case, which gives a predictable base. The right-hand side mixes bare verbs like evaluate and query with verb-noun pairs like get_logic and list_flags, so naming is mostly consistent but not perfectly uniform.

Tool Count5/5

Five tools is a tight, focused set for a feature-flag evaluation and introspection server. Each tool serves a clear purpose and the count feels neither thin nor bloated.

Completeness4/5

The set covers the core workflows: discover schema, list flags, inspect logic, evaluate flags, and run arbitrary queries. It omits flag management mutations, but the tool descriptions suggest a query-oriented scope rather than full CRUD, so this is a minor gap at most.

Resources