Skip to main content
Glama
Sign In
Tealfabric MCP Server for Cursor

Tealfabric MCP Server for Cursor

Official
by tealfabric
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

tealfabric_test_connector

Tests a connector configuration against the Tealfabric test endpoint to verify that the connector is set up correctly before use.

Instructions

Test a connector configuration against the Tealfabric connectors test endpoint.

Input Schema

NameRequiredDescriptionDefault
connector_idYesConnector ID
configurationNoConnector configuration object expected by the selected connector

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.2.0
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / configuration
      Added value: +{
+  "additionalProperties": {},
+  "description": "Connector configuration object expected by the selected connector",
+  "propertyNames": {
+    "type": "string"
+  },
+  "type": "object"
+}
    • addedInput schema / properties / connector_id
      Added value: +{
+  "description": "Connector ID",
+  "type": "string"
+}
    • removedInput schema / properties / payload
      Removed value: -{
-  "additionalProperties": {},
-  "description": "Connector configuration payload expected by the selected connector",
-  "type": "object"
-}
    • changedInput schema / required
      Previous value: -[
-  "payload"
-]New value: +[
+  "connector_id"
+]
  2. First observedv0.1.3

TDQS

C2.9/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 disclosure burden and says almost nothing. It does not state whether the test is a dry-run validation or actually exercises an external connection, whether it is idempotent, what could fail, or what a result looks like — all of which matter for a tool that likely performs outbound network calls.

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?

A single front-loaded sentence with no filler. It is efficient, though some of the brevity reflects missing content rather than disciplined editing.

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 tool with a nested configuration object, no output schema, and zero annotations, the description should explain what a successful vs. failed test returns and any prerequisites. It says none of this, leaving the agent unable to predict the result or the side effects.

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 both connector_id and the nested configuration object are documented in the schema itself. The description adds no meaning beyond that — it does not say which fields the configuration needs or how errors from a malformed configuration are surfaced. Baseline 3 applies.

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?

States a specific verb ('Test') and resource ('a connector configuration') with the target endpoint named. However, 'test' is ambiguous — it could mean static schema validation or a live connectivity/auth probe — and the description does nothing to distinguish which.

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 when-to-use guidance at all: nothing about whether the connector must already exist, whether it must come before create_integration/update_integration, or when to consult the sibling get_connector_oauth2_required first. The agent has to infer the workflow placement entirely.

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