Skip to main content
Glama
LogneBudo

LLMxRay-MCP

by LogneBudo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

Diagnose my turns

diagnose_my_turns
Read-onlyIdempotent

Inspect Ollama call turns to find prompt cache loss, context overflow, partial CPU usage, or tool schema crowding, and get prioritized fixes.

Instructions

What went wrong, if anything, in the Ollama calls your client sent through LLMxRay on port 11435, judged over several turns. It looks for a prompt rejected or silently cut by the context, the cache lost on every turn or on one turn, a model partly on CPU, and tool schemas crowding the prompt. Call it after a few turns, and again after a change. For one turn in numbers use read_my_last_turn. For which model or context fits use list_local_models. Returns text. First one line per client seen, then one finding per line tagged [high], [medium] or [low], each ending with the fix. It says so when nothing stands out, and explains how to route through 11435 when no turn was seen. client: your X-LLMxRay-Client name; without it on a shared machine you read every tool's turns. since_minutes: 1 to 10080, minutes since your change. They combine. Needs LLMxRay running (npx llmxray) and says so if not. Under a second, from records already kept. No model is called.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
clientNoPart of the client label or id as LLMxRay shows it (for example "VS Code Copilot", "python-requests", or the X-LLMxRay-Client header you sent). Case-insensitive substring. Omit for all clients.
since_minutesNoOnly turns from the last N minutes. Omit for every turn LLMxRay has kept.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.8.2
    • changedInput schema / properties / client / description
      Previous value: -"Part of the client label or id as LLMxRay shows it (for example \"VS Code Copilot\", \"python-requests\"). Omit for all clients."New value: +"Part of the client label or id as LLMxRay shows it (for example \"VS Code Copilot\", \"python-requests\", or the X-LLMxRay-Client header you sent). Case-insensitive substring. Omit for all clients."
    • changedInput schema / properties / since_minutes / description
      Previous value: -"Only turns from the last N minutes."New value: +"Only turns from the last N minutes. Omit for every turn LLMxRay has kept."
  2. First observedv0.8.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare read-only/idempotent/non-destructive, and the description goes well past them: it discloses the latency (<1s), that it reads stored records rather than calling a model, the output shape (one line per client, then findings tagged [high]/[medium]/[low] each ending with a fix), and the no-op behavior when nothing stands out. This is exactly the extra context annotations can't 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 purpose, then alternates, output, parameters, and prerequisites in a logical order with no filler. It runs slightly long and the parameter sentence is compressed into a tag-like style, but nearly every clause carries information an agent needs.

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?

Despite having no output schema, the description fully covers the return format so the agent can interpret results. It also covers prerequisites, runtime cost, failure modes, and default/override behavior for optional parameters, leaving no material gap.

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. The description still adds value: it gives the concrete numeric range for since_minutes (1 to 10080), explains the shared-machine consequence of omitting client (you read every tool's turns), and notes that the two parameters combine.

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 (diagnose) and resource (Ollama calls your client sent through LLMxRay), and enumerates exactly what it hunts for: rejected prompts, lost cache, CPU-offloaded model, tool schemas crowding context. It explicitly differentiates from siblings by naming read_my_last_turn and list_local_models with their respective scopes.

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?

Explicit when-to-use ("after a few turns, and again after a change") plus explicit alternative routing ("For one turn in numbers use read_my_last_turn", "For which model or context fits use list_local_models"). The prerequisite (needs LLMxRay running via npx llmxray) and error path (explains routing through 11435 when no turn was seen) are also 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