Which integrations are available for this server?

Generates Chart.js configuration data for various chart types (bar, line, pie, doughnut, radar, polarArea) based on input data, enabling visualization of data obtained from other tools.

How do I use Cariot MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Cariot MCP Server list daily reports from last week" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Cariot MCP Server

Official

by CariotInc

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Cariot MCP Server

A Model Context Protocol (MCP) server with cariot APIs.

Quick Start

Prerequisites

Node.js v22+ (ES modules support)
Cariot API credentials (one of the following):
- API Access Key and Secret
- ID Token (from Cariot authentication)

Configuration

Add the following configuration to your MCP-enabled client (e.g., Claude Desktop) settings.

Option 1: API Key Authentication (Recommended)

{
  "mcpServers": {
    "cariot": {
      "command": "npx",
      "args": ["@cariot-labs/cariot-mcp-server"],
      "env": {
        "API_ACCESS_KEY": "your-api-access-key",
        "API_ACCESS_SECRET": "your-api-access-secret"
      }
    }
  }
}

Option 2: ID Token Authentication

{
  "mcpServers": {
    "cariot": {
      "command": "npx",
      "args": ["@cariot-labs/cariot-mcp-server"],
      "env": {
        "ID_TOKEN": "your-id-token"
      }
    }
  }
}

Environment Variables

Authentication (one of the following is required):

Variable	Description
`API_ACCESS_KEY`	Cariot API access key (used with `API_ACCESS_SECRET`)
`API_ACCESS_SECRET`	Cariot API access secret (used with `API_ACCESS_KEY`)
`ID_TOKEN`	Cariot ID token for authentication

Note: If both API key credentials and ID token are provided, API key authentication takes priority.

Optional:

Variable	Description	Default
`CARIOT_LOG_LEVEL`	Logging level (debug, info, warn, error)	info

No Installation Required

npx automatically downloads and runs the server.

Related MCP server: SORACOM Data Reader MCP

Available Tools

Cariot Tools

analyze_alcohol_checks: Analyze alcohol check results from daily reports to monitor compliance and identify violations.
get_daily_report: Get a specific daily report by daily report number.
get_daily_reports: List daily reports.
get_drivers: List drivers.
get_vehicles: List vehicles.
get_realtime: Get realtime snapshots for devices.

Utility Tools

generate_chart_config: Generate Chart.js configuration data based on input data. Supports bar, line, pie, doughnut, radar, and polarArea chart types. This tool can be used to visualize data obtained from other tools.

Development

Local Development

# Clone repository
git clone https://github.com/CariotInc/cariot-mcp-server.git
cd cariot-mcp-server
npm install

# Test
npm test

# Build
npm run build

Local Configuration

Using API Key:

{
  "mcpServers": {
    "cariot": {
      "command": "node",
      "args": ["/path/to/cariot-mcp-server/dist/index.js"],
      "env": {
        "API_ACCESS_KEY": "your-access-key",
        "API_ACCESS_SECRET": "your-access-secret",
        "CARIOT_LOG_LEVEL": "debug"
      }
    }
  }
}

License

MIT

Available Tools

7 tools

analyze_alcohol_checksAnalyze Alcohol Checks / アルコールチェック分析A

Analyzes alcohol check results from daily reports. Shows check status (before/middle/after), violations, check rate, and check statistics for drivers within a specified date range. Check rate is calculated based on whether both before and after checks are performed when driving (for past dates) or at least before check is performed (for current date). / 日報からアルコールチェック結果を分析します。指定された日付範囲内のドライバーのチェック状況(前/中/後)、違反、チェック率、およびチェック統計を表示します。チェック率は、運転時に乗車前と乗車後の両方のチェックが実施されているか(前日以前)、または少なくとも乗車前チェックが実施されているか(当日)に基づいて計算されます。

ParametersJSON Schema

Name	Required	Description
`driverName`	No	Driver name (partial match, put a space between family and given name) / ドライバー名（部分一致。姓と名の間に必ずスペースを入れてください）
`dateFrom`	No	Start date (yyyy-MM-dd) / 開始日 (yyyy-MM-dd)
`dateTo`	No	End date (yyyy-MM-dd) / 終了日 (yyyy-MM-dd)
`limit`	No	Number of results to retrieve (default: 20, max: 100) / 取得件数 (デフォルト:20, 最大:100)

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations, the description carries full burden and discloses key behavioral details: check rate calculation logic depending on date (past vs current), and that it shows status, violations, and stats. However, it does not mention any side effects or permissions.

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 verbose with both English and Japanese, and includes details that could be more concise. The first sentence states purpose, but the check rate explanation adds length. It is functional but not tight.

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

Completeness4/5

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

Given no output schema and no annotations, the description covers the main functionality and explains a key behavioral nuance (check rate calculation). It does not describe the return format, but that is acceptable for this context.

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%; all parameters are described in the schema. The description adds minimal new meaning beyond what the schema already provides (e.g., 'partial match' is repeated). Baseline 3 is appropriate.

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 description clearly states the tool analyzes alcohol check results, showing check status, violations, check rate, and statistics. It differentiates from sibling tools like get_daily_reports and get_drivers by focusing specifically on alcohol checks.

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

Usage Guidelines3/5

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

The description explains what the tool does but does not provide explicit guidance on when to use it versus alternatives (e.g., get_daily_reports). The context is implied but not explicit.

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

generate_chart_configGenerate Chart.js Configuration / Chart.js設定データ生成A

Generates Chart.js configuration data based on input data. Supports bar, line, pie, doughnut, radar, and polarArea chart types. Returns a ChartConfiguration object that can be used directly with Chart.js. IMPORTANT: When using this tool, you MUST embed the EXACT generated ChartConfiguration object in your final response WITHOUT any code block markers (no json, javascript, or any other formatting). Output the raw JSON object directly so the client can parse and use it. / 入力データに基づいてChart.js設定データを生成します。bar、line、pie、doughnut、radar、polarAreaのグラフタイプをサポートします。Chart.jsで直接使用できるChartConfigurationオブジェクトを返します。重要：このツールを使用した場合、生成されたChartConfigurationオブジェクトを、コードブロックマーカー（json、javascript等）を一切付けずに、そのまま生のJSONオブジェクトとして返答の末尾に含めてください。クライアントがパースして使用できるようにしてください。

ParametersJSON Schema

Name	Required	Description
`chartType`	Yes	Chart type (bar, line, pie, doughnut, radar, polarArea) / グラフタイプ（bar、line、pie、doughnut、radar、polarArea）
`labels`	Yes	Array of labels for the chart / グラフのラベル配列
`datasets`	Yes	Array of datasets / データセット配列
`title`	No	Chart title / グラフのタイトル
`xAxisLabel`	No	X-axis label (for bar, line, radar charts) / X軸ラベル（bar、line、radarグラフ用）
`yAxisLabel`	No	Y-axis label (for bar, line, radar charts) / Y軸ラベル（bar、line、radarグラフ用）

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description must carry behavioral info. It discloses the output format requirement but does not mention safety (e.g., read-only nature, error handling). The formatting instruction adds value beyond defaults.

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 bilingual and contains a critical usage instruction highlighted with 'IMPORTANT'. One sentence could be trimmed, but it remains focused and front-loaded.

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?

Given the tool generates a configuration object and has no output schema, the description sufficiently explains the return type and usage. Parameters are well-documented in schema, and supported types are listed.

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?

Input schema covers all parameters with descriptions (100% coverage). The description adds the list of supported chart types, matching the chartType enum, but does not significantly enhance understanding of individual parameters.

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 description clearly states the tool generates Chart.js configuration from input data and lists supported chart types. It is distinct from retrieval-focused sibling tools like get_daily_report.

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?

The description includes an explicit requirement to output the configuration without code block markers, guiding correct usage. It lacks explicit when-to-use vs alternatives, but siblings are all data retrieval, so context is clear.

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

get_daily_reportGet Daily Report / 運転報告詳細取得C

Retrieves a detailed daily report for a specific date and driver. / 指定された日付とドライバーの日報詳細を取得します。

ParametersJSON Schema

Name	Required	Description	Default
`dailyReportNo`	Yes	Daily report number (required) / 日報番号 (必須)

TDQS

C2.6/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, required permissions, or rate limits. As a retrieval tool, it is likely read-only, but this is not stated.

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 short and includes both English and Japanese, which is efficient. However, the inclusion of 'date and driver' without clear mapping to the parameter reduces its precision.

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?

The description lacks details about the return value, format, or what constitutes a 'detailed' report. Given the simple parameter and lack of output schema, more context would be helpful but is not provided.

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

Parameters2/5

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

The schema coverage is 100%, but the description's mention of 'date and driver' does not align with the actual parameter 'dailyReportNo', potentially misleading. No additional semantic value is added beyond the schema.

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?

The description clearly states 'Retrieves a detailed daily report' with a specific verb and resource, but mentions 'for a specific date and driver' while the parameter is a report number, causing slight confusion. It distinguishes from the sibling 'get_daily_reports' (plural) which likely retrieves multiple reports.

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 guidance on when to use this tool versus alternatives like 'get_daily_reports'. No prerequisites or context for usage are provided.

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

get_daily_reportsGet Daily Reports / 運転報告一覧取得B

Retrieves a list of daily reports for all drivers within a specified date range. / 指定された日付範囲内の全ドライバーの日報をリストで取得します。

ParametersJSON Schema

Name	Required	Description
`driverName`	No	Driver name (partial match, put a space between family and given name) / ドライバー名（部分一致。姓と名の間に必ずスペースを入れてください）
`dateFrom`	No	Start date (yyyy-MM-dd) / 開始日 (yyyy-MM-dd)
`dateTo`	No	End date (yyyy-MM-dd) / 終了日 (yyyy-MM-dd)
`limit`	No	Number of results to retrieve (default: 100, max: 500) / 取得件数 (デフォルト:100, 最大:500)

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, and the description only states a read operation. It does not disclose any behavioral traits beyond the obvious, such as permissions required, rate limits, or behavior on empty results.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two short sentences (English and Japanese). No redundant information, every part adds value.

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

Completeness3/5

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

For a simple list retrieval tool with no output schema and no annotations, the description is adequate but lacks guidance on when to use this tool versus get_daily_report, and does not describe the output structure.

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%, with bilingual descriptions for all four parameters. The tool description adds no additional insight beyond the schema, so baseline score of 3 is appropriate.

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 description clearly states the verb 'retrieves' and resource 'list of daily reports for all drivers within a specified date range'. The title and description differentiate from sibling tools like get_daily_report (singular) and other get_* tools.

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 explicit guidance on when to use this tool versus alternatives such as get_daily_report or other reporting tools. No mention of prerequisites or exclusion criteria.

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

get_driversGet Drivers / ドライバー一覧取得C

Retrieves a list of all drivers' information. / 全ドライバーの情報をリストで取得します。

ParametersJSON Schema

Name	Required	Description	Default
`driverName`	No	Driver name (partial match, put a space between family and given name) / ドライバー名（部分一致。姓と名の間に必ずスペースを入れてください）
`limit`	No	Number of items to retrieve (default: 20, max: 50) / 取得件数（デフォルト：20、最大：50）

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 bears full responsibility for behavioral disclosure. It indicates a read operation but does not mention pagination behavior, data freshness, authentication needs, or the structure of returned information.

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 very concise, consisting of a single bilingual sentence. It is front-loaded and wastes no words. However, it misses some important details that could be included without harming conciseness.

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?

Given the simple nature of the tool (list retrieval with two optional params) and no output schema, the description should at least indicate what fields are returned or that results are paginated. It only says 'drivers' information,' which is vague, and fails to mention the limit parameter's role in pagination.

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 the baseline is 3. The tool description adds no additional meaning beyond the schema's parameter descriptions. It does not explain the partial match behavior for driverName or the default limit value.

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?

The description clearly states that the tool retrieves a list of all drivers' information. The verb 'Retrieves' and resource 'drivers' are specific. However, it does not explicitly distinguish from siblings like get_vehicles, though the context of 'drivers' is unique enough.

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?

The description provides no guidance on when to use this tool versus alternatives (e.g., get_daily_report, get_vehicles). There is no mention of scenarios, prerequisites, or when not to use it.

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

get_realtimeGet Realtime / リアルタイム情報取得C

Retrieves real-time information for the specified driver or vehicle. / 指定したドライバーまたは車両のリアルタイム情報を取得します。

ParametersJSON Schema

Name	Required	Description	Default
`deviceUids`	Yes	Comma separated device UID list (required). / 取得するデバイスUIDのカンマ区切りリスト (必須)。

TDQS

C2.9/5.0

Behavior1/5

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

No annotations are present, so the description carries full burden. It fails to disclose any behavioral traits such as read-only nature, authentication needs, or side effects. The minimal description provides no transparency beyond the obvious.

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 very concise with two short sentences, but it could be more informative without becoming verbose. It is efficient but lacks substance.

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?

Given the tool has a single parameter and no output schema, the description is insufficient. It does not explain what the real-time information includes (e.g., location, speed) or the return format, leaving gaps for the agent.

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 coverage is 100% with the parameter 'deviceUids' well-described as a comma-separated list. The tool description adds no additional meaning beyond the schema, meeting the baseline for high coverage.

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 description clearly states the verb 'retrieves' and the resource 'real-time information' for a specified driver or vehicle. It distinguishes itself from sibling tools like get_drivers or get_daily_reports by focusing on real-time data.

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 guidance is provided on when to use this tool versus alternatives, when not to use it, or any prerequisites. The description merely states what it does without context.

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

get_vehiclesGet Vehicles / 車両一覧取得C

Retrieves a list of all vehicles' information. / 全車両の情報をリストで取得します。

ParametersJSON Schema

Name	Required	Description	Default
`vehicleName`	No	Vehicle name (partial match) / 車両名（部分一致）
`limit`	No	Number of items to retrieve (default: 20, max: 50) / 取得件数（デフォルト：20、最大：50）

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It does not mention that the list is filterable by name or that limit is configurable. The description is too minimal to inform the agent about side effects, auth needs, or result structure.

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 extremely short (one sentence), which is concise, but it lacks structure and depth. It does not use the space efficiently to convey important details. It is not overly verbose, but it is under-specified.

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?

Given the tool has two optional parameters and no output schema, the description is incomplete. It does not mention what fields are in the list, pagination, or any other behavior. Sibling tools like get_daily_reports might have similar listing functionality, but the description does not differentiate adequately.

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 coverage is 100% with parameter descriptions in the schema, so baseline is 3. The description adds no extra meaning about parameters; it does not describe them at all. Thus, it meets the baseline but adds no value beyond schema.

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?

The description clearly states the tool retrieves a list of all vehicles' information, which is a specific verb+resource. However, the phrase 'all vehicles' is slightly misleading as there is an optional filter parameter for partial vehicle name match. It does distinguish from sibling tools like get_drivers.

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 guidance is provided on when to use this tool versus alternatives like get_drivers or get_daily_reports. There is no mention of when to use it or when not to, and no exclusions.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.2/5.0

Disambiguation4/5

Each tool targets a distinct aspect of fleet management: drivers, vehicles, daily reports (singular/plural), real-time info, alcohol check analysis, and chart generation. The only potential confusion is between get_daily_report and get_daily_reports, but the singular/plural distinction is clear.

Naming Consistency3/5

Most tools use the 'get_' prefix consistently, but 'analyze_alcohol_checks' and 'generate_chart_config' break the pattern with different verbs. While readable, the mix of verb styles is inconsistent.

Tool Count5/5

With 7 tools, the server is well-scoped for a fleet data retrieval and analysis domain. Each tool serves a clear purpose without being excessive or insufficient.

Completeness3/5

The tool set covers core read operations (drivers, vehicles, reports, real-time) and adds analysis (alcohol checks, chart config). However, there are no write operations (e.g., create/update drivers, submit reports), which may limit agents performing management tasks.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Charts by Szum A
io.szum
Create, inspect, manage, and render charts and data visualizations as SVG/PNG or interactive embeds.
Data Visualization Image & Video Processing
132
Drivara
io.github.bsrishi
Read-only access to your Drivara fleet — jobs, drivers, vehicles, fuel, profit & analytics.
Travel & Transportation Finance
2
mcp AOAuth
co.axiom
List datasets, schemas, run APL queries, and use prompts for exploration, anomalies, and monitoring.
Databases Monitoring Search
29
stagenth · Excel 数据可视化 A
com.stagenth
Excel analytics: inspect, query (JSON rows), charts, and JSON-to-xlsx workbook writing.
Data Visualization Data Platforms
42

Related MCP Servers

MCP Energy Server
Government Data Open Data Research & Data
ebarros23
A
license
Not graded
quality
Not graded
maintenance
Provides access to comprehensive U.S. and international energy data from the EIA API, including electricity, natural gas, petroleum, coal, renewables, CO2 emissions, and energy forecasts.
Updated 10 months ago (2025-11-10 12:40 UTC)
SORACOM Data Reader MCP
Home Automation & IoT Monitoring Data Platforms
leaveanest
A
license
A
quality
D
maintenance
Enables access to SORACOM IoT platform data including Harvest sensor data, file storage, SoraCam camera footage/events, and SIM statistics through authenticated API calls.
Updated 9 months ago (2025-12-05 03:26 UTC)
5
MIT
mcp-samsara
Travel & Transportation
AutomationSquadOS
A
license
B
quality
B
maintenance
Fleet management in your assistant — vehicles, routes, drivers and HOS compliance over Samsara's public API.
Updated 17 days ago (2026-08-18 08:02 UTC)
21
4
MIT
Witzense MCP
Location Services Travel & Transportation
MightyCMEMBRENO
F
license
B
quality
C
maintenance
Enables interaction with the Witzense/JIMI device tracking Open API, providing tools for device tracking, locations, alarms, reports, OBD data, and geofences.
Updated 15 days ago (2026-08-20 05:09 UTC)
23

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/CariotInc/cariot-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server