Skip to main content
Glama

elaichi__connection__list_tools

Read-onlyIdempotent

List the tools one authenticated account is ALLOWED to run: the connector’s catalog filtered by the restrictions in force for this caller. It does not look at the connection’s status — a "pending", "needs_reauth" or "disconnected" connection returns exactly the same list as a working one while actually running none of them — so this can never confirm that a connection authenticated, and a non-empty list here is not evidence that it did. Use connection.get and read status for that. Use this whenever you hold a conn_… id, and always when assembling toolbox entries, because an entry naming a restricted tool is rejected. It is no longer the only restriction-filtered view: connector.list_tools applies the same per-caller clamp, so for the same connector the two return the same set — what this one adds is that you name the ACCOUNT rather than the slug. If governance has blocked the whole connector for you, this REFUSES with a permission error rather than answering an empty list — the same as connector.list_tools, and the same as the REST route behind it. So an empty tools here means the provider genuinely has nothing to list, never "blocked for you"; read connector.get’s restricted to state the block without provoking the refusal. The connection itself stays describable either way — connection.get is not gated — so you can always explain WHY the listing refused. Returns { connection_id, connector_slug, tools: [...], nextCursor, prevCursor } — the rows are under tools, NOT under result, so this is not the standard list envelope. The restriction filter is applied BEFORE paging, so every row on every page is one this caller may actually run and the cursor never counts rows it would have hidden. limit defaults to 200, which is the whole allowed set for almost every provider; a non-null nextCursor means there are more, and you page by sending it back as cursor until it is null.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesConnection id (`conn_…`) from connection.list — not a connector slug.
limitNoRows per page, 1–200. Defaults to 200 — the whole set in one call for almost every organization — rather than the 50 the other lists here default to. Larger values are clamped, not rejected.
cursorNoOpaque cursor taken verbatim from a previous call’s `nextCursor`. Omit for the first page.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Adds substantial behavioral context beyond the readOnly/idempotent annotations: connection status is irrelevant, a blocked connector causes a refusal rather than an empty list, the response uses a non-standard envelope, and paging filters before pagination. No contradiction with annotations.

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 description is long but front-loaded with purpose and usage, followed by edge-case and paging details. Every major claim earns its place for a tool with subtle failure modes, though there is minor redundancy around connector.list_tools equivalence and authentication caveats.

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?

Despite having no output schema, the description fully documents the return envelope, the location of rows under `tools`, paging behavior, default limit, refusal semantics, and how to disambiguate an empty list from a blocked connector. An agent has everything needed to call it correctly.

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?

The schema already covers 100% of parameters, so the baseline is 3. The description adds meaningful semantics: limit defaults to 200 rather than 50, larger values are clamped, cursor is opaque and sent back verbatim, and id must come from connection.list. This exceeds the baseline.

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?

States a specific verb ('List'), resource (tools an authenticated account is ALLOWED to run), and the key filtering behavior (catalog filtered by per-caller restrictions). It explicitly distinguishes itself from the sibling connector.list_tools by noting the difference is naming the ACCOUNT rather than the slug.

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?

Provides explicit when-to-use guidance: 'Use this whenever you hold a conn_… id, and always when assembling toolbox entries.' It also names alternative tools for related needs, such as connection.get for checking authentication status, and explains when connector.list_tools is equivalent.

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