Last9

{
  "mcp": {
    "servers": {
      "last9": {
        "type": "stdio",
        "command": "/opt/homebrew/bin/last9-mcp",
        "env": {
          "LAST9_REFRESH_TOKEN": "<your_refresh_token>"
        }
      }
    }
  }
}

NPM के लिए: "command": "npx" का उपयोग करें और "args": ["-y", "@last9/mcp-server@latest"] जोड़ें।

GitHub Releases से डाउनलोड करने के बाद, इसे एक्सट्रैक्ट करें और पूरा पाथ दें:

{
  "mcpServers": {
    "last9": {
      "command": "C:\\Users\\<user>\\AppData\\Local\\Programs\\last9-mcp-server.exe",
      "env": {
        "LAST9_REFRESH_TOKEN": "<your_refresh_token>"
      }
    }
  }
}

Windows पर NPM वाला तरीका आसान है — पाथ मैनेज करने की ज़रूरत नहीं।

HTTP मोड में चलाएँ

export LAST9_REFRESH_TOKEN="your_refresh_token"
export LAST9_HTTP=true
export LAST9_PORT=8080
./last9-mcp-server

सर्वर http://localhost:8080/mcp पर शुरू होता है।

curl से परीक्षण करें

Streamable HTTP हैंडलर स्टेटलेस मोड में चलता है, इसलिए हर अनुरोध स्वतंत्र रूप से संभाला जाता है। initialize हैंडशेक और Mcp-Session-Id हेडर वैकल्पिक हैं — इन्हें भेजने वाले क्लाइंट भी काम करते हैं (हेडर स्वीकार किया जाता है और अनदेखा किया जाता है), और क्लाइंट सीधे tools/list / tools/call पर भी जा सकते हैं। हर टूल एक स्वतंत्र अनुरोध/प्रतिक्रिया क्वेरी है; सर्वर कोई server→client सूचना नहीं भेजता, इसलिए GET /mcp (SSE स्ट्रीम) 405 लौटाता है।

# List tools — a session handshake is optional in stateless mode
curl -s -X POST http://localhost:8080/mcp \
    -H "Content-Type: application/json" \
    -H "Accept: application/json, text/event-stream" \
    -d '{"jsonrpc": "2.0", "id": 1, "method": "tools/list", "params": {}}'

# Call a tool
curl -s -X POST http://localhost:8080/mcp \
    -H "Content-Type: application/json" \
    -H "Accept: application/json, text/event-stream" \
    -d '{
      "jsonrpc": "2.0",
      "id": 2,
      "method": "tools/call",
      "params": {
        "name": "get_service_logs",
        "arguments": {
          "service_name": "your-service-name",
          "lookback_minutes": 30,
          "limit": 10
        }
      }
    }'

प्रति-अनुरोध toolsets

HTTP मोड में, अनुरोध X-Last9-Toolsets हेडर से अपने उपलब्ध टूल सीमित कर सकता है, या उन क्लाइंट के लिए toolsets क्वेरी पैरामीटर का उपयोग कर सकता है जो हेडर सेट नहीं कर सकते (/mcp?toolsets=logs,traces)। यदि दोनों भेजे जाएँ, तो गैर-रिक्त हेडर को प्राथमिकता मिलती है। मान में --toolsets जैसे ही अल्पविराम से अलग किए गए नाम होते हैं। अनुरोध को स्टार्टअप के --toolsets के साथ प्रतिच्छेद मिलता है: यह केवल सीमित कर सकता है, कभी बढ़ा नहीं सकता; और all या रिक्त मान स्टार्टअप सेट को बनाए रखता है। अज्ञात नाम पर उसे बताते हुए 400 लौटता है। tools/list, tools/call और initialize निर्देश, सभी प्रभावी सेट का पालन करते हैं; get_current_time और get_workspace_overview हर सेट में बने रहते हैं।

curl -s -X POST http://localhost:8080/mcp \
    -H "Content-Type: application/json" \
    -H "Accept: application/json, text/event-stream" \
    -H "X-Last9-Toolsets: logs,alerts" \
    -d '{"jsonrpc": "2.0", "id": 1, "method": "tools/list", "params": {}}'

हर अलग प्रभावी सेट को उसका अपना सर्वर मिलता है, जो पहले अनुरोध पर बनता है (दसियों मिलीसेकंड) और शटडाउन तक बना रहता है; स्टार्टअप सेट को दोहराने वाला अनुरोध स्टार्टअप सर्वर का पुनः उपयोग करता है। कोई निष्कासन नहीं होता: केवल नामित toolsets स्वीकार किए जाते हैं, इसलिए कैश में उनके संयोजनों के लिए अधिकतम एक सर्वर रहता है (आज 135, कुल मिलाकर लगभग 75 MB लाइव हीप; परीक्षण में पूरा कैश स्थिर होने पर लगभग 230 MB रेज़िडेंट मेमोरी के पास पहुँचा)।

स्रोत से बिल्ड करें

git clone https://github.com/last9/last9-mcp-server.git
cd last9-mcp-server
go build -o last9-mcp-server
LAST9_HTTP=true ./last9-mcp-server

LAST9_HTTP=true स्थानीय विकास के लिए है। वास्तविक उपयोग के लिए, होस्ट किया गया HTTP एंडपॉइंट अधिक आसान है।

समय इनपुट

• निरपेक्ष समय (start_time_iso/end_time_iso, या time_iso) को lookback_minutes पर प्राथमिकता मिलती है।
• सापेक्ष समयावधियों के लिए: lookback_minutes का उपयोग करें।
• निरपेक्ष समयावधियों के लिए: RFC3339/ISO8601 — 2026-02-09T15:04:05Z का उपयोग करें।
• पुराना YYYY-MM-DD HH:MM:SS केवल संगतता के लिए स्वीकार किया जाता है।
• since yesterday 9am IST जैसे वाक्यांशों को get_current_time से RFC3339 सीमाओं में बदलें।

get_workspace_overview

कोई पैरामीटर नहीं। पिछले 60 मिनट की जाँच समवर्ती रूप से करता है; हर उप-कॉल के लिए छोटा टाइमआउट होता है, और यह current_time, lookback_minutes, environments, telemetry (logs/traces/metrics बूलियन), service_count (अलग-अलग सेवाएँ, get_service_summary रैंक, हर परिवेश), alert_group_count, firing_alert_count और errors ([{field, error}]) लौटाता है। जिस फ़ील्ड की उप-कॉल विफल हुई हो, वह null (अज्ञात) होता है, कभी 0 या false नहीं। जाँचें --toolsets से सीमित नहीं होतीं: toolsets यह तय करते हैं कि कौन-से टूल उपलब्ध हैं, और API टोकन यह तय करता है कि सर्वर क्या पढ़ सकता है।

get_current_time

• range (स्ट्रिंग, वैकल्पिक): last 2h, past 30 minutes, last 7d (s, m, h, d = 24h, w = 7d; अधिकतम 366d); today; yesterday; since <point>; <point> to <point>। कोई समय-बिंदु RFC3339, या today / yesterday / सप्ताह का कोई दिन (monday, mon: इसका सबसे हाल का अवसर, आज सहित) / YYYY-MM-DD हो सकता है, जिसके साथ वैकल्पिक 9am, 9:30pm या 14:30 हो सकता है। अंत में दिया गया टाइम ज़ोन दोनों सीमाओं के लिए timezone को ओवरराइड करता है; अन्य कहीं भी टाइम ज़ोन देने पर त्रुटि होती है। केवल now के लिए इसे छोड़ दें।
• timezone (स्ट्रिंग, वैकल्पिक): IANA नाम या संक्षिप्त नाम (IST = Asia/Kolkata, PST/PDT, EST/EDT, UTC, GMT)। डिफ़ॉल्ट UTC है। अज्ञात टाइम ज़ोन त्रुटि हैं, और अस्पष्ट CST भी त्रुटि है (America/Chicago या Asia/Shanghai पास करें)।

now (और range के साथ start/end) को {iso, epoch_seconds, local} के रूप में लौटाता है; local केवल गैर-UTC टाइम ज़ोन के लिए दिखाई देता है।

get_exceptions

• limit (पूर्णांक, वैकल्पिक): अधिकतम अपवाद। डिफ़ॉल्ट: 20।
• lookback_minutes (पूर्णांक, वैकल्पिक): डिफ़ॉल्ट: 60।
• start_time_iso / end_time_iso (स्ट्रिंग, वैकल्पिक): निरपेक्ष समय सीमा।
• service_name (स्ट्रिंग, वैकल्पिक): सेवा के अनुसार फ़िल्टर करें।
• span_name (स्ट्रिंग, वैकल्पिक): स्पैन नाम के अनुसार फ़िल्टर करें।
• env (स्ट्रिंग, वैकल्पिक): परिवेश के अनुसार फ़िल्टर करें।

get_service_summary

• start_time_iso / end_time_iso (स्ट्रिंग, वैकल्पिक)
• env (स्ट्रिंग, वैकल्पिक): PromQL रेगेक्स। डिफ़ॉल्ट .* है। सटीक मिलान के लिए एंकर आवश्यक हैं (उदा. ^prod$)।
• sort_by (स्ट्रिंग, वैकल्पिक): request_count (डिफ़ॉल्ट), throughput_rpm, http_4xx_count, http_5xx_count या grpc_error_count।
• limit (पूर्णांक, वैकल्पिक): रैंक की गई पंक्तियों की अधिकतम संख्या। छोड़ने या 0 देने पर 10; 100 से अधिक मान 100 तक सीमित होते हैं।

get_service_environments

• start_time_iso / end_time_iso (स्ट्रिंग, वैकल्पिक)

अन्य सभी APM टूल के लिए env मान आवश्यक है। यदि यह खाली लौटे, तो "" का उपयोग करें।

get_service_performance_details

डिफ़ॉल्ट रूप से हर सीरीज़ का सारांश लौटाता है: points, missing_points (बिना ट्रैफ़िक वाले उपलब्धता बकेट, जिन्हें आँकड़ों से बाहर रखा जाता है), min, p50, p90, p99 (निकटतम-रैंक), max, mean, last, baseline_mean (मान्य बिंदुओं के पहले आधे का औसत, पूरी समयावधि का नहीं), delta_pct (मान्य बिंदुओं के दूसरे आधे की तुलना बेसलाइन से; बेसलाइन 0 होने पर अनुपस्थित) और अधिकतम 3 change_points (timestamp, before_mean, after_mean), हर मेट्रिक और प्रतिक्रिया-समय क्वांटाइल के लिए अधिकतम 4 सीरीज़ तक (सबसे अधिक औसत पहले; बाकी की संख्या series_omitted में)। points: 0 वाली सीरीज़ में कोई आँकड़े नहीं होते, और baseline_mean/delta_pct के लिए कम-से-कम 6 बिंदु (हर आधे में 3) आवश्यक हैं। full_series बताता है कि कच्चे बिंदु include_series के ज़रिए उपलब्ध हैं।

• service_name (स्ट्रिंग, आवश्यक)
• lookback_minutes (पूर्णांक, वैकल्पिक): डिफ़ॉल्ट: 60।
• start_time_iso / end_time_iso (स्ट्रिंग, वैकल्पिक)
• env (स्ट्रिंग, वैकल्पिक): डिफ़ॉल्ट prod है।
• top_n (पूर्णांक, वैकल्पिक): शीर्ष ऑपरेशन/शीर्ष त्रुटि सूची में प्रविष्टियों की अधिकतम संख्या। डिफ़ॉल्ट: 5, या include_series=true के साथ 10। अधिकतम 100।
• include_series (बूलियन, वैकल्पिक): सारांश के बजाय हर सीरीज़ का हर बिंदु लौटाएँ। डिफ़ॉल्ट: false।

get_service_operations_summary

• service_name (स्ट्रिंग, आवश्यक)
• lookback_minutes (पूर्णांक, वैकल्पिक): डिफ़ॉल्ट: 60।
• start_time_iso / end_time_iso (स्ट्रिंग, वैकल्पिक)
• env (स्ट्रिंग, वैकल्पिक): डिफ़ॉल्ट prod है।

get_service_dependency_graph

• service_name (स्ट्रिंग, वैकल्पिक)
• lookback_minutes (पूर्णांक, वैकल्पिक): डिफ़ॉल्ट: 60।
• start_time_iso / end_time_iso (स्ट्रिंग, वैकल्पिक)
• env (स्ट्रिंग, वैकल्पिक): डिफ़ॉल्ट prod है।

get_apm_service_deviations

• service_name (string, optional): फ़्लीट स्कोप के लिए छोड़ दें; किसी एक सेवा और उससे जुड़े ऑपरेशन के लिए दें।
• lookback_minutes (integer, optional): मौजूदा विंडो। डिफ़ॉल्ट: 60।
• start_time_iso / end_time_iso (string, optional): मौजूदा विंडो स्पष्ट रूप से दें।
• baseline_start_time_iso / baseline_end_time_iso (string, optional): बेसलाइन स्पष्ट रूप से दें। डिफ़ॉल्ट रूप से, इससे ठीक पहले की समान अवधि वाली विंडो।
• datasource (string, optional): डिफ़ॉल्ट के लिए छोड़ दें; अनुमानित नामों का समाधान Prometheus टूल की तरह होता है। जवाब में इस्तेमाल किया गया डिफ़ॉल्ट या सबसे निकट का मिलान बताया जाता है; अस्पष्ट नामों पर क्वेरी किए बिना संभावित विकल्प लौटाए जाते हैं।
• env (string, optional): डिफ़ॉल्ट रूप से prod।
• max_services / max_operations (integer, optional): डिफ़ॉल्ट 10, प्रत्येक की अधिकतम सीमा 10।

get_databases

• env (string, optional): एनवायरनमेंट के अनुसार फ़िल्टर करें। रेगुलर एक्सप्रेशन स्वीकार करता है। डिफ़ॉल्ट: सभी।
• lookback_minutes (integer, optional): डिफ़ॉल्ट: 60। विंडो 7 दिनों से अधिक की नहीं हो सकती।
• start_time_iso / end_time_iso (string, optional)

get_database_slow_queries

• db_system (string, optional): उदाहरण के लिए postgresql, mysql, mongodb, redis।
• host (string, optional): डेटाबेस होस्ट (net_peer_name)।
• service_name (string, optional): कॉल करने वाली सेवा का नाम।
• env (string, optional)
• min_duration_ms (float, optional): क्वेरी की न्यूनतम अवधि, ms में।
• lookback_minutes (integer, optional): डिफ़ॉल्ट: 60।
• start_time_iso / end_time_iso (string, optional)
• limit (integer, optional): डिफ़ॉल्ट: 20।

get_database_queries

• db_system (string, optional)
• host (string, optional)
• service_name (string, optional)
• env (string, optional)
• lookback_minutes (integer, optional): डिफ़ॉल्ट: 60।
• start_time_iso / end_time_iso (string, optional)
• limit (integer, optional): डिफ़ॉल्ट: 20।

get_database_server_metrics

• db_system (string, required): उदाहरण के लिए postgresql, mysql, mongodb, redis, aerospike।
• host (string, optional)
• lookback_minutes (integer, optional): डिफ़ॉल्ट: 60।
• start_time_iso / end_time_iso (string, optional)

prometheus_range_query

• query (string, required): PromQL क्वेरी।
• start_time_iso / end_time_iso (string, optional): डिफ़ॉल्ट रूप से पिछले 60 मिनट।
• lookback_minutes (float, optional): डिफ़ॉल्ट: 60।

prometheus_instant_query

• query (string, required)
• time_iso (string, optional): डिफ़ॉल्ट रूप से अभी।
• lookback_minutes (float, optional)

prometheus_label_values

• match_query (string, optional): PromQL फ़िल्टर।
• label (string, required): लेबल का नाम।
• lookback_minutes (float, optional): डिफ़ॉल्ट: 60।
• start_time_iso / end_time_iso (string, optional)

जब कोई विंडो न दी गई हो और match_query में एक मेट्रिक का नाम हो (metric{...} या {__name__="metric"}), तो 60 मिनट का खाली परिणाम 4 दिनों की अवधि पर एक बार फिर से आज़माया जाता है; दूसरे टेक्स्ट ब्लॉक में बताया जाता है कि परिणाम किस विंडो को कवर करता है।

prometheus_labels

• match_query (string, optional): PromQL फ़िल्टर।
• lookback_minutes (float, optional): डिफ़ॉल्ट: 60।
• start_time_iso / end_time_iso (string, optional)

prometheus_label_values की तरह, एकल-मेट्रिक की खाली खोज 4 दिनों की अवधि पर फिर से आज़माई जाती है।

get_logs

• logjson_query (array, required): JSON पाइपलाइन क्वेरी।
• lookback_minutes (integer, optional): डिफ़ॉल्ट: 5।
• start_time_iso / end_time_iso (string, optional)
• limit (integer, optional): सर्वर डिफ़ॉल्ट: 5000।
• index (string, optional): physical_index:<name> या rehydration_index:<block_name>।
• response_mode (string, optional): summary (डिफ़ॉल्ट; null के लिए भी) या raw। 20 से अधिक पंक्तियों वाला रॉ-लाइन परिणाम इस रूप में लौटता है: summary: lines_summarized, severity_counts (शीर्ष छह लेबल, बाकी other_severities में), first_timestamp/last_timestamp, क्वेरी विंडो पर 10-बकेट वाला histogram (लौटाई गई पंक्तियों पर, और परिणाम सीमा से कटने पर truncated: true के साथ), तथा शीर्ष patterns (template, count, अधिकतम दो samples), बाकी का कुल other में; अधिकतम 4000 वर्ण। यदि शीर्ष-स्तरीय मेटाडेटा फिर भी समा न पाए, तो उसे हटाकर dropped_fields में उसका नाम दिया जाता है। raw पंक्तियाँ लौटाता है। एग्रीगेट परिणामों का सारांश कभी नहीं बनाया जाता।

लॉग-आधारित सेवा इन्वेंटरी के लिए, पहले physical_index_service_count से क्वेरी करें:

sum by (name, service_name, env) (physical_index_service_count{destination="logs"})

service_name को ServiceName के रूप में, मौजूद होने पर env को एनवायरनमेंट के रूप में, और name को फ़िज़िकल इंडेक्स नाम के रूप में इस्तेमाल करें। यदि name="default", तो index छोड़ दें; उपयोगकर्ता द्वारा चुने गए गैर-डिफ़ॉल्ट फ़िज़िकल इंडेक्स के लिए index: "physical_index:<name>" दें। यदि बैकएंड स्पष्ट फ़िज़िकल इंडेक्स फ़िल्टरिंग अस्वीकार करे, तो index के बिना फिर से प्रयास करें और बताएँ कि उस बैकएंड के लिए स्पष्ट फ़िज़िकल इंडेक्स फ़िल्टरिंग उपलब्ध नहीं है।

get_service_logs

• service_name (string, required)
• lookback_minutes (integer, optional): डिफ़ॉल्ट: 60।
• limit (integer, optional): डिफ़ॉल्ट: 100, या response_mode: "raw" के साथ 20।
• env (string, optional)
• severity_filters (array, optional): उदाहरण के लिए ["error", "warn"]। OR लॉजिक।
• body_filters (array, optional): उदाहरण के लिए ["timeout", "failed"]। OR लॉजिक।
• start_time_iso / end_time_iso (string, optional)
• index (string, optional)
• response_mode (string, optional): summary (डिफ़ॉल्ट; null के लिए भी) या raw। 20 से अधिक पंक्तियों पर, logs को get_logs वाले उसी summary से बदल दिया जाता है, जबकि अन्य फ़ील्ड जस के तस रहते हैं; raw प्रविष्टियाँ लौटाता है।

एक से अधिक फ़िल्टर प्रकार AND से जुड़ते हैं। हर ऐरे के भीतर OR लॉजिक लागू होता है। पहले व्यापक एग्रीगेट गणनाओं के लिए get_logs का इस्तेमाल करें; get_service_logs का इस्तेमाल केवल सेवा/एनवायरनमेंट/इंडेक्स तक सीमित करने और नमूनों की संख्या कम करने के बाद करें।

get_log_patterns

• service_name (string, required)
• env (string, optional)
• start_time_iso / end_time_iso (string, optional)
• lookback_minutes (integer, optional): डिफ़ॉल्ट: 60।
• severity_filters / body_filters (array, optional): OR लॉजिक, जैसा कि get_service_logs में है। severity_filters केवल तभी सेट करें जब get_service_profile में severity_set all बताया गया हो; none या partial के साथ यह उन पंक्तियों को हटा देता है जिनकी गंभीरता बॉडी में है।
• index (string, optional)
• sample_size (integer, optional): विंडो से नमूने में ली गई पंक्तियाँ, सबसे नई पहले। डिफ़ॉल्ट: 1000, अधिकतम: 5000।
• top_n (integer, optional): गिनती के अनुसार लौटाए गए टेम्पलेट। डिफ़ॉल्ट: 20, अधिकतम: 100। बाकी का कुल other में दिया जाता है।

क्लस्टरिंग MCP सर्वर पर नमूने की पंक्तियों में चलती है, इसलिए गिनतियाँ, first_seen और last_seen नमूने के भीतर के होते हैं; window.sample_limit_reached बताता है कि नमूने में मेल खाने वाली पंक्तियाँ छूट सकती हैं या नहीं (इसमें sample_size पंक्तियाँ होती हैं और API इससे मेल खाता सटीक total_matching_lines रिपोर्ट नहीं करता, या खोज logs_truncated थी), ऐसी स्थिति में इसमें केवल विंडो की सबसे नई पंक्तियाँ होती हैं। हर template और sample को 500 वर्णों पर काटा जाता है और अंत में … जोड़ा जाता है, इसलिए जो बॉडी क्लस्टर नहीं होती (जैसे message फ़ील्ड के बिना JSON), वह जवाब को भर नहीं सकती। विफल चंक्स वाली खोज टूल त्रुटि होती है; ट्रंकेट या कैप की गई खोज फिर भी पैटर्न लौटाती है, जिन्हें sample_limit_reached से चिह्नित किया जाता है। खाली patterns सूची का अर्थ है कि कुछ भी मेल नहीं खाया, केवल तभी जब sample_limit_reached false हो; true होने पर खोज जल्दी रुक गई और मेल खाने वाली पंक्तियाँ छूट सकती हैं।

get_emerging_log_patterns

सभी get_log_patterns पैरामीटर लेता है (समय सीमा मौजूदा विंडो होती है), साथ ही:

• baseline_start_time_iso / baseline_end_time_iso (string, optional): दोनों सेट करें या दोनों में से कोई नहीं। डिफ़ॉल्ट: मौजूदा विंडो से ठीक पहले की समान अवधि वाली विंडो।
• min_count (integer, optional): उस विंडो में बदले हुए पैटर्न के लिए आवश्यक पंक्तियाँ जिसमें उसकी संख्या अधिक हो: new/increased के लिए मौजूदा विंडो, decreased/disappeared के लिए बेसलाइन। डिफ़ॉल्ट: 3 (या यदि कम हो तो sample_size), अधिकतम: sample_size।
• change_factor (number, optional): आवृत्ति अनुपात, 1 से अधिक, जिसे दोनों विंडो में दिखने वाले पैटर्न को increased तक पहुँचना या decreased के व्युत्क्रम तक गिरना चाहिए। डिफ़ॉल्ट: 2।

दोनों सीमाएँ पूरी होनी चाहिए, इसलिए अधिक मात्रा वाला ऐसा टेम्पलेट जिसकी आवृत्ति में change_factor के अनुसार बदलाव नहीं हुआ, कभी रिपोर्ट नहीं किया जाता। केवल बदले हुए टेम्पलेट लौटाए जाते हैं (new, increased, decreased, disappeared), साथ में current और baseline की गिनतियाँ; unchanged_patterns उन टेम्पलेट की गिनती करता है जो दोनों विंडो में थे, लेकिन उनमें change_factor से कम बदलाव हुआ; और below_min_count_patterns उन बदलावों की गिनती करता है जिन्हें min_count से कम पंक्तियाँ होने के कारण हटा दिया गया। आवृत्तियों की तुलना प्रति मिनट की जाती है, जब दोनों नमूनों में हर मेल खाने वाली पंक्ति मौजूद हो; कैप किए गए नमूने के सटीक total_matching_lines से प्रति मिनट का अनुमान लगाया जाता है; अन्यथा नमूने के हिस्से के रूप में तुलना होती है, जहाँ increased/decreased दर के बजाय संरचना बताते हैं (comparison_basis)। खाली patterns सूची का अर्थ है कि दोनों सीमाओं से अधिक कोई बदलाव नहीं हुआ, न कि लॉग अपरिवर्तित रहे: कम बदलावों की गिनती below_min_count_patterns में होती है, और sample_limit_reached वाली विंडो पूरे विंडो की नहीं, नमूनों की तुलना करती है।

get_log_attributes

• lookback_minutes (integer, optional): डिफ़ॉल्ट: 15।
• start_time_iso / end_time_iso (string, optional)
• region (string, optional)
• index (string, optional)

get_log_attributes_for_pipeline

• pipeline (array, required): खोज का दायरा तय करने के लिए पहले के फ़िल्टर चरण, उदाहरण के लिए [{"type":"filter","query":{"$eq":["ServiceName","<service>"]}}]।
• lookback_minutes (integer, optional): डिफ़ॉल्ट: 15।
• start_time_iso / end_time_iso (string, optional)
• region (string, optional)
• index (string, optional)

get_drop_rules

कोई पैरामीटर नहीं। GET /otel_settings/drop?region=... के ज़रिए ड्रॉप नियमों की सूची देता है।

add_drop_rule

• name (string, required)
• filters (array, required): हर फ़िल्टर: key, value, operator (equals/not_equals), conjunction (and)।
• फ़िल्टर कुंजियों में attributes["key_name"] या resource.attributes["key_name"] का इस्तेमाल होना चाहिए (Last9 API के लिए आवश्यक)।
• POST /otel_settings/drop?region=...&cluster_id=... के ज़रिए नियम बनाता है।

get_remapping_rules

• rule_type (string, required): logs_extract, logs_map या traces_map।
• region (string, optional): डिफ़ॉल्ट: कॉन्फ़िगर किया गया डेटा स्रोत क्षेत्र।
• GET /otel_settings/remapping/{rule_type}?region=... के ज़रिए नियमों की सूची देता है।

add_remapping_rule

हर कॉल में एक नियम बनाता है; मैप नियमों के लिए हर target_attribute पर एक कॉल आवश्यक है।

• rule_type (string, आवश्यक): logs_extract, logs_map या traces_map।
• name (string, आवश्यक)
• remap_keys (array, आवश्यक): स्रोत फ़ील्ड। logs_extract के साथ json: बॉडी फ़ील्ड के नाम; pattern के साथ: नामित कैप्चर समूह वाला ठीक एक regex। मैप नियम: एट्रिब्यूट पाथ, पहला गैर-रिक्त मान लागू होता है।
• target_attribute (string, आवश्यक): logs_extract: log_attributes या resource_attributes। logs_map: service, severity या resource_deployment.environment। traces_map: service।
• extract_type (string, केवल logs_extract के लिए, वहाँ आवश्यक): json या pattern।
• action (string, केवल logs_extract के लिए): upsert (डिफ़ॉल्ट) या insert।
• prefix (string, केवल logs_extract के लिए)
• preconditions (array, केवल logs_extract के लिए): अधिकतम एक {key, value, operator}; operator है equals (डिफ़ॉल्ट), not_equals या like (regex)।
• region (string, वैकल्पिक): डिफ़ॉल्ट: कॉन्फ़िगर किया गया datasource क्षेत्र।
• नियम POST /otel_settings/remapping/{rule_type}?region=... के ज़रिए बनाता है। कभी दोबारा प्रयास नहीं किया जाता; टाइमआउट के बाद, get_remapping_rules से जाँचें।

get_traces

व्यापक खोजों और एग्रीगेशन के लिए उपयोग करें। सटीक trace ID खोजने के लिए, get_service_traces का उपयोग करें।

• tracejson_query (array, आवश्यक)
• start_time_iso / end_time_iso (string, वैकल्पिक)
• lookback_minutes (integer, वैकल्पिक): डिफ़ॉल्ट: 60।
• limit (integer, वैकल्पिक): डिफ़ॉल्ट: 5000।

get_service_traces

trace_id या service_name में से ठीक एक आवश्यक है।

• trace_id (string, वैकल्पिक): डिफ़ॉल्ट लुकबैक: 72 घंटे।
• service_name (string, वैकल्पिक): डिफ़ॉल्ट लुकबैक: 60 मिनट।
• lookback_minutes (integer, वैकल्पिक)
• start_time_iso / end_time_iso (string, वैकल्पिक)
• limit (integer, वैकल्पिक): डिफ़ॉल्ट: 10।
• env (string, वैकल्पिक)

get_trace_attributes

• lookback_minutes (integer, वैकल्पिक): डिफ़ॉल्ट: 15।
• start_time_iso / end_time_iso (string, वैकल्पिक)
• region (string, वैकल्पिक)

get_trace_attributes_for_pipeline

• pipeline (array, आवश्यक): खोज को सीमित करने के लिए पहले के फ़िल्टर चरण, जैसे [{"type":"filter","query":{"$eq":["ServiceName","<service>"]}}]।
• lookback_minutes (integer, वैकल्पिक): डिफ़ॉल्ट: 15।
• start_time_iso / end_time_iso (string, वैकल्पिक)
• region (string, वैकल्पिक)

get_trace_attribute_values

• tag_name (string, आवश्यक): get_trace_attributes से एट्रिब्यूट का नाम (जैसे resource_department या attributes['http.method'])।
• pipeline (array, वैकल्पिक): मानों को सीमित करने के लिए पहले के फ़िल्टर चरण; वैश्विक मानों के लिए इसे छोड़ दें।
• lookback_minutes (integer, वैकल्पिक): डिफ़ॉल्ट: 15।
• start_time_iso / end_time_iso (string, वैकल्पिक): ऐतिहासिक RFC3339 सीमाएँ; lookback_minutes को प्राथमिकता देती हैं।
• region (string, वैकल्पिक)

get_trace_attribute_deviations

• comparison_mode (string, आवश्यक): latency, errors या time।
• service_name (string, आवश्यक)
• environment (string, आवश्यक): सटीक deployment.environment मान।
• operation (string, वैकल्पिक)
• filters (array, वैकल्पिक): Trace JSON फ़िल्टर शर्तें।
• candidate_attributes (array, वैकल्पिक): अधिकतम 8; सीमित खोज के लिए इसे छोड़ दें।
• latency_threshold_ms (number, वैकल्पिक): latency मोड के लिए आवश्यक; अन्य मोड में अस्वीकार किया जाता है।
• start_time_iso / end_time_iso (string, वैकल्पिक)
• lookback_minutes (integer, वैकल्पिक): डिफ़ॉल्ट: 15। अधिकतम: 15।
• baseline_start_time_iso / baseline_end_time_iso (string, वैकल्पिक): time मोड के लिए आवश्यक; एक-दूसरे से ओवरलैप नहीं करते और लक्ष्य विंडो के बराबर अवधि के होते हैं।
• minimum_cohort_size (integer, वैकल्पिक): डिफ़ॉल्ट: 100। न्यूनतम: 20।
• minimum_value_support (integer, वैकल्पिक): डिफ़ॉल्ट: 20। न्यूनतम: 10।
• limit (integer, वैकल्पिक): डिफ़ॉल्ट: 10। अधिकतम: 10।

इसके लिए सहयोगी backend क्षमता सक्षम होनी चाहिए।

get_trace_waterfall

• trace_id (string, आवश्यक)
• environment (string, वैकल्पिक)
• start_time_iso / end_time_iso (string, वैकल्पिक)
• lookback_minutes (integer, वैकल्पिक): डिफ़ॉल्ट: 4320 (72 घंटे)।
• selected_span_id (string, वैकल्पिक): केवल उस span के एट्रिब्यूट, इवेंट और लिंक लौटाता है।
• max_spans (integer, वैकल्पिक): डिफ़ॉल्ट: 500। अधिकतम: 1000; संगठन की redaction नीति इसे इससे कम पर सीमित कर सकती है।

Trace सेवा का investigation-evidence/v1 envelope बिना बदलाव लौटाता है; waterfall data के अंतर्गत होता है। सेवा waterfall बनाती है और backend से बाहर जाने से पहले प्रति-संगठन नीति के अनुसार मानों को redact करती है (credentials, query literals, URLs, emails, IPs, user identifiers): sanitizer लागू हुई नीति का नाम बताता है और evidence.sanitization बताता है कि कितने मान redact या truncate किए गए। यदि आवश्यक जानकारी redact हुई है, तो इसके आसपास काम करने के बजाय संगठन के admin से नीति समायोजित करने को कहें। यह टूल ऐसे response को अस्वीकार करता है जिसमें sanitizer block न हो, sanitizer.version का मान trace-evidence-sanitizer/v1 के अलावा कुछ हो, body में कोई JSON key दोहराई गई हो, या body 512 KiB से बड़ी हो (कम max_spans)। इसके लिए सहयोगी backend क्षमता सक्षम होनी चाहिए।

get_change_events

• start_time_iso / end_time_iso (string, वैकल्पिक)
• lookback_minutes (integer, वैकल्पिक): डिफ़ॉल्ट: 60।
• service_name (string, वैकल्पिक)
• env (string, वैकल्पिक)
• event_name (string, वैकल्पिक): available_event_names पाने के लिए पहले इसे दिए बिना कॉल करें।

analyze_change_impact

change_event या service + timestamp में से ठीक एक पास करें।

• change_event (object, वैकल्पिक): get_change_events change_events[] का एक तत्व, बिना बदलाव। इसमें metric.service, metric.deployment_environment और सबसे शुरुआती values[].timestamp का उपयोग होता है।
• service (string, वैकल्पिक): जब change_event छोड़ा गया हो, तब timestamp के साथ आवश्यक।
• timestamp (string, वैकल्पिक): RFC3339 या unix seconds, जिसे निकटतम पिछले मिनट तक राउंड डाउन किया जाता है।
• env (string, वैकल्पिक): सटीक environment। डिफ़ॉल्ट: इवेंट का environment, अन्यथा सभी।
• baseline_minutes (integer, वैकल्पिक): डिफ़ॉल्ट: 60। 30..120 तक सीमित।
• after_minutes (integer, वैकल्पिक): डिफ़ॉल्ट: baseline_minutes। 30..120 तक सीमित और वर्तमान समय से आगे नहीं।

regression likely तब लागू होता है जब इनमें से कोई भी शर्त पूरी हो: सेवा या उसके शीर्ष 10 callers में से किसी एक के लिए error rate कम-से-कम 1 percentage point बढ़े, p95 कम-से-कम 40% बढ़े, या throughput (rpm) कम-से-कम 50% घटे। callers को दोनों विंडो के संयुक्त throughput के आधार पर क्रमबद्ध किया जाता है (बदलाव से पहले कम-से-कम 100 requests और throughput के मामले में बदलाव के बाद भी कम-से-कम 100 requests होने चाहिए; p95 केवल latency_env के requests गिनता है); उनके लिए कोई alert बदलाव के बाद firing शुरू करे और बाद की विंडो के अंत में भी firing हो (alert group name या service, service_name या service.name label से, case-insensitive मिलान; अन्यथा annotation से; summary जैसे सामान्य टेक्स्ट से कभी नहीं); env के साथ, किसी अन्य environment के label वाले alerts को अनदेखा किया जाता है (case की परवाह किए बिना) और बिना label वाले alerts को env_match: unlabelled के रूप में चिह्नित किया जाता है; या get_apm_service_deviations से regression मिले। insufficient data तब लागू होता है जब बाद की विंडो 5 मिनट से कम हो (भविष्य में होने वाला बदलाव भी शामिल), सेवा के requests बहुत कम हों, या golden signals, direct-caller lookup, alerts या get_apm_service_deviations विफल हों—पूरी तरह या deviations.apm.unavailable में सूचीबद्ध किसी भी query में: साक्ष्य न मिलने पर कभी no significant change नहीं मिलता, और यदि फिर भी regression मिले तो बताया जाता है कि क्या विफल हुआ। no significant change एक मान्य उत्तर है, विफलता नहीं। Trace-attribute deviations केवल तभी चलाए जाते हैं जब env सेट हो, और प्रत्येक ओर अधिकतम 15 मिनट की अवधि में; वे verdict की व्याख्या करते हैं, लेकिन उसे निर्धारित नहीं करते। इसलिए उन्हें छोड़ने या उन्हें प्राप्त करने में विफल होने से verdict नहीं बदलता। हर सूची में 10 आइटम रखे जाते हैं और छोड़े गए आइटमों की संख्या बताई जाती है; upstream कॉल विफल होने पर केवल उसके अनुभाग में error रहता है। Golden-signal latency दोनों विंडो में एक ही environment से आती है, जिसका नाम latency_env में दिया जाता है: यदि env न हो, तो सबसे व्यस्त environment चुना जाता है। Golden-signal error rate में 5xx और gRPC errors गिने जाते हैं; deviations.apm में error-status spans और 429s भी गिने जाते हैं। Caller के signals उसके अपने server spans होते हैं, इसलिए केवल client वाले callers का rpm 0 दिखता है।

regressions में regression likely के पीछे मौजूद हर trigger के लिए एक entry होती है, reason के क्रम में; अन्य verdicts के लिए यह [] होता है। हर entry में service, role (changed या dependent), env, metric (इनमें से ठीक एक: error_rate_pct, latency_p95_ms, throughput_rpm, alert, apm_deviation) और metric की इकाई में baseline/after होते हैं (%, ms, rpm या APM signal का अपना मान; alert के लिए null)। alert आइटम में rule_id और state भी होते हैं, जो उस instance की स्थिति बताते हैं जिसे सूचीबद्ध करने वाले बाद की विंडो के सबसे नए alerts-monitor slice में दिखाया गया हो; यह हमेशा firing होता है: बदलाव के बाद शुरू हुआ लेकिन बाद की विंडो के अंत तक resolve हो चुका alert regression नहीं है, इसलिए उससे कोई ticket नहीं बनता; वह अपने state के साथ alerts.started में रहता है और reason उसकी गिनती करता है। env वह environment है जिसमें metric मापा गया: अनुरोधित env, अन्यथा error rate और throughput सभी environments (env: "") का योग लेते हैं, जबकि p95 सबसे व्यस्त environment का उपयोग करता है, latency_env; alert अपना env label उपयोग करता है और APM deviation अपना env। हर regression सेवा-व्यापी होता है, इसलिए कोई भी endpoint का नाम नहीं बताता।

get_alert_groups

changeboard / label-coverage ऑडिट के लिए कॉन्फ़िगर किए गए Compass alert-group की सूची। इसमें शून्य rules वाले और firing न कर रहे groups भी शामिल हैं। PromQL नहीं लौटाता।

• alert_group_name / alert_group_type / data_source_name (string, वैकल्पिक): case-insensitive substring मिलान।
• team / tier (string, वैकल्पिक): कॉन्फ़िगर किए गए metadata पर सटीक case-insensitive मिलान।
• label_key + label_value (string, वैकल्पिक): दोनों एक साथ सेट होने चाहिए। एक metadata.labels जोड़ी पर सटीक case-insensitive मिलान — key और value दोनों।

id, name, type, entity_class, team, tier, metadata.labels और rule counts वाला संक्षिप्त JSON {"count":N,"groups":[...]} लौटाता है। खाली team / labels का अर्थ है कि मान सेट नहीं है।

get_alert_operations_summary

• start_time_iso / end_time_iso (string, आवश्यक): RFC3339 विंडो, अधिकतम 31 दिन।
• timezone (string, वैकल्पिक): दिन की सीमाओं के लिए IANA नाम। डिफ़ॉल्ट: UTC।
• severities / services (array, वैकल्पिक): सारांश का दायरा सीमित करें।
• include_rules (boolean, वैकल्पिक): प्रति-rule hygiene भी लौटाएँ ( fire_count के आधार पर शीर्ष 20, flapping और unrouted rules; जब API ने अपनी rule सूची सीमित की हो, तब truncated सहित)। डिफ़ॉल्ट: false।

alerts_raised, acknowledged, unacknowledged, current_backlog, delivered, notification_outcomes, top_rules, needs_attention और coverage वाला JSON लौटाता है। हर metric {status, count?, reason?} होता है; partial count केवल विंडो के एक हिस्से को कवर करता है और न्यूनतम सीमा नहीं है।

get_alert_coverage

किसी सेवा, environment, एक alert group या—जब कोई scope न दिया गया हो—पूरे संगठन के लिए “मैं किन चीज़ों पर alert नहीं कर रहा हूँ?” का उत्तर देता है। केवल पढ़ने के लिए: यह कभी कुछ बनाता, बदलता या unmute नहीं करता। investigate toolset में भी उपलब्ध है।

• service (string, वैकल्पिक): सेवा का नाम।
• environment (string, वैकल्पिक): Deployment environment (उदाहरण के लिए prod)।
• entity_id (string, वैकल्पिक): Alert group (entity) UUID, जैसा get_alert_groups से लौटाया गया हो।
• muted_days (integer, वैकल्पिक): पूरे दिन, 1 से 3650 तक। डिफ़ॉल्ट: 7; 0 का अर्थ है डिफ़ॉल्ट। इससे अधिक समय तक muted rule को muted_too_long gap माना जाता है। मानों के आगे-पीछे की खाली जगह हटाई जाती है; खाली स्ट्रिंग अनदेखी की जाती हैं। गैप के प्रकार: uncovered_signal (latency, error_rate, throughput या saturation पर कोई सक्षम नियम नहीं; उस अक्षम नियम का नाम बताता है जो इसे कवर करेगा), all_rules_disabled (ऐसा अलर्ट समूह जिसके सभी नियम अक्षम हैं), no_notification_channel (ऐसा नियम जिसकी severity के लिए उसके अलर्ट समूह का कोई चैनल रूट नहीं करता), muted_too_long (अनिश्चित काल के लिए या muted_days से अधिक समय के लिए म्यूट किया गया; muted_since नियम का आखिरी अपडेट है और अनिश्चितकालीन म्यूट के लिए mute_until शामिल नहीं होता)।

संक्षिप्त JSON {scope, generated_at, complete, summary, counts, groups} लौटाता है। groups में मौजूद हर प्रकार के लिए एक {kind, count, gaps, omitted} प्रविष्टि होती है, जिसमें प्रति प्रकार अधिकतम 10 गैप सूचीबद्ध होते हैं (omitted बाकी गैप की संख्या बताता है; उन्हें देखने के लिए दायरा सीमित करें); हर गैप में suggested_tool (create_alert, create_alert_from_chart, attach_notification_channel या patch_alert) और suggested_args होता है, जिसमें केवल वे इनपुट होते हैं जिन्हें टूल स्वीकार करता है (patch_alert: entity_id, id और is_disabled=false या mute_until=0; attach_notification_channel: alert_group_id और एक breach/threat severity; create_alert: entity_id; create_alert_from_chart: service_name); गैप के अपने entity_id, rule_id और signal इनके साथ सूचीबद्ध होते हैं। सुझाए गए टूल को केवल तभी कॉल करें जब वह सत्र में उपलब्ध हो और उपयोगकर्ता पुष्टि करे। complete केवल तभी true होता है जब API कोई गैप सूचीबद्ध न करे, हर गिनती 0 हो और कम-से-कम एक अलर्ट समूह दायरे से मेल खाता हो (सटीक service_name / env लेबल, जिनकी जाँच get_alert_groups की सूची से की जाती है); किसी भी समूह से मेल न खाने वाला दायरा, विफल लुकअप या बिना सूचीबद्ध गैप वाली गिनतियाँ पूर्ण नहीं मानी जातीं, और summary इसका कारण बताता है।

get_alert_config

• search_term (string, optional): नाम, समूह, डेटा स्रोत और टैग में फ़्री-टेक्स्ट खोज।
• rule_name (string, optional)
• severity (string, optional)
• rule_type (string, optional): static या anomaly।
• alert_group_name / alert_group_type / data_source_name (string, optional)
• tags (array, optional): सभी का मेल होना चाहिए (AND लॉजिक)।

हर नियम में Recent Evaluations सूचीबद्ध होता है: एक मिनट के 5 नमूने, नवीनतम पहले; हर नमूने पर वह UTC मिनट अंकित होता है जिस पर वह समाप्त होता है। नवीनतम नमूना कॉल से 1–2 मिनट पहले समाप्त होता है, क्योंकि मॉनिटर नवीनतम मिनट का डेटा देर से भरता है। firing; ok = मॉनिटर ने बताया कि नियम फ़ायर नहीं हो रहा था (सामान्य, हल की गई, लंबित या खाली स्थिति, जैसा कि is_firing=0 में get_alert_rule_state); unknown = नियम के लिए मॉनिटर की कोई पंक्ति नहीं (अभी मूल्यांकन नहीं हुआ, या उस मिनट का लुकअप विफल हुआ, जिसका उल्लेख प्रतिक्रिया के शीर्ष पर होता है), या ऐसी पंक्ति जिसकी स्थिति firing, normal, resolved, pending या empty में से कोई नहीं है (जैसे no_data, silenced)। अक्षम नियमों के लिए कुछ नहीं दिखता। जब 25 से अधिक सक्षम नियम मेल खाते हैं, तो उन सभी के लिए इतिहास छोड़ दिया जाता है और प्रतिक्रिया में इसकी जानकारी दी जाती है।

get_entity_kpis

केवल पढ़ने के लिए; alerts और investigate टूलसेट में। एक अलर्ट समूह के हर KPI की सूची देता है, जिनमें वे KPI भी शामिल हैं जिनका उपयोग अभी कोई अलर्ट नियम नहीं करता। लौटाए गए ID का उपयोग expression_args / indicators_used में करें; कभी कोई ID न गढ़ें।

• entity_id (string, required): अलर्ट समूह/एंटिटी UUID, get_alert_groups या get_alert_config से।

JSON {"entity_id","count","kpis":[{"id","name","description","query","unit"}]} लौटाता है, नाम के अनुसार क्रमबद्ध। unit केवल प्रदर्शन लेबल है: थ्रेशोल्ड की तुलना क्वेरी के कच्चे मान से होती है। जब कोई KPI उपयुक्त न हो, तो create_kpi से एक बनाएँ। खाली समूह के परिणाम में create_kpi का नाम केवल तभी आता है जब सत्र उसे उपलब्ध कराता हो; --read-only के साथ (जब तक कि --allow-write-tools=create_kpi न हो) या investigate टूलसेट में, इसके बजाय यह बताता है कि KPI बनाने के लिए लिखने योग्य alerts सत्र चाहिए।

create_kpi

मौजूदा अलर्ट समूह पर KPI बनाता है; केवल alerts टूलसेट में। इसका उपयोग केवल तभी करें जब get_entity_kpis में आपकी ज़रूरत वाली क्वेरी वाला कोई KPI न हो। पहले prometheus_range_query से जाँचें कि क्वेरी डेटा लौटाती है: API केवल ऐसी क्वेरी को अस्वीकार करता है जिसका पार्स होना संभव न हो, और ऐसे मेट्रिक के लिए भी मान्य क्वेरी सहेजता है जो मौजूद नहीं है।

• entity_id (string, required): अलर्ट समूह/एंटिटी UUID।
• name (string, required): अलर्ट समूह के भीतर अद्वितीय; उसी नाम से दूसरी बार बनाने पर conflict के रूप में अस्वीकार किया जाता है।
• query (string, required): PromQL। डैशबोर्ड पैनल पर अलर्ट करने के लिए, पैनल का PromQL get_dashboard से लें।
• unit (string, required): क्वेरी के कच्चे मान की इकाई, जैसे seconds, ms, percent, ratio, count, req/s। यह केवल एक लेबल है और कोई रूपांतरण नहीं करता, इसलिए थ्रेशोल्ड की तुलना कच्चे मान से होती है।
• description (string, optional)
• data_source_id (string, optional): डिफ़ॉल्ट रूप से अलर्ट समूह का डेटा स्रोत।

कोई MCP टूल KPI को हटाता या संपादित नहीं करता (Last9 UI का उपयोग करें), इसलिए बनाने से पहले नाम, क्वेरी और इकाई की पुष्टि करें। एक बार बनाएँ और लौटाया गया ID expression_args / indicators_used के लिए रखें; नाम के conflict पर, get_entity_kpis से मौजूदा KPI का ID फिर से उपयोग करें। टाइमआउट या कनेक्शन त्रुटि होने पर KPI बन भी सकता है और नहीं भी: दोबारा प्रयास करने से पहले get_entity_kpis से नाम के आधार पर जाँचें। {"id","name","query","unit"} लौटाता है।

get_alerts

• time_iso (string, optional): RFC3339 में मूल्यांकन का समय।
• window (integer, optional): सेकंड में पीछे की अवधि। डिफ़ॉल्ट: 900। सीमा: 60–86400।
• lookback_minutes (integer, optional): सीमा: 1–1440।

get_alert_rule_state

• start_time (integer or string, required): अवधि की शुरुआत (समावेशी): Unix epoch सेकंड (1718000000) या RFC3339 (2024-06-10T06:13:20Z)। Epoch मिलीसेकंड, माइक्रोसेकंड और नैनोसेकंड को सेकंड में बदला जाता है; 2000-01-01 से पहले के मान अस्वीकार किए जाते हैं।
• end_time (integer or string, required): अवधि का अंत (समावेशी), उन्हीं फ़ॉर्मैट में।
• step (integer, required): नमूनों के बीच सेकंड में रिज़ॉल्यूशन। नमूनों की संख्या ((end_time - start_time) / step + 1) अधिकतम 100 तक सीमित है। हर नमूना एक upstream कॉल है, जो अपने टाइमस्टैम्प पर समाप्त होने वाले min(step, 3600) सेकंड को कवर करता है; नमूने एक बार में 5 की दर से प्राप्त किए जाते हैं, और यदि उन्हें 60s से अधिक समय लगे तो टूल पुनः प्रयास के निर्देशों के साथ त्रुटि लौटाता है।
• alert_group_id (string, optional): अलर्ट समूह ID से फ़िल्टर करें।
• rule_name (string, optional): नियम के नाम पर regex फ़िल्टर।
• alert_group_name (string, optional): अलर्ट समूह के नाम पर regex फ़िल्टर।
• label_filters (string, optional): कॉमा से अलग किए गए key=value लेबल फ़िल्टर।
• state (string, optional): स्थिति से फ़िल्टर करें (जैसे firing)।

rule_id -> [{timestamp, is_firing}] का JSON मैप लौटाता है। जिस टाइमस्टैम्प पर upstream प्रतिक्रिया में कोई नियम मौजूद नहीं होता, उसे is_firing=0 के रूप में रिपोर्ट किया जाता है — इसका अर्थ है “firing के रूप में नहीं देखा गया”, न कि पुष्टि की गई सामान्य स्थिति।

get_alert_hygiene

सक्षम अलर्ट नियमों का केवल-पढ़ने वाला ऑडिट। यह कभी कुछ नहीं बदलता: हर सुझाया गया सुधार एक प्रस्ताव है, जिसे उपयोगकर्ता की स्पष्ट पुष्टि के बाद ही update_alert (ट्यूनिंग), patch_alert (is_disabled), delete_alert या attach_notification_channel के माध्यम से लागू किया जाता है, जब ये उपलब्ध हों।

• window (string, optional): 7d या 30d। डिफ़ॉल्ट: 7d।
• limit (integer, optional): लौटाए जाने वाले फ़्लैग किए गए नियमों की अधिकतम संख्या, सबसे खराब पहले। डिफ़ॉल्ट: 20। सीमा: 1–100।

अवधि अभी समाप्त होती है। श्रेणियाँ (किसी नियम की एक से अधिक श्रेणियाँ हो सकती हैं): noisy (< 20% acked; with an unavailable ack_rate it is judged on fire rate alone and the reason says so; mute time is not reported), flapping (> 4 flaps/day के साथ ≥ 5 fires/day), stale (अवधि से पहले आखिरी बार फ़ायर हुआ और अवधि में कोई फ़ायरिंग समय नहीं, या ऐसा सक्षम कॉन्फ़िगर किया गया नियम जिसकी अवधि में कोई episode नहीं है, जबकि lifecycle coverage पूरा है और API की सूची truncated नहीं है), unrouted (अवधि में कोई फ़ायरिंग चैनल तक नहीं पहुँची और अलर्ट समूह से अभी कोई चैनल जुड़ा नहीं है; जब अटैचमेंट नहीं पढ़े जा सकते, तो नियम इसके बजाय unavailable.routed के अंतर्गत आता है)। हर आँकड़ा {status, count|value, reason} या null होता है: अनुपलब्ध मान को कभी शून्य नहीं माना जाता और केवल वही जाँच छोड़ी जाती है जिसके लिए उस मान की ज़रूरत है; unavailable हर अनुपलब्ध मान के लिए सक्षम नियमों की संख्या बताता है (fire_count, flap_count, ack_rate, routed, rule_config उन नियमों के लिए जो अलर्ट नियमों की सूची में नहीं हैं, जिनके सुधारों में वर्तमान मान नहीं होता, और activity उन कॉन्फ़िगर किए गए नियमों के लिए जिनका कोई episode नहीं है और जिनकी चुप्पी इतिहास से साबित नहीं की जा सकती, इसलिए उनका आकलन नहीं किया जाता)। coverage बताता है कि अलर्ट इतिहास ने अवधि का कितना हिस्सा कवर किया; दरों की गणना कवर की गई अवधि के आधार पर होती है, जो कम-से-कम एक दिन होती है। upstream_truncated true होता है जब API ने केवल सबसे अधिक शोर करने वाले 200 नियम लौटाए हों, इसलिए कम शोर वाले नियमों का मूल्यांकन नहीं किया गया। सुधार, अलर्ट नियमों की सूची में हर नियम के कॉन्फ़िगरेशन से बनाए जाते हैं: bad_minutes बढ़ाएँ (count_true(result) >= N में N) या eval_window को लंबा करें (अधिकतम 60 मिनट); शोर करने वाले स्थिर थ्रेशोल्ड के लिए, थ्रेशोल्ड को condition (expr > 100) में ले जाएँ या एक्सप्रेशन को adaptive_std_cmp(metric, sensitivity, window) पर स्विच करें; नोटिफ़िकेशन चैनल जोड़ें; पुराने नियमों को अक्षम या हटाएँ।

32 KB के लक्ष्य के अनुसार आकार में सीमित संक्षिप्त JSON {window, from, to, coverage, upstream_truncated, rules_evaluated, flagged_rules, truncated, omitted_for_size, unavailable, rules} लौटाता है: truncated true होता है जब फ़्लैग किए गए नियमों की संख्या limit से अधिक हो या लक्ष्य से बड़ी हो, और omitted_for_size उन नियमों की संख्या बताता है जिन्हें आकार के लिए limit से काटा गया है (सबसे खराब नियम हमेशा रखा जाता है, इसलिए 32 KB से बड़ा एक अकेला नियम ही लौटता है और लक्ष्य से अधिक होता है); हर नियम में findings (category, reason, suggested_fix, वैकल्पिक alternative_fix) और कच्चा stats होता है।

get_notification_channels

• scope (string, optional): attached (डिफ़ॉल्ट) हर अलर्ट-समूह अटैचमेंट के लिए एक पंक्ति लौटाता है; id एक अटैचमेंट ID है, जिसे detach_notification_channel लेता है। channels संगठन के चैनल लौटाता है (id, name, type, send_resolved, created_via); id एक चैनल ID है, जिसे attach_notification_channel लेता है। डेस्टिनेशन, हेडर और सर्टिफ़िकेट कभी नहीं लौटाए जाते।

कॉन्फ़िगर किए गए नोटिफ़िकेशन चैनल (Slack, PagerDuty, ईमेल, वेबहुक आदि) TSV तालिका के रूप में लौटाता है। अटैचमेंट पंक्तियों (service_fqid सेट) में global false और services - दिखता है; services केवल पुराने service bindings सूचीबद्ध करता है। अटैचमेंट पंक्तियों पर send_resolved पंक्ति का संग्रहीत डिफ़ॉल्ट होता है, न कि डिलीवरी में उपयोग होने वाला मान; resolve notifications चैनल के अपने send_resolved (scope=channels) का पालन करते हैं। दोनों दायरों में created_via शामिल होता है (last9-mcp उन पंक्तियों के लिए जिन्हें MCP एजेंट ने बनाया, अन्यथा -)।

recommend_alert_config

केवल पढ़ने के लिए। lifecycle मार्गदर्शन, सत्यापन गेट और responder-context की आवश्यकताएँ लौटाता है; यह अपने आप में प्रमाण नहीं है, इसलिए थ्रेशोल्ड तय करने के लिए टेलीमेट्री टूल का उपयोग करें।

• signal (string, required): मेट्रिक या उपयोगकर्ता-प्रभाव संकेत, जिसमें इकाई और आयाम शामिल हों।
• objective (string, required): पता लगाने के लिए लक्षण या उपयोगकर्ता पर प्रभाव।
• rule_type (string, optional): static (डिफ़ॉल्ट) या anomaly।
• severity (string, optional): breach (डिफ़ॉल्ट) या threat।
• environment (string, optional): वातावरण और ट्रैफ़िक प्रोफ़ाइल।

validate_alert_expression

किसी एक्सप्रेशन को सहेजे बिना उसका dry-run करता है। create_alert / update_alert से पहले इसका उपयोग करें।

• entity_id (string, required): अलर्ट समूह/एंटिटी UUID।
• expression (string, required): KPI के सटीक नाम से पहचाने गए इंडिकेटर पर अंकगणित, जैसे errors / requests। अधिकतम 3 इंडिकेटर। स्पेस, डॉट या डैश वाले नाम ज्यों के त्यों लिखें (Test Alert / errors), ठीक वैसे ही जैसे create_alert उन्हें सहेजता है।
• indicators_used (object, required, non-empty): इंडिकेटर नाम से entity_id के स्वामित्व वाले KPI UUID का मैप; समूह के KPI ID और नाम get_entity_kpis से सूचीबद्ध करें। हर KPI का सटीक नाम उपयोग करें: यह dry-run कोई भी नाम स्वीकार करता है, लेकिन create_alert और update_alert उन expression_args कुंजियों को अस्वीकार करते हैं जो बाउंड KPI के नाम से मेल नहीं खातीं। केवल अंकगणितीय एक्सप्रेशन की जाँच की जाती है (भीतरी metric expression पास करें, adaptive_std_cmp(...) wrapper नहीं); condition / alert_condition की जाँच नहीं होती। कम-से-कम एक timeseries की जाँच केवल तभी चलती है जब एक से अधिक indicators का उपयोग किया गया हो।

{"valid":true} या {"valid":false,"reason":"..."} लौटाता है; अमान्य एक्सप्रेशन एक सामान्य परिणाम है, tool error नहीं।

describe_alert_chart

केवल पढ़ने के लिए। कवर किए गए Discover chart पर alert किए जा सकने वाले signals (key, unit, eval_query, query_kind) की सूची देता है। Viewer-role tokens अस्वीकार किए जाते हैं।

• surface (string, required): discover-service या discover-exceptions; custom dashboards सहित कोई भी अन्य surface, API कॉल करने से पहले अस्वीकार कर दिया जाता है (इसके बजाय KPI के साथ create_alert का उपयोग करें)।
• chart_key (string, required): उदाहरण के लिए, apdex, error_rate, response_time, exception_count।
• service_name (string, required)
• env (string, optional)
• attributes (object, optional): अतिरिक्त identity dimensions, इस tool द्वारा रिपोर्ट किए गए key names का उपयोग करते हुए।

create_alert

मौजूदा alert group में एक rule बनाता है, जो हमेशा disabled रहता है (एक draft, भले ही is_disabled=false पास किया गया हो)। पहले recommend_alert_config कॉल करें, फिर उपयोगकर्ता की पुष्टि के बाद ही patch_alert is_disabled=false से promote करें। इसे एक बार बनाएँ और लौटाया गया rule ID सुरक्षित रखें। यदि alert group पहले से rule_name का उपयोग करता है (case-insensitive), तो कुछ भी बनाए बिना अनुरोध अस्वीकार कर दिया जाता है और मौजूदा rule का id बताया जाता है।

• entity_id (string, required): Alert group/entity UUID।
• alert_rule (object, required): पूरा typed rule body, जिसमें entity के वास्तविक KPIs से जुड़े primary_indicator और expression_args शामिल हों। प्रत्येक expression_args key उस KPI का सटीक नाम होना चाहिए जिससे वह जुड़ता है (जैसे x जैसा placeholder नहीं), और primary_indicator तथा expression में उन्हीं नामों का उपयोग होना चाहिए। Static rules के लिए condition, alert_condition, और eval_window (0–60 मिनट) आवश्यक हैं। Adaptive rules में expression = adaptive_std_cmp(<primary_indicator>, sensitivity, window) का उपयोग होता है; तब ये तीनों fields वैकल्पिक हैं (डिफ़ॉल्ट expr > 0, count_true(result) >= 1, 1)। algorithm सेट नहीं किया जा सकता। Responder context को properties में रखें (description, runbook, annotations, query_mode)।

Notification routing alert group पर कॉन्फ़िगर की जाती है, rule पर नहीं।

create_alert_from_chart

describe_alert_chart द्वारा वर्णित chart से static-threshold rule बनाता है। create_alert की तरह, rule disabled draft के रूप में बनाया जाता है और fire नहीं होता; उपयोगकर्ता की पुष्टि के बाद ही इसे patch_alert is_disabled=false से promote करें। Chart API rules को enabled बनाती है, इसलिए tool rule बनाने के तुरंत बाद उसे disable कर देता है; यदि यह विफल होता है, तो परिणाम में rule id वाला error आता है और rule live हो सकता है।

• surface / chart_key / service_name / signal_key / name (string, required)
• env (string, optional)
• attributes (object, optional)
• threshold (number, optional): Signal की इकाई में; 0 या उससे अधिक होना चाहिए। Apdex जैसे score-unit signals के लिए स्पष्ट मान आवश्यक है।
• threshold_operator (string, optional): > (डिफ़ॉल्ट), <, >=, <=, ==, !=।
• eval_window (integer, optional): मिनट, 1–60। डिफ़ॉल्ट: 5।
• bad_minutes (integer, optional): 1–eval_window। डिफ़ॉल्ट: 3।
• severity (string, optional): breach या threat।
• description (string, optional)
• group_id (string, optional): सामान्यतः छोड़ दें।

update_alert

Rule के evaluation config को पूरी तरह बदलता है। पहले get_alert_config या get_entity_alert_rules से rule प्राप्त करें। यदि rule मौजूद नहीं है या किसी अन्य alert group का है, तो बिना कोई बदलाव किए अनुरोध अस्वीकार कर दिया जाता है। Rule को soft-delete करके फिर से बनाया जा सकता है, इसलिए इसके बाद लौटाई गई replacement ID का उपयोग करें।

• entity_id (string, required)
• id (string, required): Alert rule UUID।
• alert_rule (object, required): पूरा configuration; इसका shape create_alert जैसा ही है।

patch_alert

आंशिक बदलाव, जो rule ID को बनाए रखता है। कम-से-कम एक बदलाव आवश्यक है। यदि rule मौजूद नहीं है या किसी अन्य alert group का है, तो बिना कोई बदलाव किए अनुरोध अस्वीकार कर दिया जाता है।

• entity_id (string, required)
• id (string, required): Alert rule UUID।
• is_disabled (boolean, optional): false promote/enable करता है, true pause करता है।
• mute_until (integer, optional): Unix epoch deadline; 0 unmute करता है।
• properties (object, optional): description, runbook, annotations, query_mode। भेजा गया प्रत्येक field संग्रहीत field को बदल देता है; छोड़े गए या खाली fields अपने संग्रहीत मान बनाए रखते हैं। annotations पूरा map बदल देता है, इसलिए बनाए रखने के लिए हर key भेजें; {} इसे साफ़ करता है।
• recurring_mute_schedule (object, optional): साप्ताहिक schedule बदलता है: enabled (डिफ़ॉल्ट false), timezone (IANA name, required), और windows (weekdays में से 1–20, sun..sat के रूप में, start_time / end_time को 24-hour HH:MM के रूप में)। यदि end, start के बराबर या उससे पहले हो, तो यह अगले दिन समाप्त होता है। बनाए रखने के लिए हर window भेजें।
• clear_recurring_mute_schedule (boolean, optional): Schedule को पूरी तरह हटाता है; इसे recurring_mute_schedule के साथ नहीं जोड़ा जा सकता। यह enabled=false से अलग है, जो windows को संग्रहीत रखता है।

Viewer-role users केवल mute_until बदल सकते हैं। Group या entity muted होने पर rule-level mute में बदलाव अस्वीकार किए जाते हैं। बदलावों को get_entity_alert_rules से वापस पढ़ें, जो mute_until, recurring_mute_schedule और properties दिखाता है।

delete_alert

किसी rule को स्थायी रूप से हटाता है। पहले get_alert_config से सत्यापित करें और उपयोगकर्ता से स्पष्ट पुष्टि लें। यदि rule मौजूद नहीं है या किसी अन्य alert group का है, तो बिना कुछ हटाए अनुरोध अस्वीकार कर दिया जाता है।

• entity_id (string, required)
• id (string, required): Alert rule UUID।

mute_alert_group

किसी group के सभी मौजूदा और भविष्य के rules को mute करता है; एक rule को mute करने के लिए mute_until के साथ patch_alert का उपयोग करें। Editor access आवश्यक है।

• entity_id (string, required): Alert group/entity UUID।
• until (integer, required): Mute समाप्त होने का Unix epoch seconds। 0 unmute करता है; -1 जैसा ऋणात्मक मान अनिश्चितकाल के लिए mute करता है।

acknowledge_alert

Firing alert का स्वामित्व लेता है या उसे छोड़ता है। Alert को resolve या mute नहीं करता। जिस alert के आप पहले से owner हैं, उसे acknowledge करना सुरक्षित no-op है। ack कुछ भी रिकॉर्ड किए बिना अनुरोध अस्वीकार कर देता है, जब तक कि get_alerts में पिछले घंटे के भीतर वही सटीक alert (तीनों ids) सूचीबद्ध न हो।

• alert_group_id / rule_id / rule_type (string, required): get_alerts में alert से कॉपी करें।
• action (string, optional): ack (डिफ़ॉल्ट) या unack। केवल owner या org admin unack कर सकता है।
• mute_until (integer, optional): केवल ack। mute_alert_group या patch_alert से पहले से लागू किए गए mute को रिकॉर्ड करता है; कुछ भी mute नहीं करता।

reassign_alert

जिस alert का पहले से owner है, उसे किसी अन्य user को सौंपता है; यदि उसका कोई owner नहीं है, तो पहले acknowledge करें। यदि alert का कोई owner न होने के कारण कुछ भी reassign नहीं होता, तो यह बताता है कि क्या get_alerts में पिछले घंटे के भीतर वह alert सूचीबद्ध है। Last9 नए owner को सूचित नहीं करता।

• alert_group_id / rule_id / rule_type (string, required): get_alerts में alert से कॉपी करें।
• owner_email (string, optional): प्राथमिकता वाला विकल्प; active org users से case-insensitive मिलान किया जाता है।
• owner_user_id (string, optional): owner_email या owner_user_id में से ठीक एक दें।

create_notification_channel

एक channel बनाता है; attach_notification_channel से जोड़ने तक यह कुछ भी route नहीं करता। इसे एक बार बनाएँ और id सुरक्षित रखें; update tool उपलब्ध नहीं है। केवल id, name, type, और send_resolved लौटाता है।

• name (string, required): हर type के लिए unique; colon नहीं होना चाहिए।
• type (string, required): slack, pagerduty, opsgenie, email, या generic_webhook।
• destination (string, required): Slack Incoming Webhook URL (या slack_app_mode के साथ channel ID), PagerDuty routing key, Opsgenie API key, किसी भी domain के comma-separated work email addresses (केवल org के domain तक सीमित नहीं; API Gmail जैसे personal-provider addresses अस्वीकार करती है, और personal login वाले org में केवल उसके admin का address स्वीकार होता है), या HTTPS webhook URL।
• slack_app_mode (boolean, optional): केवल Slack के लिए। डिफ़ॉल्ट: false।
• mention_handles (string, optional): Comma-separated, उदाहरण के लिए user|U123ABC|name, special|here, special|channel।
• webhook_headers (object, optional): केवल generic_webhook।
• webhook_ca_certificate (string, optional): केवल generic_webhook; अधिकतम 64 KiB का एक PEM CA certificate।
• send_resolved (boolean, optional): डिफ़ॉल्ट: true।

attach_notification_channel

किसी मौजूदा channel को एक alert group पर route करता है। Idempotent। Attachments, attach करते समय channel की delivery settings (headers, certificate, mentions) की प्रतिलिपि बनाते हैं; यदि बाद में channel की settings बदलें, तो फिर से attach करें।

• channel_id (integer, required): Channel id (scope=channels के साथ get_notification_channels), attachment id नहीं।
• alert_group_id (string, required): get_alert_groups से।
• severity (string, required): breach, threat, या both। both दो attachments बनाता है; यदि दूसरा विफल हो, तो पहला attached रहता है और error में retry करने की severity बताई जाती है।

detach_notification_channel

एक attachment हटाता है। Delete-scope token आवश्यक है; write-scope token से detach नहीं किया जा सकता।

• attachment_id (integer, required): scope=attached के साथ get_notification_channels से प्राप्त id। Channel ids अस्वीकार किए जाते हैं।
• alert_group_id (string, optional): यदि attachment किसी दूसरे group का है, तो अनुरोध अस्वीकार कर दिया जाता है।

delete_notification_channel

ऐसे channel को स्थायी रूप से हटाता है जिसके कोई attachments नहीं हैं; पहले उसके attachments detach करें। Delete-scope token आवश्यक है। Channels की सूची फिर से लेकर deletion की पुष्टि करता है।

• channel_id (integer, required): scope=channels के साथ get_notification_channels से प्राप्त id। Attachment ids अस्वीकार किए जाते हैं।

did_you_mean

• query (string, required): खोजने के लिए नाम — आंशिक, गलत वर्तनी वाला, या संक्षिप्त।
• type (string, optional): Entity type तक सीमित करें: service, environment, host, database, k8s_deployment, k8s_namespace, job।

Similarity scores के साथ अधिकतम 3 निकटतम matches लौटाता है। जहाँ entity का नाम अनिश्चित हो, वहाँ किसी भी tool call से पहले इसका उपयोग करें। यदि पिछली call में खाली परिणाम मिले हों, तो दोबारा प्रयास करने से पहले इसका उपयोग करें।

get_service_profile

• service_name (string, required): वह service जिसके लिए telemetry profile निकाली जानी है।
• datasource (string, optional): Datasource का नाम। डिफ़ॉल्ट के लिए छोड़ दें; अनुमानित नाम Prometheus tools की तरह resolve होता है। एक संक्षिप्त जाँच विवरण और उसके बाद पूरा प्रोफ़ाइल कच्चे JSON के रूप में लौटाता है: सिग्नल की मौजूदगी (logs/traces/metrics को present, absent, या unknown के रूप में), भाषा और रनटाइम, डिप्लॉयमेंट परिवेश, लॉग signal_shape (log_format, severity_set, level_field, trace_context_in_logs), और जहाँ लागू हो, सुझाया गया ingest सुधार। जब बैकएंड freshness की रिपोर्ट करता है, तो विवरण में last seen पंक्ति जुड़ती है, जिसमें freshness.logs.last_seen और freshness.traces.last_seen (RFC3339, या null होने पर none) होते हैं, और जब freshness.traces_stale का मान true हो, तो traces stale चेतावनी भी जुड़ती है: spans रुक गए, जबकि logs जारी रहे; इसलिए सेटअप की कमी नहीं, बल्कि freshness.traces.last_seen के आसपास हुए regression की जाँच करें। Upstream से प्राप्त और कैश किया गया; TTL लगभग 15 मिनट है।

किसी भी service-scoped जाँच से पहले इसे कॉल करें, ताकि टूल का चयन सेवा की वास्तविक telemetry से मेल खाए — यदि traces का मान absent हो, तो trace टूल छोड़ दें; और जब severity_set का मान none या partial हो, तो severity_filters का उपयोग करने के बजाय log body में मौजूद level_field से severity पार्स करें। metrics हमेशा unknown होता है और v1 में dependencies भरा नहीं जाता। जब logs और traces दोनों का मान absent हो, तो सेवा को unmonitored घोषित करने से पहले did_you_mean से नाम की पुष्टि करें।

list_dashboards

• name (string, वैकल्पिक): डैशबोर्ड नाम का केस-असंवेदनशील सबस्ट्रिंग। सूची को सीमित करता है और total।
• limit (integer, वैकल्पिक): प्रति पृष्ठ डैशबोर्ड की संख्या, 1–200। डिफ़ॉल्ट: 100।
• cursor (string, वैकल्पिक): पिछले पृष्ठ से मिला next_cursor; इसके साथ वही name पास करें।

{"dashboards": [{"id", "name", "updated_at", "created_by", "locked"}], "total", "next_cursor"} लौटाता है, सबसे हाल में अपडेट किए गए पहले। खाली होने पर created_by शामिल नहीं होता; जब API readonly की रिपोर्ट नहीं करता, तब locked शामिल नहीं होता। updated_at Unix epoch सेकंड को string के रूप में दर्शाता है। 32 KB से कम रहने के लिए पृष्ठ समय से पहले समाप्त हो सकता है; अंतिम पृष्ठ पर next_cursor मौजूद नहीं होता।

get_dashboard

• id (string, आवश्यक): डैशबोर्ड UUID।
• region (string, वैकल्पिक): पैनल क्वेरी भरने के लिए region। कॉन्फ़िगर किए गए datasource region का डिफ़ॉल्ट उपयोग होता है।

परिणाम में शीर्ष-स्तरीय locked जुड़ता है (API द्वारा इसे छोड़ने पर false) और created_by (लेखक का user id)।

किसी पैनल पर alert सेट करने के लिए, last9://reference/alerting देखें।

validate_dashboard

केवल पढ़ने के लिए। डैशबोर्ड कभी बनाता या अपडेट नहीं करता। dashboard_id या dashboard_definition में से ठीक एक स्वीकार करें।

• dashboard_id (string, वैकल्पिक): सत्यापन के लिए सहेजा गया डैशबोर्ड UUID।
• dashboard_definition (object, वैकल्पिक): inline, असहेजा डैशबोर्ड बॉडी (वास्तविक dry run)। {dashboard, metadata} create envelope को खोलकर उसका dashboard object लिया जाता है।
• start_time_iso / end_time_iso (string, वैकल्पिक): सत्यापन विंडो (RFC3339)। अवधि ≤ 24h होनी चाहिए।
• region (string, वैकल्पिक): पैनल क्वेरी चलाने के लिए region।

dashboard_validation/v1 लौटाता है: प्रति-पैनल lint और execute वर्गीकरण (data / no_data / invalid / error)। Day-1 के खाली परिणाम बिना diagnose probes के valid_no_data के रूप में वर्गीकृत होते हैं। बिना पैनल वाला डैशबोर्ड success: false और error: "no_panels" के साथ लौटता है। अन्य फ़ॉर्मैट के पैनल फ़ील्ड (Grafana gridPos, title, type, और उन पैनलों पर targets जिन्हें क्वेरी चाहिए) तथा गलत प्रकार वाले फ़ील्ड प्रति पैनल shape_problems में सूचीबद्ध होते हैं, summary.panels_invalid_shape में गिने जाते हैं, और overall को fail बनाते हैं।

preview_dashboard

केवल-पढ़ने वाला client-side preview। या तो dashboard (create request से मिला असहेजा डैशबोर्ड object) पास करें, या id के साथ ops (वही क्रमबद्ध operations जो patch_dashboard में हैं)। आवश्यक start_time_iso और end_time_iso RFC3339 timestamps हैं, जिनके बीच की अवधि अधिकतम 24 घंटे हो सकती है। वैकल्पिक variables में scalar overrides होते हैं; अन्यथा डैशबोर्ड के मान और अंतर्निहित डिफ़ॉल्ट लागू होते हैं।

{
  "id": "dashboard-id",
  "ops": [{"op": "update_panel", "panel_id": "panel-id", "fields": {"name": "Request latency"}}],
  "start_time_iso": "2026-10-01T08:00:00Z",
  "end_time_iso": "2026-10-01T09:00:00Z"
}

saved: false लौटाता है: परिभाषा/क्वेरी का validation सारांश (definition_error सहित, यदि create-schema मेल न खाए), और panels जिसमें ok / empty / error स्थिति, हल की गई क्वेरी और target diagnostics होते हैं। PromQL और LogJSON चलते हैं; असमर्थित क्वेरी प्रकार और अनसुलझे variables पैनल को त्रुटि बनाते हैं। मान्य, गैर-क्वेरी पैनल ok होते हैं; अमान्य पैनल परिभाषाएँ error होती हैं। Patch diff में शुद्ध panels_added, panels_changed (moves सहित) और panels_removed, साथ ही क्रमबद्ध operation बदलाव शामिल होते हैं। IDs और शून्य-आधारित indices पैनलों की पहचान करते हैं; हटाए गए indices मूल डैशबोर्ड को संदर्भित करते हैं। सहेजे गए पैनलों के IDs अलग-अलग और गैर-रिक्त होने चाहिए।

सीमाएँ: 50 पैनल, 100 क्वेरी, 100 operations, input और candidate dashboard के लिए प्रत्येक 65536 JSON bytes, और 60 सेकंड की execution deadline। 65536 JSON bytes से बड़ी हल की गई क्वेरी execution से पहले अस्वीकार कर दी जाती हैं। Evidence में प्रति target अधिकतम तीन samples और 1024 JSON bytes रखे जाते हैं; samples छोड़े जाने पर truncated: true शामिल होता है। 262144 bytes से बड़ी JSON report विफल हो जाती है और input घटाने के निर्देश देती है।

कोई डैशबोर्ड बनाया या अपडेट नहीं किया जाता। यह candidate को create schema के विरुद्ध जाँचता है और मौजूदा validator का उपयोग करके क्वेरी चलाता है; यह backend द्वारा स्वीकृति या rendering की गारंटी नहीं देता। Backend द्वारा दिए गए IDs, defaults, हटाए गए fields या समवर्ती edits सहेजे गए परिणाम को बदल सकते हैं। Preview में वही स्थानीय patch operations और panel-version defaults उपयोग होते हैं जो write में होते हैं।

create_dashboard

केवल नया डैशबोर्ड बनाने के लिए। इस कॉल के dashboard.id लौटाने के बाद, पैनल संपादित करने के लिए patch_dashboard (या संरचना बदलने के लिए update_dashboard) का उपयोग करें — पैनल जोड़ने, घटाने या ठीक करने के लिए दोबारा create न करें।

• dashboard (object, आवश्यक): name और panels[] वाली डैशबोर्ड परिभाषा। हर पैनल में name, version, layout (x, y, w, h), visualization.type, और queries[] आवश्यक हैं।
• metadata (object, वैकल्पिक): डैशबोर्ड metadata — _category और _type fields (उदाहरण के लिए {"_category":"custom","_type":"metrics"})।

update_dashboard

केवल डैशबोर्ड के अधिकांश हिस्से की संरचना बदलने के लिए उपयोग करें; अलग-अलग पैनल जोड़ने, संपादित करने, हटाने या स्थानांतरित करने के लिए patch_dashboard का उपयोग करें। ID के आधार पर पूरा प्रतिस्थापन (create जैसी ही body): हर पैनल को ठीक उसी रूप में फिर से भेजना होगा।

• id (string, आवश्यक): अपडेट करने के लिए डैशबोर्ड UUID।
• dashboard (object, आवश्यक): पूरा प्रतिस्थापन डैशबोर्ड body (create जैसी ही संरचना)।
• metadata (object, वैकल्पिक): प्रतिस्थापन metadata। केवल-पढ़ने वाले system dashboards एक recoverable tool error लौटाते हैं।

patch_dashboard

छोटे सुधारों के लिए update_dashboard के बजाय इसे प्राथमिकता दें: अपरिवर्तित पैनल दोबारा नहीं भेजे जाते। यह डैशबोर्ड पढ़ता है, ops को क्रम से लागू करता है और उसे वापस लिखता है; इसलिए पढ़ने और लिखने के बीच कहीं और किया गया edit अधिलेखित हो जाता है। {dashboard_id, changes[]} लौटाता है; जिन ops की शर्तें डैशबोर्ड पहले से पूरी करता है, उन्हें छोड़ दिया जाता है, और यदि कोई बदलाव न हो तो कुछ भी नहीं लिखा जाता। Write के बाद दोबारा पढ़े गए डैशबोर्ड से diff की जाँच होती है: पैनल fields संग्रहीत मान दिखाते हैं, not_stored API द्वारा हटाई गई keys सूचीबद्ध करता है और not_removed उन keys को सूचीबद्ध करता है जिन्हें API ने null के बावजूद बनाए रखा। 200 characters से बड़े diff मानों को उनकी जगह पर छोटा किया जाता है और उनका JSON type बरकरार रहता है।

• id (string, आवश्यक): patch करने के लिए डैशबोर्ड UUID।
• ops (array, आवश्यक): क्रम से लागू किए जाने वाले ops; यदि कोई भी अमान्य हो, तो कुछ नहीं लिखा जाता और त्रुटि उसे ops[i] के रूप में नामित करती है।
  • add_panel: panel (पूरा panel object; version का डिफ़ॉल्ट 1 है), वैकल्पिक index (0-आधारित insert position, डिफ़ॉल्ट append)।
  • update_panel: panel_id, fields (बदलने के लिए शीर्ष-स्तरीय panel keys; null किसी key को हटाता है; id बदला नहीं जा सकता)।
  • remove_panel: panel_id।
  • move_panel: panel_id, index (स्थानांतरण के बाद की 0-आधारित position)।
  • set_title: title (डैशबोर्ड का नाम)।
  • set_variable: variable; समान target वाले variable को बदलता है, अन्यथा उसे जोड़ता है।

delete_dashboard

• id (string, आवश्यक): हटाने के लिए डैशबोर्ड UUID। केवल-पढ़ने वाले system dashboards हटाए नहीं जा सकते।

set_dashboard_lock

• id (string, आवश्यक): डैशबोर्ड UUID।
• locked (boolean, आवश्यक): true डैशबोर्ड को लॉक करता है, false उसे अनलॉक करता है।

Write tool; इसे केवल तभी कॉल करें जब उपयोगकर्ता स्पष्ट रूप से अनुरोध करे। केवल डैशबोर्ड का लेखक या org admin ही उसे लॉक या अनलॉक कर सकता है, और अंतर्निहित dashboards हमेशा केवल-पढ़ने योग्य होते हैं। परिणामी स्थिति के साथ {"id", "locked"} लौटाता है। लॉक होने पर update_dashboard, patch_dashboard और delete_dashboard कोई write नहीं भेजते और एक recoverable tool error लौटाते हैं, जो dashboard is locked से शुरू होता है, लेखक का नाम बताता है और create_dashboard से डैशबोर्ड अनलॉक करने या उसकी कॉपी बनाने का सुझाव देता है।

list_dashboard_snapshots

• dashboard_id (string, आवश्यक): उस डैशबोर्ड UUID के snapshots की सूची बनाएँ।

केवल metadata लौटाता है (id, name, expires_at, आदि)। स्थिर panel data के लिए get_dashboard_snapshot का उपयोग करें।

get_dashboard_snapshot

• id (string, आवश्यक): Snapshot UUID।

पूरा स्थिर snapshot लौटाता है, जिसमें dashboard_definition, panel_data, time_range, और variables शामिल हैं।

delete_dashboard_snapshot

• id (string, आवश्यक): हटाने के लिए Snapshot UUID।

get_profile_services

• lookback_minutes / start_time_iso / end_time_iso (वैकल्पिक): समयावधि; lookback या स्पष्ट ISO bounds को प्राथमिकता दें (डिफ़ॉल्ट 60m)।
• region (string, वैकल्पिक): Region override।

समयावधि में profiling data वाली सेवाएँ लौटाता है। get_flamegraph / get_top_functions / get_profile_summary से पहले इसे कॉल करें।

get_flamegraph

• service (string, आवश्यक): get_profile_services से सेवा का नाम।
• profile_type (string, वैकल्पिक): cpu (डिफ़ॉल्ट), alloc, या wall। समयावधियों की तुलना करते समय कोई प्रकार तय करें।
• env / cluster / namespace / runtime (string, वैकल्पिक): Scope filters।
• limit (number, वैकल्पिक): अधिकतम aggregated stack rows (डिफ़ॉल्ट 1000, अधिकतम 10000)।
• lookback_minutes / start_time_iso / end_time_iso / region (वैकल्पिक)।

नेस्टेड flamegraph tree (name / value / self / children) लौटाता है। truncated: true का अर्थ है कि API row limit तक पहुँच गई।

get_top_functions

get_flamegraph जैसे ही filters। सबसे अधिक सक्रिय functions की self-sample ranking लौटाता है। परिणाम छोटा किया जा सकता है; truncated देखें।

get_profile_summary

get_flamegraph जैसे ही filters। सेवा के प्रोफ़ाइल का संक्षिप्त, प्राकृतिक-भाषा triage लौटाता है।

grafana_search_dashboards

• query (string, वैकल्पिक): शीर्षक का सबस्ट्रिंग। खाली होने पर व्यापक सूची मिलती है (5,000 rows की सीमा के अधीन)।

{"dashboards":[…], "truncated":bool} लौटाता है, जिसमें uid, title, uri, url, type, tags होते हैं। grafana_get_dashboard के साथ uid का उपयोग करें।

grafana_get_dashboard

• uid (string, आवश्यक): Grafana dashboard uid।
• full_json (boolean, वैकल्पिक): true होने पर, फ़िल्टर किए गए सारांश के बजाय कच्चा Grafana JSON लौटाएँ।

डिफ़ॉल्ट सारांश: version, tags, templating variables, और हर पैनल के type/datasource/gridPos/promQL targets। अज्ञात plugin panel types unsupportedPanelTypes में दिखाई देते हैं।

grafana_list_folders

कोई पैरामीटर नहीं। Folder tree लौटाता है।

grafana_list_folder_dashboards

• folder_uid (string, required): Grafana फ़ोल्डर uid.

उस फ़ोल्डर के डैशबोर्ड के लिए {"dashboards":[…], "truncated":bool} लौटाता है (पृष्ठांकित, अधिकतम 5,000 तक)।

grafana_list_datasources

कोई पैरामीटर नहीं। डेटा स्रोतों का सुरक्षित प्रक्षेप लौटाता है (क्रेडेंशियल फ़ील्ड नहीं)।