Skip to main content
Glama

elaichi__connector__list

Read-onlyIdempotent

Browse the catalog of third-party providers this organization can connect to (Slack, HubSpot, Google Calendar, …). A connector is a provider DEFINITION, not an account: nothing here is authenticated and nothing here is usable until someone creates a connection from it, so this cannot answer "what is our org connected to" — that is connection.list. Each row carries slug (the connector’s key everywhere else in this catalog — connectors have no id), label, category, description and byoa (true when the org must supply its own OAuth app first). No row carries a tool count: that lives on connector.get, one connector at a time, so "which connector has the most tools" cannot be answered from this list and must not be guessed from it. Every row carries restricted and, when it is true, restricted_by ("role" or "user") — governance has blocked that connector FOR YOU. A blocked connector is still listed, deliberately: presence here is not permission to use it, and absence means the provider genuinely is not in this catalog. Say the true one. When restricted is true, tell the person the connector exists and that they are blocked, and offer access_request.create with resource_type "connector" and the slug as tool — never claim no such connector exists, and never attempt connection.create or connector.list_tools on it, both of which refuse. restricted_by says only WHOSE rule layer blocked it, their role or their account; it never names the rule, who wrote it, or what else it covers, and neither may you. search and category are applied by the catalog before paging, so "is there a Slack connector" is one call rather than a walk through every page; category matches exactly, so take its value from the category of a row you have already seen rather than inventing one. Returns { result: [...], nextCursor } — no prevCursor on this one, so you can page forward but never back. limit defaults to 50 here, NOT to the whole catalog, and the catalog is far larger than one page: send nextCursor back as cursor until it comes back null, and never answer "which connectors are there" from the first page alone.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoRows per page, 1–200 (default 50). Larger values are clamped, not rejected.
cursorNoOpaque cursor taken verbatim from a previous call’s `nextCursor`. Omit for the first page.
searchNoCase-insensitive substring of the connector’s slug or label (e.g. "slack"), applied across the whole catalog before paging.
categoryNoExact category string as it appears in these rows (e.g. "crm"). Not a substring and not a guess — an unknown category matches nothing rather than erroring.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds substantial behavior beyond that: blocked connectors are deliberately still listed, `restricted_by` names only the rule layer and must never be elaborated, and the absence of a provider means it is genuinely missing from the catalog. It also discloses the pagination asymmetry ("no prevCursor on this one") and the trap that `limit` defaults to 50 rather than the whole catalog. No statement contradicts the annotations.

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?

The description is strongly front-loaded and nearly every sentence carries a distinct constraint, but it is unusually long — over a thousand words for a 4-parameter list endpoint. Some admonitions repeat the same idea ("Say the true one" / "never claim no such connector exists", and the "neither may you" restatement in the restricted_by paragraph) and could be tightened without losing information. It is dense with value, yet overweight.

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

Completeness5/5

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

There is no output schema, so the description correctly supplies the return shape ({ result: [...], nextCursor }), the row's field set (slug, label, category, description, byoa, restricted, restricted_by), and complete paging rules. Combined with 100% schema coverage on inputs, an agent has everything required to invoke the tool correctly and to consume its results accurately — including the traps around blocked rows and first-page-only answers.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3 — every parameter already has schema-level documentation. The description adds operational value beyond that: search and category are applied before paging (making a one-call existence check possible), category values "must" come from an observed row rather than invention, and cursor paging must be followed "until it comes back null." This is more than the baseline but not exhaustive per-parameter enrichment.

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 first sentence names a specific verb and resource — "Browse the catalog of third-party providers this organization can connect to" — and immediately disambiguates the core concept: "A connector is a provider DEFINITION, not an account." It explicitly differentiates from siblings by naming what this tool cannot answer (org connectivity belongs to connection.list, tool counts belong to connector.get), so an agent can distinguish it without opening any schema.

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

Usage Guidelines5/5

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

The description gives explicit when-to-use and when-not-to-use guidance: "this cannot answer 'what is our org connected to' — that is connection.list" and "'which connector has the most tools' cannot be answered from this list." It also prescribes the exact fallback for blocked connectors — access_request.create with resource_type "connector" and the slug as `tool` — and explicitly forbids connection.create or connector.list_tools on those rows. This is textbook alternative-routing.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources