Skip to main content
Glama
Sign In
fes-mcp

fes-mcp

by hnegi01
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

dashboard.get_dashboard_script

dashboard_get_dashboard_script
Read-only

Retrieves a dashboard export and wraps its script in a SisenseScript helper for rendering as plain text, markdown, or file output.

Instructions

Build a formatted dashboard script helper object. Retrieves a dashboard export payload and wraps its script content in a :class:SisenseScript helper that can render plain text, markdown, or file output. Returns: SisenseScript | dict[str, str] A :class:SisenseScript instance when the dashboard is retrieved and has a script. {"error": "..."} when the export fails (including status_code for HTTP failures such as missing …

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": {
      "dashboard_id": "<dashboard_id>"
    },
    "name": "dashboard_get_dashboard_script"
  }
}

Input Schema

NameRequiredDescriptionDefault
dashboard_idYesThe dashboard identifier to export.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral detail beyond annotations: it specifies the return type (SisenseScript or error dict), the condition for success (dashboard retrieved and has a script), and error behavior (includes status_code for HTTP failures). This gives an agent a good sense of outcomes without making the description the sole source of safety information.

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 description is concise and mostly front-loaded: the first sentence states the primary purpose, and the second covers the return contract. The phrasing 'Build a formatted dashboard script helper object' is slightly abstract but immediately clarified. No redundant filler appears, though the return type sentence could be tightened.

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?

For a single-parameter, read-only tool with annotations and no output schema, the description covers the essential behavioral contract: what it returns on success, what it returns on failure, and how errors are shaped. Minor gaps exist, such as not explicitly describing what happens when a dashboard exists but has no script, but overall it is sufficiently complete for an agent to invoke the tool correctly.

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?

The input schema provides 100% coverage of the single parameter, dashboard_id, with a clear description. The tool description does not add additional meaning about the parameter beyond what is already in the schema. According to the rubric, baseline 3 is appropriate since schema_description_coverage is high and the parameter is simple.

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 action: building a formatted dashboard script helper object by retrieving a dashboard export and wrapping its script in a SisenseScript helper. This clearly distinguishes it from sibling tools like dashboard_get_dashboard_by_id (which retrieves the dashboard itself) and dashboard_get_widget_script (which targets widget scripts). The verb 'build' plus the resource 'dashboard script helper' makes the purpose unambiguous.

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 description implies this tool is used when a formatted dashboard script helper is needed, but it does not explicitly state when to use it over alternatives or when not to use it. No sibling comparisons or exclusions are provided. The usage context is inferable from the clear resource focus, but explicit guidance is absent.

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

Deploy Server

Other Tools