Skip to main content
Glama

Liliphant

call_any_read_api_of_liliphant

Read-onlyIdempotent

Read from any Liliphant API API endpoint with a GET request for the user and return its response. Use it once you know the exact endpoint: look it up with get_liliphant_api_docs first to get its URL, headers, query params and body, unless the skill or a dedicated tool on this server already gives them exactly. Load the quickstart-liliphant skill first: it explains which tool to use when. For POST, PUT, PATCH and DELETE use call_any_api_of_liliphant. Pass the full url with path variables filled in, the headers the docs list, and query params in query (not in the url). For the auth header the docs name (Authorization, proxy_auth_token, x-api-key, ...), pass it with an empty value "": the signed-in user's token is filled in automatically. Never put a real or made-up token there; if the docs name no auth header, leave it out and the token is sent as Authorization. If the API needs the user to sign in, they're asked the first time. Returns { status, ok, headers, data }: the HTTP status and the response body, including error details on failure.

Input Schema

NameRequiredDescriptionDefault
urlYesFull endpoint URL with path variables replaced by real values, e.g. https://api.example.com/users/42. Put query params in `query`, not here.
queryNoQuery params as name/value pairs; an array sends the param once per item. Example: {"type": "flow", "bringflows": true}
headersYesRequest headers as name/value pairs, as the docs list them. Give the auth header (Authorization, proxy_auth_token, x-api-key, ...) an empty value "" so the signed-in user's token is filled in; never put a token here yourself. Pass {} when the endpoint needs no headers. Example: {"proxy_auth_token": "", "Content-Type": "application/json"}

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/openWorld, but the description adds genuinely new behavior: auth headers must be passed with an empty string and the signed-in user's token is injected, never a fabricated token, with a fallback to Authorization when docs name no auth header. It also discloses the interactive sign-in flow on first use and the error-detail-bearing return shape, none of which is in the annotations.

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

Conciseness4/5

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

The purpose and the docs-lookup prerequisite are front-loaded, and every sentence carries operational content (alternatives, auth trick, return shape). It is still a single dense block with a stutter ("API API") and some clauses that could be split for faster scanning.

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 generic open-world HTTP passthrough with no output schema, the description covers everything an agent needs: how to discover the endpoint spec, how to position path/query/header values, how auth is injected, what happens on first sign-in, and the { status, ok, headers, data } return shape including failure 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 the baseline is 3, but the description goes beyond it by stating the token-injection convention and the fallback rule ("if the docs name no auth header, leave it out"), plus reinforcing that query params belong in `query` rather than the URL. Most of the per-parameter mechanics are still duplicated from the schema, keeping it short of a 5.

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?

Opens with a specific verb+resource+constraint: "Read from any ... API endpoint with a GET request ... and return its response." It explicitly contrasts itself with the write sibling call_any_api_of_liliphant, which handles POST/PUT/PATCH/DELETE, so an agent can separate the two read/write tools without inspecting either schema.

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?

Gives an explicit precondition chain: look up the endpoint with get_liliphant_api_docs first, and load the quickstart-liliphant skill before use. It also names the alternative tool and the exact condition that selects it (non-GET methods), and carves out an exception when a dedicated tool already supplies the details.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources