Skip to main content
Glama
Tealfabric MCP Server for Cursor

Tealfabric MCP Server for Cursor

Official
by tealfabric

tealfabric_list_integrations

List integrations or query integration details, status, statistics, and execution history with action and filter parameters.

Instructions

List integrations or query integration details/status/statistics/execution history via action filters.

Input Schema

NameRequiredDescriptionDefault
pageNo
typeNo
limitNoLimit for execution-history action
actionNoOptional action; omit to list all integrations
searchNo
statusNo
sort_byNo
is_activeNo1=enabled, 0=disabled
execution_idNoExecution ID (for status action)
integration_idNoIntegration ID (for get/test/execution-history)
items_per_pageNo
sort_directionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changedv0.2.0
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / is_active / anyOf
      Added value: +[
      +  {
      +    "const": 0,
      +    "type": "number"
      +  },
      +  {
      +    "const": 1,
      +    "type": "number"
      +  }
      +]
    • removedInput schema / properties / is_active / enum
      Removed value: -[
      -  0,
      -  1
      -]
    • removedInput schema / properties / is_active / type
      Removed value: -"number"
    • addedInput schema / properties / items_per_page / anyOf
      Added value: +[
      +  {
      +    "const": 10,
      +    "type": "number"
      +  },
      +  {
      +    "const": 25,
      +    "type": "number"
      +  },
      +  {
      +    "const": 50,
      +    "type": "number"
      +  },
      +  {
      +    "const": 100,
      +    "type": "number"
      +  }
      +]
    • removedInput schema / properties / items_per_page / enum
      Removed value: -[
      -  10,
      -  25,
      -  50,
      -  100
      -]
    • removedInput schema / properties / items_per_page / type
      Removed value: -"number"
    • addedInput schema / properties / limit / maximum
      Added value: +9007199254740991
    • addedInput schema / properties / limit / minimum
      Added value: +-9007199254740991
    • addedInput schema / properties / page / maximum
      Added value: +9007199254740991
  2. First observedv0.1.3

TDQS

C2.4/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden and does not meet it. It does not state that the surface is read-only, that 'test' performs a live connection check with side effects, that execution-history is paginated by limit, or what permissions are required. 'test' in particular is a non-obvious action an agent could invoke unsafely without a disclosure.

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

Conciseness3/5

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

It is a single compact sentence with no padding, which is good, but the slash-delimited list of modes is compressed to the point of ambiguity and nothing is front-loaded about the action-driven design. Efficient but under-informative.

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

Completeness2/5

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

For a 12-parameter, five-mode tool with no annotations and no output schema, the description should explain mode selection, parameter requirements per mode, and return shape. It supplies none of these, leaving the agent to reverse-engineer behavior from a partially described schema.

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

Parameters2/5

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

Schema coverage is only 42% with 12 parameters, so the description must compensate and does not. It never explains the action-to-parameter pairing (integration_id for get/test/execution-history, execution_id for status), nor the seven undocumented params (page, type, search, status, sort_by, sort_direction, items_per_page). Only the schema's own 'action' and 'limit' descriptions carry any semantics.

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

Purpose3/5

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

The description names the primary resource (integrations) and lists the supported query modes (details/status/statistics/execution history), but 'via action filters' is vague and it never says this is a single multi-mode dispatch tool driven by the action enum. An agent can guess it is a read/list surface, but the boundaries between modes are fuzzy.

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?

No guidance on when to pick this tool over siblings such as tealfabric_execute_integration or tealfabric_update_integration, and no indication of which mode substitutes for a missing get_integration. The only usage hint ('via action filters') is a restatement of the enum in the schema rather than actionable routing advice.

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