Skip to main content
Glama
hnegi01

fes-mcp

by hnegi01
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

datamodel.generate_connections_payload

datamodel_generate_connections_payload
Read-only

Generate provider-specific connection payloads for Athena, RedShift, BigQuery, and DataBricks to automate data source setup.

Instructions

Generate a connection payload for a given data source type. Builds the provider-specific request body consumed by create_connections. The datasource_type is matched case-insensitively. Supported types are "Athena", "RedShift", "BigQuery", and "DataBricks". Returns: dict[str, Any] The provider-specific connection payload.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
datasource_typeYesType of data source (matched case-insensitively).
connection_paramsYesConnection details. Supported keys depend on ``datasource_type``: - Athena: ``name`` (required), ``region`` (required), ``s3_output_location`` (required), ``aws_access_key`` (required), ``aws_secret_key`` (required), ``description``, ``schema``, ``additional_parameters``. - DataBricks: ``name`` (required), ``connection_string`` (required), ``token`` (required), ``description``, ``use_dynamic_schema``, ``schema``. - BigQuery: ``name`` (required), ``service_account_key_path`` (required), ``description``, ``use_service_account``, ``use_proxy_server``, ``use_dynamic_schema``, ``record_field_flattening_level``, ``unnest_arrays``, ``allow_large_results``, ``use_storage_api``, ``additional_parameters``, ``database``. - RedShift: ``server`` (required), ``username`` (required), ``password`` (required), ``name``, ``description``, ``default_database``, ``additional_parameters``.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.1.2
    • addedInput schema / properties / connection_params / additionalProperties
      Added value: +true
    • addedInput schema / properties / connection_params / properties
      Added value: +{
+  "additional_parameters": {
+    "type": "string"
+  },
+  "allow_large_results": {
+    "type": "boolean"
+  },
+  "aws_access_key": {
+    "type": "string"
+  },
+  "aws_secret_key": {
+    "type": "string"
+  },
+  "connection_string": {
+    "type": "string"
+  },
+  "database": {
+    "type": "string"
+  },
+  "default_database": {
+    "type": "string"
+  },
+  "description": {
+    "type": "string"
+  },
+  "name": {
+    "type": "string"
+  },
+  "password": {
+    "type": "string"
+  },
+  "record_field_flattening_level": {
+    "type": "string"
+  },
+  "region": {
+    "type": "string"
+  },
+  "s3_output_location": {
+    "type": "string"
+  },
+  "schema": {
+    "type": "string"
+  },
+  "server": {
+    "type": "string"
+  },
+  "service_account_key_path": {
+    "type": "string"
+  },
+  "token": {
+    "type": "string"
+  },
+  "unnest_arrays": {
+    "type": "boolean"
+  },
+  "use_dynamic_schema": {
+    "type": "boolean"
+  },
+  "use_proxy_server": {
+    "type": "boolean"
+  },
+  "use_service_account": {
+    "type": "boolean"
+  },
+  "use_storage_api": {
+    "type": "boolean"
+  },
+  "username": {
+    "type": "string"
+  }
+}
    • addedInput schema / properties / connection_params / required
      Added value: +[]
    • changedInput schema / properties / datasource_type / description
      Previous value: -"Type of data source. One of ``\"Athena\"``, ``\"RedShift\"``, ``\"BigQuery\"``, ``\"DataBricks\"`` (case-insensitive)."New value: +"Type of data source (matched case-insensitively)."
    • addedInput schema / properties / datasource_type / enum
      Added value: +[
+  "Athena",
+  "RedShift",
+  "BigQuery",
+  "DataBricks"
+]
  2. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral detail: datasource_type matching is case-insensitive, the output is a dict payload, and the tool is a payload builder rather than a connector. This goes beyond what annotations alone provide.

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 compact, front-loaded with the core purpose, and every sentence contributes either to scope, supported types, or return type. There is no redundant or filler content.

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?

Given the rich input schema and annotations, the description is nearly complete. It explains the output type and how the payload is intended to be used. A more explicit note about what happens with unsupported datasource types would improve it, but the supported list and schema enum already cover the main decision.

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 schema fully documents datasource_type and connection_params, including per-type required and optional keys. The description adds little beyond what the schema already provides, so the baseline score of 3 is appropriate.

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 ('Generate a connection payload') and a clear resource ('for a given data source type'). It distinguishes itself from sibling datamodel tools by explicitly noting it builds the provider-specific request body for create_connections, not performing connection operations.

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

Usage Guidelines4/5

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

The description gives clear context: use this to produce a payload consumed by create_connections, with supported datasource types enumerated. It does not explicitly name alternatives or say when not to use it, but the intended use case is strongly implied by the 'consumed by create_connections' phrasing.

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