LLMxRay-MCP

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds real context beyond that: it requires LLMxRay running via npx llmxray, runs under a second, calls no model, and fails with guidance ('it says what to move') when either side has no turns. Return-format detail is left to the medians/verdict summary, so it is short of a 5.

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

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

The value proposition is front-loaded in one question ('Did a change help?'), followed by the metrics and the sibling routing table, then parameters and prerequisites. Nothing is redundant, though the four-tool enumeration is a fairly long detour for a single tool and slightly dilutes the core instruction.

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

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

With no output schema, the description still conveys what is returned (medians per metric, the delta, and a one-line cache verdict). It covers prerequisites, timing, parameter meaning, and the failure mode of insufficient turns on either side, which is everything needed to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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: split_minutes_ago is explained semantically (older = 'before', newer = 'after', set it to minutes since your change) rather than just bounded, and client is given a purpose ('so another tool's turns do not mix in'). The schema's own note that client matches a substring is not restated, so it is not a full 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a concrete verb and resource (compare turns before vs after a moment) and enumerates exactly what is computed: medians of cached share, prefill time, generation speed and prompt size, plus the difference and a one-line verdict. It explicitly positions itself against the three sibling turn-readers, so the agent can distinguish it without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the triggering situation directly: 'Use it after you changed a system prompt, keep_alive, num_ctx or the tool list.' It also maps the entire sibling family to one question each (diagnose_my_turns = verdict, read_my_last_turn = one turn in full, list_my_turns = sequence), which is an explicit alternative-selection guide.

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

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

Annotations already establish read-only, idempotent, non-destructive, closed-world, so the bar is lower, yet the description adds real behavioral detail: how findings are formatted (one line per client, then tagged [high]/[medium]/[low] each ending with the fix), that it declares when nothing stands out, that it explains 11435 routing when no turn was seen, plus prerequisites, latency, and 'no model is called'.

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

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

Front-loaded with the core question and no filler sentences, but the tool-comparison block and return-format block make it longer than strictly needed; each sentence still carries information an agent would otherwise have to infer.

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

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

No output schema exists, so the description compensates by describing the return text shape, the empty-case behavior, and the failure/routing path when LLMxRay is not running. Nothing an agent needs to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3; the description adds meaning beyond it by noting that client and since_minutes combine and by flagging the shared-machine consequence of omitting client (you read every tool's turns). It does not restate the substring semantics, which the schema already covers.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (a verdict over several turns about Ollama calls sent through LLMxRay on port 11435) and explicitly positions itself against all four sibling turn-readers with a one-line differentiator each. An agent can pick this tool without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit timing guidance ('Call it after a few turns, and again after a change') and routes the agent to list_local_models for a different question (which model or context fits). The four-tool comparison table makes when-to-use vs alternatives unambiguous.

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

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.

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.

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.

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.

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.

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.

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

Annotations already cover the safe-read profile (readOnly, idempotent, non-destructive, closed-world), and the description adds substantial operational context beyond them: requires Ollama reachable, runs under a second in two listing calls, loads no model, and the result is a snapshot that goes stale after keep_alive. It even describes the output line format and sort order.

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

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

Front-loaded with what the tool reports, then usage, then return format and constraints. Dense and largely waste-free, though the return-format paragraph is verbose for what it conveys.

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

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

With no output schema, the description carries the full burden of explaining returns and does so explicitly (machine line, 'N models pulled:', per-model lines with LOADED/VRAM verdicts). Nothing needed to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Zero parameters, so the schema baseline applies. The description confirms this by stating it takes no arguments, no model name and no filter, which prevents an agent from inventing filters, but it adds nothing beyond that confirmation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (lists Ollama models pulled on this machine) plus what is reported: size, parameters, quantisation, load state, context, VRAM fit. It explicitly distinguishes itself from siblings by noting it knows nothing about past calls, routing those to diagnose_my_turns and read_my_last_turn.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit timing guidance ("Use it before choosing a model or a context length", "call it right before deciding") and names the alternative tools for a different need (past calls). The when-not is clear: not for historical call data, and no filtering is possible.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, yet the description still adds real behavioral context: it requires LLMxRay running (npx llmxray), responds under a second, calls no model, and warns that omitting client on a shared machine exposes every tool's turns. It stops short of explaining ordering/pagination edge cases beyond 'newest last'.

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

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

Front-loaded with what it returns, then the sibling-routing matrix, then usage, then parameter notes and operational requirements. The four-tool comparison is slightly long but directly serves tool selection, so it earns its place; every other sentence is compact.

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

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

With no output schema, the description compensates by describing the returned line format field by field. Prerequisites (LLMxRay must be running), latency, filter interaction, and client-scoping behavior are all covered, which is everything needed to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 adds semantics beyond the schema: the client param is tied to the caller's X-LLMxRay-Client identity and its omission has a scoping consequence, and it states that the three filters combine. Ranges and default 20 are repeated from the schema rather than added.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb+resource (list the turns sent through LLMxRay) and enumerates exactly what each line contains: turn number, time, client, model, tokens with cached share, prefill ms, generation speed, stop reason, flags. It also positions itself against the sibling tools by naming the four turn-reading tools and the distinct question each answers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'four tools read your turns, one question each' paragraph gives explicit when-to-use routing against diagnose_my_turns, read_my_last_turn, and compare_my_turns. It goes further by naming the concrete trigger ('to see the sequence behind a finding') and the hand-off ('find when a change took effect before calling compare_my_turns with that many minutes').

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

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

Beyond the readOnly/idempotent annotations, the description discloses that nothing can be mutated through MCP, that settings live on the Live page, that LLMxRay must be running (npx llmxray), that failures name the URL tried, and that it responds in under a second. This is genuine operational context an agent cannot infer from 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.

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

Front-loaded with the return payload, then usage routing, then constraints and latency. Every sentence is load-bearing: the field list defines scope, the sibling comparison routes selection, and the failure/latency notes set expectations.

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

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 and does so by enumerating the status fields. Requirements, prerequisites, failure behavior, and latency are all covered, leaving nothing an agent needs to call this correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero arguments, so the baseline is 4. The description reinforces this with 'Takes no arguments', which is a useful confirmation but adds little semantic depth beyond an empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence names a specific verb (reads) and enumerates the exact resources returned: observe port and listen state, Ollama target and version, turn retention, disk retention of request text, start time. The line 'Those tools read the turns; this one reads the server itself' cleanly differentiates it from diagnose_my_turns and read_my_last_turn.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly states when to reach for it ('Use it first when diagnose_my_turns or read_my_last_turn answers that nothing was seen') and the alternative goal ('to confirm which Ollama your calls reach'), naming the competing siblings and the diagnostic condition that selects this tool.

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

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

Annotations only declare the safety profile (readOnly, idempotent, non-destructive, closed-world); the description adds traits beyond that: the LLMxRay runtime dependency ('Needs LLMxRay running (npx llmxray) and says so if not'), latency ('Under a second, from records already kept'), absence of side effects ('No model is called'), the output shape ('text, one fact per line'), and the empty-state behavior ('Explains how to route through 11435 when no turn was seen'). This is unusually complete behavioral disclosure for a read tool.

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

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

The fact list, sibling routing table, usage line, and parameter guidance are all load-bearing and the scope statement is front-loaded. It is dense and slightly long, and the line about routing through 11435 is terse enough to be mildly cryptic, but nothing is redundant filler.

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

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

With no output schema, the description compensates by describing the return format and empty-state behavior. It covers the runtime prerequisite, expected latency, side-effect profile, and the one optional parameter's intent, leaving nothing an agent needs in order to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema already explains the substring/omit semantics, so the baseline is 3. The description goes further by explaining the rationale the schema omits: the label is the name set via X-LLMxRay-Client, and on a shared machine the latest turn may belong to another tool, so you should pass your own name. That is genuine added meaning, though it does not cover case-sensitivity or matching edge cases.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a precise verb and resource ('what exactly happened on your latest turn') and enumerates the concrete facts returned (prompt tokens and cached share, prefill time/speed, generated tokens/speed, stop reason, prompt make-up, context requested, VRAM fit, first divergence). It explicitly positions itself against all three siblings by naming each and the single question it answers, so an agent can distinguish it without opening another schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit when-to-use ('Use it to budget the next call'), an explicit when-to-use-something-else ('For what is installed and loaded use list_local_models'), and a routing table that assigns one question to each of the four turn-reading tools. The condition that selects this tool (one turn in full) versus diagnose/list/compare is stated outright.

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