clariBI.com
Server Details
clariBI is an AI-powered business intelligence platform built for small and mid-sized SaaS, ecommerce, and operations teams. Instead of writing SQL or building dashboards manually, users ask questions in plain English ("what's our CAC by channel last quarter?") and the AI engine pulls the data from Stripe, HubSpot, Google Analytics, ad platforms, Jira, and 30+ other sources via the open Model Context Protocol. Dashboards generate themselves on source connect.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.4/5 across 3 of 3 tools scored.
Each tool has a distinct, non-overlapping purpose: check_pricing for viewing tiers, register_account for starting signup, and verify_email for completing it. An agent can easily differentiate them.
All tools follow a consistent verb_noun pattern (check_pricing, register_account, verify_email), making the tool set predictable and easy to navigate.
With 3 tools covering the essential signup flow (pricing inquiry, registration initiation, completion), the number is well-scoped for the server's purpose.
The tools form a complete signup cycle (check pricing → register → verify email), but lack a resend verification code tool or a login tool for returning users, which are minor gaps.
Available Tools
3 toolscheck_pricingARead-onlyIdempotentInspect
List clariBI subscription tiers with prices, AI credits, data source limits, user limits, and headline features. No authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
| tier | No | Optional. Return only this tier (free, trial, lite, starter, professional, enterprise). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds 'No authentication required' beyond what the annotations (readOnlyHint, idempotentHint, destructiveHint) provide. It explicitly confirms the tool is safe to call without credentials, which is valuable behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's purpose and content. It is front-loaded and avoids unnecessary words, though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one optional parameter, no output schema, and explicit annotations), the description fully covers what the tool returns and how it behaves, making it complete for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers 100% of the single parameter (tier) with a clear explanation. The description does not add any extra meaning beyond that, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and clearly identifies the resource 'clariBI subscription tiers' along with the included details: prices, credits, limits, and features. It effectively distinguishes from sibling tools like register_account and verify_email, which focus on account actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states 'No authentication required,' giving clear context on when to use the tool. While it does not explicitly mention when not to use it or alternatives, the sibling tools provide implicit differentiation, and the statement is direct and useful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
register_accountAInspect
Begin clariBI account signup. Validates the email + organization name, emails a 6-digit verification code, and returns a pending_id. Call verify_email(pending_id, code) within 10 minutes to finish signup and receive an API key.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Work email for the new account. | ||
| last_name | No | User's last name (optional). | |
| first_name | No | User's first name (optional). | |
| accept_terms | Yes | Must be true. By passing true the user agrees to https://claribi.com/terms and https://claribi.com/privacy. | |
| organization_name | Yes | Display name for the organization workspace. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes validation, email sending, pending_id return, and timeout. Adds context beyond annotations (e.g., timeout, next step). 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences. Every sentence provides essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers input validation, output (pending_id), next step (verify_email), and time limit. No output schema, but the description sufficiently explains the return value and lifecycle.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with individual parameter descriptions. The tool description ties parameters to the flow (e.g., accept_terms must be true, email and org_name are validated). Slightly more than baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Begin clariBI account signup' with specific actions: validates email+org, sends verification code, returns pending_id. It distinguishes from sibling tools like verify_email and check_pricing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to follow with verify_email(pending_id, code) within 10 minutes. Provides sequential usage context and time constraint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_emailAInspect
Complete clariBI signup by submitting the verification code plus a password. Returns an OAuth access_token for immediate use AND a long-lived MCP API key for persistent configuration. The new organization lands on the Trial tier (50 AI credits, 14 days).
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | 6-digit verification code from the email. | |
| password | Yes | A password for the new account. Must be at least 8 characters and pass Django's standard validators. | |
| pending_id | Yes | The pending_id returned by register_account. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations by specifying the outputs (access_token, API key) and the resulting subscription tier. It does not contradict the annotations (readOnlyHint=false etc.) and is accurate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with no wasted words. It front-loads the main action and efficiently covers inputs, outputs, and implications.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description appropriately explains the return values and the resulting trial tier. It is complete for a verification step, though error handling or retry guidance is omitted. Sufficient for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description does not need to detail parameters. The description mentions the pending_id source but adds no new semantic information beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool completes signup by submitting verification code and password, listing the returned items (access token and API key) and the resulting trial tier. This distinguishes it from sibling tools like register_account and check_pricing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after register_account by mentioning 'pending_id from register_account', but does not explicitly state prerequisites or when not to use. It provides good context about the outcome (trial tier) that aids decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!