Skip to main content
Glama
sciple-idp

Sciple Platform MCP Server

Official
by sciple-idp

add_panel

Add a panel to a Sciple dashboard for visualizing metrics or logs from PromQL, CloudWatch, Elasticsearch, or plain text.

Instructions

Add a panel to a dashboard.

A panel belongs to ONE of five shapes — pick one based on what the user wants and supply only that shape's parameters:

  1. PromQL metric promql=

  2. CloudWatch metric cw_namespace + cw_metric_name + cw_stat (optional cw_dimensions JSON, cw_period)

  3. ElasticSearch/OpenSearch logs panel_type='logs' (or 'log_table') + es_index + optional kql_filter + optional log_* display options

  4. CloudWatch Logs panel_type='logs' (or 'log_table') + cw_log_group + optional cw_filter_pattern + optional log_* display options

  5. Text panel_type='text' + text_content (optional text_background hex color)

ALWAYS pass datasource_id (the observability data source id from the Sciple UI → Data sources) for metric + log panels — without it the panel binds to the dashboard's default and may render empty. Text panels never need a data source.

Recommended panel_type per shape: line / bar / stat / gauge → metric panels logs / log_table → log panels text → text panels

Args: dashboard_id: The dashboard id to add the panel to. title: Panel title (1-200 characters). panel_type: One of: line, bar, stat, gauge, logs, log_table, text. Defaults to "line". unit: Display unit string (e.g. "none", "bytes", "percent", "bits/s"). Defaults to "none". legend_label: Legend label for metric queries. Ignored for log panels (use log_columns instead) and text panels. datasource_id: Id of the observability data source. Required for metric + log panels. promql: PromQL expression. Use for shape #1. cw_namespace, cw_metric_name, cw_stat: CloudWatch metric triple (e.g. "AWS/EC2", "CPUUtilization", "Average"). Use for shape #2. cw_dimensions: JSON string of CloudWatch dimensions, e.g. '[{"Name": "InstanceId", "Value": "i-0abc..."}]'. cw_period: CloudWatch period in seconds (e.g. 60). es_index: ElasticSearch / OpenSearch index pattern, e.g. "production-eks-pods-logs" or "logs-". Use for shape #3. kql_filter: Optional KQL filter for ES, e.g. 'level:error AND service:"api"'. Use for shape #3 (paired with es_index). cw_log_group: CloudWatch Logs log group, e.g. "/aws/lambda/my-fn". Use for shape #4. cw_filter_pattern: Optional CloudWatch Logs filter pattern, e.g. "?ERROR ?WARN" or "[..., status_code=5, ...]". Use for shape #4 (paired with cw_log_group). log_columns: Ordered list of column names to display in the log table, e.g. ["timestamp", "level", "message"]. Defaults to the editor's default if omitted. log_limit: Max rows to fetch (defaults match the UI; typical 200). log_wrap_message: Wrap long log messages (default false). log_expandable_rows: Allow row expansion (default true). log_highlight_by_severity: Color rows by severity (default true). log_live_tail: Enable live-tail mode (default false). text_content: Markdown body for a text panel. Required when panel_type='text'. text_background: Optional CSS color string for the text panel background, e.g. "#dcfce7", "rgb(220, 252, 231)".

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
unitNonone
titleYes
promqlNo
cw_statNo
es_indexNo
cw_periodNo
log_limitNo
kql_filterNo
panel_typeNoline
log_columnsNo
cw_log_groupNo
cw_namespaceNo
dashboard_idYes
legend_labelNo
text_contentNo
cw_dimensionsNo
datasource_idNo
log_live_tailNo
cw_metric_nameNo
text_backgroundNo
log_wrap_messageNo
cw_filter_patternNo
log_expandable_rowsNo
log_highlight_by_severityNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Install Server

TDQS

A5/5.0
Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden. It discloses important behaviors such as the panel binding to the dashboard's default data source and possibly rendering empty without datasource_id, which log options are ignored for certain panel types, and default behavior for log_limit and log_wrap_message. This is substantive transparency.

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

Conciseness5/5

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

The description is long but well-structured: a nested shape list front-loads the decision logic, followed by a compact args reference. The overlap between shapes and args is justified given 24 parameters, and every section carries real decision-making value.

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

Completeness5/5

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

For a 24-parameter tool with no annotations and no schema-level descriptions, this description covers the essential context: required parameters, mutually exclusive shapes, defaults, ignored parameters, and the datasource_id requirement. The presence of an output schema means return-value details are already structured, so no additional description is needed there.

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

Parameters5/5

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

The input schema has 0% description coverage, so the description must compensate — and it does comprehensively. Each parameter is explained with usage context, examples, and shape associations, such as cw_namespace + cw_metric_name + cw_stat for CloudWatch metrics and es_index paired with kql_filter for ElasticSearch. This goes far beyond the bare schema field names.

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

Purpose5/5

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

The description states a specific verb and resource: 'Add a panel to a dashboard.' It then enumerates five concrete panel shapes, making the tool's purpose unmistakable and distinct from siblings like delete_panel or add_cell. This is far beyond a vague or tautological definition.

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

Usage Guidelines5/5

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

The description gives explicit guidance on when to use each parameter set via the five shapes, recommends panel_type values per shape, and warns that datasource_id is required for metric/log panels but never for text panels. This is actionable and leaves little to inference.

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

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sciple-idp/sciple-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server