Skip to main content
Glama
deep-agentic-core-mcp

deep-agentic-core-mcp

Official

Optimization Opportunities

lens.optimization_analyze
Read-only

Rank evidence-backed optimizations from AgenticLens run traces by projected benefit, confidence, and quality risk; advisory and read-only.

Instructions

Rank evidence-backed optimizations from AgenticLens Run traces: prompt caching and compression, retrieval pruning and reranking, memory summarization, tool caching, retry policy, redundant steps, unnecessary handoffs and quality-cost trade-offs between variants. Each opportunity keeps projected benefit, confidence and quality risks separate. Advisory and read-only: no decision ledger writes and nothing is changed. Needs agenticlens>=0.11.0.

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": {
      "traces": "<traces>"
    },
    "name": "lens.optimization_analyze"
  }
}

Input Schema

NameRequiredDescriptionDefault
configNoLens OptimizationConfig thresholds; unknown keys fail.
tracesYesAgenticLens Run trace JSON objects with unique run_id.
session_idNoSession to read/write shared state under. Defaults to 'default'.
baseline_variant_idNoVariant to compare quality-cost trade-offs against.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.0

TDQS

A3.7/5.0
Behavior4/5

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

Beyond the readOnlyHint annotation, the description adds that no decision ledger writes occur and nothing is changed, that benefit/confidence/quality risk are reported separately, and that agenticlens>=0.11.0 is required — a real prerequisite an agent would otherwise miss. It does not cover pagination, runtime cost, or what happens with malformed traces, but annotation coverage lowers the bar.

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?

The core action is front-loaded in the first clause, followed by an enumerated capability list and then the safety and version caveats. The category list is long but each item is concrete; a little trimming would still improve density.

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

Completeness4/5

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 characterizes the return shape (each opportunity keeps benefit, confidence, and quality risk separate), which is exactly what an agent needs to interpret results. The version prerequisite and read-only guarantee round it out; only sibling routing information 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%, so the four parameters are already documented. The description only indirectly gestures at baseline_variant_id through 'quality-cost trade-offs between variants' and adds no syntax or constraint detail about traces, config, or session_id beyond the schema.

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

Purpose4/5

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

The description gives a specific verb and resource ('Rank evidence-backed optimizations from AgenticLens Run traces') and enumerates the optimization categories it covers, which implicitly separates it from diagnosis/reporting siblings like lens.diagnose_run or lens.audit_report. It never names a sibling explicitly, so an agent must infer the boundary rather than being told it.

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

Usage Guidelines3/5

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

Usage is implied by 'from AgenticLens Run traces' and by the advisory framing, but there is no explicit when-to-use/when-not-to-use statement and no pointer to the alternative tools (e.g. lens.diagnose_run, lens.modelfit_recommend) an agent should pick instead for related questions.

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