Skip to main content
Glama
Sign In
AI-ML-Lab-MCP

AI-ML-Lab-MCP

by SyedHassan904
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Column Types

column_types

Retrieve Pandas data types for every column using a dataset ID to inspect schema and guide cleaning or feature engineering.

Instructions

Return Pandas data types for each column. Args: dataset_id (str): ID of the dataset. Returns: dict: column_types (column name -> dtype).

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": {
      "dataset_id": "<dataset_id>"
    },
    "name": "column_types"
  }
}

Input Schema

NameRequiredDescriptionDefault
dataset_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.2/5.0
Behavior3/5

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

No annotations are supplied, so the description carries the full disclosure burden. It does state the return shape (column name to dtype), which signals a read-only inspection, but it says nothing about behavior on an invalid dataset_id, permissions, or whether results are cached or scoped.

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 definition is short and front-loaded, leading with the action before the Args/Returns blocks. The docstring-style labels are slightly boilerplate but not wasteful for a one-parameter tool.

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 trivial one-parameter inspection tool with no output schema, the description covers purpose, input meaning, and return shape. Little more is needed, though a note on error behavior or a pointer to related tools would close the remaining gap.

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 0% for the single dataset_id parameter, but the description supplies a one-line gloss ('ID of the dataset'), which is enough to use the parameter correctly. It adds little beyond the schema's type declaration and gives no format or example.

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?

The description states a specific verb and resource: it returns Pandas dtypes for each column of a dataset. That is unambiguous on its own, but it never distinguishes the tool from siblings such as dataset_info or convert_data_types, which likely expose overlapping column metadata.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no stated prerequisite, and no mention of alternatives. An agent has to infer that this is a read-only inspection step that might precede convert_data_types; the description does not say so.

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