Skip to main content
Glama
ADIKANT

datalens-dev-mcp

by ADIKANT

dl_operation_reconcile

Read-onlyIdempotent

Confirm uncertain DataLens modifying operation results by exact target readback without replaying the write.

Instructions

Reconcile an uncertain modifying result by exact target readback without replaying the write.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
operation_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.2.0

TDQS

B3.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: it performs a readback of the target and deliberately does not replay the write, clarifying the mechanism and the no-side-effect recovery contract.

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?

One dense sentence with zero filler and the key constraint ('without replaying the write') front-loaded. It is efficient, though the compressed phrasing borders on cryptic for an agent that has no other guidance.

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

Completeness3/5

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

For a single-parameter, annotation-backed tool this covers the action and mechanism, but with no output schema the description should indicate what the reconcile yields (e.g. whether the operation is confirmed applied, failed, or still unknown). That outcome semantics is the main missing piece.

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

Parameters2/5

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

Schema description coverage is 0% and the single required parameter operation_id is given no explanation in either the schema or the description. 'Uncertain modifying result' hints that operation_id identifies that operation, but the format, source, and scope of the id are left entirely to inference.

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?

States a specific verb ('Reconcile') and a specific object ('an uncertain modifying result'), plus the mechanism (exact target readback). It is distinguishable from the many dl_object_* and dl_operation_get siblings, though the term 'reconcile' is somewhat jargon-heavy and the framing is abstract.

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?

The trigger condition is implied ('uncertain modifying result') and the alternative behavior is ruled out ('without replaying the write'), which points the agent away from a retry. However, no sibling is named and no explicit when/when-not statement is given; the agent must infer this is the recovery path after an ambiguous write.

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