twelvebit Analytics

Integration status

get_integrations

Read-onlyIdempotent

Status of each integration (stripe, polar, lemonsqueezy, paddle, dodo, shopify, woocommerce, gsc, meta_ads, google_ads, github): connected, last sync, last event, last error and non-secret details. Never returns secrets or tokens. To connect one, give the person connect_url: secrets and sign-ins are entered only in the dashboard, never in chat.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_integrations"
  }
}

Input Schema

Name	Required	Description	Default
`site`	No	Site domain (example.com), id or public id (tb_…). Optional with a site key, or when the account has one site.
`provider`	No	Only this integration.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered structurally. The description adds genuine value with 'Never returns secrets or tokens' and the rule that secrets/sign-ins happen only in the dashboard, but it doesn't discuss rate limits, error states, or partial-failure behavior of the sync data.

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?

Front-loaded with the returned-fields list and the security constraint in the second sentence; every sentence carries weight. The long parenthetical provider list is somewhat redundant with the enum but is compact enough not to hurt readability.

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?

With no output schema, the description compensates by naming the returned fields and explicitly excluding secrets. Annotations cover safety, the schema covers both parameters fully, and the connect-via-dashboard rule closes the remaining security gap, so 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.

Parameters3/5

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

Schema description coverage is 100% and both parameters (site, provider) are documented in the schema, including the optional-site-with-key nuance and the provider enum. The description merely echoes the provider list already present in the enum, adding no syntax or format detail beyond the schema.

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-and-resource ('Status of each integration') and enumerates all eleven providers plus the exact fields returned (connected, last sync, last event, last error). This clearly separates it from mutating siblings like disconnect_integration.

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

Usage Guidelines4/5

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

Gives explicit positive guidance on connecting integrations ('give the person connect_url', entered only in the dashboard, never in chat), which is a real when-to-use/when-not rule. It stops short of naming disconnect_integration or other siblings as alternatives for changing integration state.

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

All twelvebit Analytics tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?