Cryptographic 563-leaf LLM rate oracle, context-cliff auditor, and prompt cache optimizer.
Scored across 4 tools
The four tools have mostly distinct purposes: cliff checking, audit metadata, catalog search, and supported-model listing. However, etuki_search_models and list_supported_models could be confused since both return model information, though descriptions clarify that one searches the full catalog and the other enumerates only the five cliff-engine models.
Verbs are consistently action-oriented (check, get, search, list), but the prefix convention is mixed: two tools use etuki_, while check_context_cliff and list_supported_models do not. This makes the naming somewhat readable but inconsistent.
Four tools are reasonable for a focused FinOps pricing oracle, with each tool covering a distinct function. The surface is slightly thin but well-scoped for the niche domain.
The set covers key operations—cliff decisioning, audit evidence, catalog search, and supported-model listing—but lacks a direct tool to fetch full pricing details for arbitrary catalog models. Agents may need to rely on search results alone for non-cliff models, which could be a gap.
Check one LLM request's token counts against a pricing snapshot and return a deterministic decision: allow, pre-cliff warning, hard-cliff reroute, or budget-gate block, with estimated costs and a cheaper fallback model where one exists. Estimates only, not billing. Receives model name and token counts only, never prompt content.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | Model ID from list_supported_models (gpt-6-1-sol, claude-haiku-5-5, claude-sonnet-5-5, claude-opus-5-5, gpt-6-luna) | |
| pass_rate | No | ||
| request_id | No | Optional trace ID (1..64 alphanumeric/underscore/hyphen chars). | |
| retry_rate | No | ||
| prompt_tokens | Yes | ||
| cache_hit_rate | No | ||
| budget_gate_usd | No | ||
| allow_async_batch | No | ||
| completion_tokens | Yes | ||
| routed_cache_hit_rate | No | ||
| cold_start_cache_write | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds real context beyond that: the decision is deterministic, results are cost estimates rather than billing records, and no prompt content is consumed. It omits how the eight tuning knobs (budget_gate_usd, cache_hit_rate, retry_rate, etc.) alter the decision, which keeps it below 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?
Two front-loaded sentences: the outcome space first, then the estimation caveat and the input-privacy constraint. No filler, and the most decision-relevant information leads.
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?
The return shape is described (decision plus estimated costs plus fallback model), which is necessary since no output schema exists. But for an 11-parameter tool with 18% schema coverage, an agent has no guidance on how the optional cost-model parameters interact or which defaults govern the decision, leaving a meaningful gap.
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 only 18% — just 'model' and 'request_id' are documented — so the description must compensate and largely does not. It mentions model name and token counts, but the eight optional behavioral parameters (budget_gate_usd, cache_hit_rate, routed_cache_hit_rate, cold_start_cache_write, retry_rate, pass_rate, allow_async_batch) are left entirely unexplained in both schema and description.
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 and resource ('check one LLM request's token counts against a pricing snapshot') and enumerates the exact decision space: allow, pre-cliff warning, hard-cliff reroute, budget-gate block. This is clearly distinguishable from sibling read tools like list_supported_models and get_audit_evidence without opening the 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?
'Estimates only, not billing' establishes the scope boundary and 'Receives model name and token counts only, never prompt content' implies a pre-flight check, but the description never states explicitly when to call this versus list_supported_models or the search/audit siblings. Usage is inferable rather than declared.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the cryptographic snapshot metadata (Merkle root, RS256 public key URL, snapshot date, and 12/12 CI self-test reference) for the current pricing snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, closed-world, and non-destructive behavior, so the safety profile is covered. The description adds value by enumerating the exact contents returned (Merkle root, RS256 public key URL, snapshot date, 12/12 CI self-test reference), which tells the agent what verification material is available; it does not mention the behavior when no snapshot exists, but that is a minor gap given the annotation coverage.
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?
A single dense sentence that front-loads the action and resource, then lists the returned fields without any filler. Every clause earns its place.
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 usefully enumerates the returned metadata fields. It stops short of describing error or empty-snapshot behavior, but for a zero-parameter, read-only retrieval tool this is largely sufficient.
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 parameters, so there is nothing for the description to document and the baseline of 4 applies. The description correctly does not invent any inputs.
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 (retrieve) and resource (cryptographic snapshot metadata for the current pricing snapshot), with concrete field names. Slightly misaligned with the tool name 'audit_evidence' — it actually returns metadata rather than the evidence payload itself, which could cause mild ambiguity.
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 phrase 'for the current pricing snapshot' implies the scope in which this tool applies, but there is no explicit when-to-use guidance, no mention of when not to use it, and no indication of alternatives for historical snapshots. Sibling tools are in unrelated domains, so no routing is strictly needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search and filter across all 563 Merkle-committed LLM API and cloud infrastructure entities in the Etuki catalog by keyword.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Model or vendor keyword (e.g. gpt-6.1, claude, gemini, deepseek, hunyuan) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so the safety profile is covered. The description contributes the catalog scope (563 Merkle-committed entities), but is silent on behavior an agent would want: what an omitted query returns, result limits/pagination, and match semantics.
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?
A single sentence, front-loaded with the verb and resource, with a useful scale/count detail and no filler. Nothing extraneous.
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?
For a one-parameter, annotation-covered search tool this covers the minimum, but with no output schema the agent gets no sense of what a hit looks like or how many come back, and the optional-query behavior is left unexplained.
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 description coverage is 100% and the single 'query' param already carries examples (gpt-6.1, claude, gemini...). The description only restates 'by keyword' and notably does not explain the consequence of the zero required parameters — i.e. what an empty query returns.
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 ('Search and filter') plus a well-scoped resource: 'all 563 Merkle-committed LLM API and cloud infrastructure entities in the Etuki catalog'. That is concrete enough to distinguish it from list_supported_models, though it never names the sibling explicitly.
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 word 'search ... by keyword' implies discovery usage, but the description never says when to choose this over list_supported_models or etuki_get_audit_evidence, and gives no exclusions or prerequisites. Usage has to be inferred from the name and the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the 5 deterministic cliff-engine models supported by check_context_cliff along with their input/output rates, cache rates, cliff token thresholds, soft-block thresholds, fallback targets, pricing_snapshot_id, and Merkle root.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so safety is covered. The description adds real value by enumerating the returned data (rates, thresholds, fallback targets, pricing_snapshot_id, Merkle root), which tells the agent what this fixed-size snapshot contains.
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?
One sentence with the action and resource front-loaded, followed by the returned-field enumeration. It is dense but every clause carries information; no filler or repetition.
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, and the description compensates by listing the exact fields returned, plus the fixed count of 5 models. Combined with annotations covering the safety profile, an agent has everything needed to call and interpret this tool.
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 no parameters, so parameter semantics are moot and the baseline of 4 applies. The description correctly avoids inventing inputs and focuses on output content.
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 concrete verb and resource ('Return the 5 deterministic cliff-engine models supported by check_context_cliff') and names the sibling tool it is tied to. Scope is explicit, though it doesn't distinguish itself from etuki_search_models, which also returns models.
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?
Usage is implied — call this to discover which models are available before invoking check_context_cliff — but the description never says when to prefer this over the sibling etuki_search_models or etuki_get_audit_evidence. No exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_context_cliffetuki_get_audit_evidenceetuki_search_modelslist_supported_modelsFree shared LLM inference (no key), verifiable score certificates, public randomness beacon.
Autonomous AI microservices: 55 dynamic guardrails, contract audits & oracles via L402/x402/MPP.
LLM cost optimization gateway, repo token-waste auditor & model arbitrage MCP server.
LLM cost optimization gateway, repo token-waste auditor & model arbitrage MCP server.
Add one secure layer between your agents and this server.