Skip to main content
Glama

call_any_read_api_of_docstar

Read-onlyIdempotent

Read from any DocStar API endpoint with a GET request for the signed-in user and return { status, ok, headers, data }. Use it for lookups no dedicated tool covers, once you know the exact endpoint: from the quickstart-docstar skill's recipes, or looked up with get_docstar_api_docs. Never guess a URL. Pass the full url with path variables filled in, the headers the endpoint's docs list, and query params in query (not in the url). Send the endpoint's auth header with an empty value "": the user's token is filled in automatically. Never put a token there yourself.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>",
      "headers": "<headers>"
    },
    "name": "call_any_read_api_of_docstar"
  }
}

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.7/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds genuinely new behavior: the return shape, and the credential mechanism where the auth header must be sent with an empty value so the signed-in user's token is injected, with an explicit warning never to place a token there. That is auth handling an agent could not infer from structured fields.

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?

Roughly five short sentences, front-loaded with purpose and payload shape before the operational rules. Every clause is actionable: endpoint sourcing, no-guessing rule, URL construction, header construction, token placeholder.

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?

There is no output schema, but the description declares the return envelope explicitly, and the three-parameter input model is fully explained including the non-obvious auth placeholder. For an open-world generic-call tool, nothing an agent needs to invoke it correctly is missing.

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% and the schema already documents url, query, and headers including the empty-value auth convention, so the description mostly restates it. It reinforces the critical split (path variables in `url`, query params in `query`) but adds no syntax or format meaning beyond the schema, so the baseline of 3 applies.

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 specific verb and scope: a GET read against any DocStar API endpoint on behalf of the signed-in user, and names the response envelope { status, ok, headers, data }. This clearly separates it from the sibling writable `call_any_api_of_docstar` and from the documentation-discovery tools `get_docstar_api_docs` / `search_docstar_docs`.

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 inclusion rule (lookups no dedicated tool covers, once the exact endpoint is known) plus the two legitimate sources of that endpoint: the quickstart-docstar skill recipes or get_docstar_api_docs. It also states a hard prohibition, 'Never guess a URL', which is exactly the failure mode an open-world tool invites.

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