Skip to main content
Glama
Sign In
LLMxRay-MCP

LLMxRay-MCP

by LogneBudo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

Estimate my prompt

estimate_my_prompt
Read-onlyIdempotent

Check if a prompt fits the loaded model's context, how much headroom remains for the answer, whether it sits in VRAM, and how much prompt cache reuses before sending.

Instructions

Before sending a prompt of N tokens: whether it fits the context the model is loaded with and the headroom left for the answer. Also whether the model sits in video memory, and how much of the prompt the cache would reuse, from this client's last turn on that model. Use it when a prompt grows, before raising num_ctx, or before switching model. For what is installed use list_local_models; for what actually happened use read_my_last_turn. model: a pulled model name, "gemma4" or "gemma4:latest"; unknown names get the list of pulled ones. prompt_tokens: 1 to 2000000, your estimate of the prompt size. client: your X-LLMxRay-Client name, so the cache estimate uses your own last turn. Needs Ollama reachable; the cache line needs LLMxRay running (npx llmxray). Under a second. No model is loaded or called.

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": {
      "model": "<model>",
      "prompt_tokens": "<prompt_tokens>"
    },
    "name": "estimate_my_prompt"
  }
}

Input Schema

NameRequiredDescriptionDefault
modelYesA pulled model name, with or without the tag.
clientNoSubstring of the client label, for the cache estimate. Omit for the last caller.
prompt_tokensYesSize of the prompt you intend to send, in tokens, 1 to 2000000.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.8.9
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Addedv0.8.6

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the read-only/idempotent annotations, it discloses dependency requirements (Ollama must be reachable; the cache line needs LLMxRay running via npx llmxray), latency (under a second), and the critical side-effect guarantee that no model is loaded or called. This is exactly the extra context annotations cannot carry.

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?

Front-loaded with the core question and followed by usage, per-parameter notes, and operational constraints. The prose is dense and slightly run-on ('the headroom left for the answer'), but every clause carries information and nothing is padded.

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, so the description carries the return-value burden itself, and it does so by naming the four things returned. Dependencies, latency, and non-side-effects are all covered, leaving nothing an agent needs to invoke it correctly.

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 baseline is 3, but the description adds real semantics: unknown model names return the list of pulled ones, prompt_tokens is 'your estimate of the prompt size', and client scopes the cache estimate to your own last turn. These clarify intent beyond the schema's terse field docs.

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 (estimate) and resource (my prompt) and enumerates the exact outputs: context fit, headroom for the answer, whether the model sits in VRAM, and cache reuse from this client's last turn. An agent can distinguish it from read_my_last_turn or list_local_models without opening a 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 explicit triggers ('when a prompt grows, before raising num_ctx, or before switching model') and explicitly routes to alternatives: list_local_models for what is installed, read_my_last_turn for what actually happened. Both the when and the alternatives are stated.

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

Deploy Server

Other Tools