How do I use Clearspar Part 135 MCP?

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., "@Clearspar Part 135 MCP How concentrated is Alaska's Part 135 charter market?" 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.

Clearspar Part 135 MCP

by portofcams

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Clearspar Part 135 MCP

An MCP server that turns Claude into a US Part 135 market analyst over my live Clearspar FAA operator dataset — 1,890 active Part 135 charter certificate holders scraped from the official FAA xlsx (fleet size derived from tail counts, state-mapped).

It wraps my real, key-gated endpoint GET /api/prospects on clearspar.binnacleai.com. The tools compute — concentration ratios, HHI, fleet distributions, rankings — they don't just dump rows. Ask "How concentrated is Alaska's Part 135 charter market?" and Claude pulls all 303 Alaska operators live and answers with real math.

This is a thin analyst layer over my own production data — not a public FAA API. It's read-only and key-gated.

What it is (honest scope)

The dataset reliably populates three dimensions: operator name, state (2-letter USPS), and fleetSize (FAA tail count), plus a crmStatus pipeline field. Every tool here is built on those. Sparse/empty fields (email, phone, website, style, certificate dates, aircraft type, lat/lng) are deliberately not exposed as tools — see "Not built" below — so the server never fabricates a metric it can't back with data.

Related MCP server: beast-baseball

Tools

Tool	What it computes
`market_summary(state, topN?)`	Operator count, total tails, avg & median fleet, largest operator, top-5 tail share, HHI concentration, top operators.
`fleet_ranking({state?, limit?})`	Operators ranked by fleet size. State-scoped or the full ~1,890 universe.
`compare_operators(names[])`	Side-by-side of 2+ operators (state, fleet, certNo, CRM status); who's largest, shared state.
`competitive_landscape(state)`	Fleet-size distribution buckets, top-1/3/5 concentration, HHI with plain-English read, market leaders.
`crm_pipeline_summary({state?})`	Live counts across CRM stages (NEW/CONTACTED/REPLIED/DEMO/CLOSED/DEAD).

Not built (data doesn't support it)

Proximity / radius / "operators near X" — there is no lat/lng, base-airport, or ICAO field. Geography is state-level only.
Operator-type segmentation (bush vs scheduled vs tour) — the style field exists but is NULL in 100% of records.
Contact / email / phone outreach tools — email, phone, and website are populated on ~0.5% of records (known enrichment gap).
Certificate-age / aircraft-make-model tools — no cert-issue-date or aircraft-type field exists; only a derived fleetSize integer.

Install

cd clearspar-part135-mcp
npm install
npm run build

Configure

Copy .env.example and fill in the key:

cp .env.example .env

CLEARSPAR_BASE_URL=https://clearspar.binnacleai.com
CLEARSPAR_API_KEY=<the DIGEST_API_KEY value>

The endpoint is key-gated (returns 401 without a valid key — that gate is verified). The key is the DIGEST_API_KEY env var on the takeoff-app Docker container (host 144.202.116.229):

# retrieve without printing it into history/logs
docker exec takeoff-app printenv DIGEST_API_KEY

CLEARSPAR_API_KEY is required — the server refuses to call the API without it.

Claude Desktop config

Add to ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "clearspar-part135": {
      "command": "node",
      "args": ["/Users/johnthomasair/code/clearspar-part135-mcp/build/index.js"],
      "env": {
        "CLEARSPAR_BASE_URL": "https://clearspar.binnacleai.com",
        "CLEARSPAR_API_KEY": "<the DIGEST_API_KEY value>"
      }
    }
  }
}

Restart Claude Desktop. The five tools appear under the plug icon.

Demo prompts

"How concentrated is Alaska's Part 135 charter market?"
"Give me a market summary for Hawaii's Part 135 operators."
"Rank the top 15 Part 135 operators nationwide by fleet size."
"Compare Grant Aviation and Bering Air."
"What's the competitive landscape in Texas — is it fragmented or dominated by a few?"
"Where does my CRM pipeline stand for Alaska?"

How it talks to the API

GET /api/prospects?state=&crmStatus=&limit=&offset= with header X-API-Key.
Response: { "total": <count of matching ACTIVE rows>, "rows": [ <Prospect> ] }. The server always filters status: 'ACTIVE'.
limit is hard-capped at 500 server-side. Any tool needing full coverage paginates by offset until it has all total rows, and caches the ~1,890-row universe for the process lifetime (the data only changes when the FAA scraper re-runs).
There is no free-text search param, so compare_operators matches names client-side.
Read-only: only GET is ever called (the route also has POST/PATCH, which this server never uses).

Live data sanity (as of build)

total = 1890 active operators · AK = 303 · HI = 28 · all certType = "135" · all crmStatus = "NEW". Verified against the live endpoint; fleetSize ranges 1–386 nationwide (1–42 in AK).

Work with me

I'm John Thomas — I run BlueWave Projects, an AI build studio. I ship production MCP servers, Claude agents, and LLM-in-the-loop pipelines — usually in days, not months — over real, often regulated data (FAA Part 135, maritime AIS, Hawaii property records). USCG Master Captain; deep in aviation, maritime, and construction operations.

Want Claude wired into your own data or workflow? john@binnacleai.com · https://bluewaveprojects.com

Available Tools

5 tools

compare_operatorsA

Side-by-side comparison of 2+ named operators (state, fleet size, certNo, CRM status), with which is largest and whether they share a state. Names are matched client-side (no server text search).

ParametersJSON Schema

Name	Required	Description	Default
`names`	Yes	Operator names (full or partial), at least 2, e.g. ['Grant Aviation','Bering Air'].

TDQS

A4.2/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses that the comparison includes specific fields and outputs which operator is largest and whether they share a state. It also notes client-side matching. However, it does not mention error handling, rate limits, or data freshness, leaving some behavioral aspects unspecified.

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 extremely concise: two sentences, no wasted words. The first sentence states the core purpose and output, and the second provides a critical implementation detail. Every sentence adds value, making it easy to parse quickly.

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 the simplicity of the tool (single parameter, no output schema, no annotations), the description covers the essential information: inputs, output highlights (largest, share state), and a key implementation detail. It is sufficient for an agent to decide when to use the tool and what to provide, though it could mention potential errors if a name is not found.

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 input schema already describes the 'names' parameter with 100% coverage. The description adds meaningful context beyond the schema by stating that names are matched client-side and that at least 2 names are required, and it outlines the comparison outputs, which helps the agent understand what values to provide and what results to expect.

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 explicitly states it performs a side-by-side comparison of 2+ named operators, listing specific fields (state, fleet size, certNo, CRM status) and outputs (largest, share state). This clearly distinguishes it from sibling tools like competitive_landscape or market_summary, which focus on broader analyses rather than direct operator comparison.

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 clearly indicates when to use the tool: when comparing 2+ named operators. It also gives a key constraint: names are matched client-side (no server text search), guiding the user on input format. However, it does not explicitly provide exclusions or suggest alternatives for different use cases.

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

competitive_landscapeA

Competitive structure of a state's Part 135 market: operator count, fleet-size distribution buckets, top-1/3/5 tail concentration, HHI with plain-English interpretation, and the leaders.

ParametersJSON Schema

Name	Required	Description	Default
`state`	Yes	2-letter US state code, e.g. AK, HI.

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description carries the burden of behavioral disclosure. It enumerates output elements but does not mention data source, freshness, authentication needs, or any side effects. The description is transparent about content but not about execution behavior.

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 a single, dense sentence that front-loads the core purpose and lists specific output components. No wasted words; every element adds value. It is both concise and well-structured.

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 the tool's simplicity (one parameter, no output schema), the description provides a comprehensive list of output metrics. It is almost self-contained, though it could mention data limitations or interpretative guidance for the HHI.

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?

The single parameter 'state' is fully described in the schema (100% coverage), and the description adds no additional semantic context beyond what the schema provides. Baseline of 3 is appropriate as the description does not need to compensate.

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 specifies the tool's purpose: analyzing the competitive structure of a state's Part 135 market. It lists specific metrics (operator count, fleet-size distribution, concentration indices, HHI interpretation, leaders), distinguishing it from sibling tools like compare_operators or fleet_ranking.

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 implies usage for competitive analysis, but lacks explicit guidance on when to use this tool versus alternatives. No conditions, prerequisites, or exclusions are provided, so the agent must infer context from the tool name and sibling list.

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

crm_pipeline_summaryA

Live distribution of operators across CRM stages (NEW/CONTACTED/REPLIED/DEMO/CLOSED/DEAD), optionally scoped to a state. Reflects outreach progress in the dataset.

ParametersJSON Schema

Name	Required	Description	Default
`state`	No	Optional 2-letter US state code to scope the pipeline.

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations provided, the description carries full behavioral disclosure burden. It states 'Live distribution' and 'Reflects outreach progress', implying a read-only query, but it does not explicitly confirm idempotency, safety, or data freshness. The behavioral traits are hinted but not fully transparent.

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 two sentences long, each sentence serving a distinct purpose: the first explains the core functionality, the second adds contextual value about the tool's insight. No word is wasted.

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?

Given no output schema and moderate complexity, the description covers the main functionality but omits details about the return format (e.g., counts, proportions). It provides sufficient context for a simple aggregation tool but leaves ambiguity about 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?

The input schema has 100% coverage with a clear description for the only parameter ('state'). The description repeats the optional scoping but adds no new semantic meaning, format guidance, or behavioral constraints 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?

The description explicitly states the tool provides a live distribution of operators across clearly enumerated CRM stages (NEW/CONTACTED/REPLIED/DEMO/CLOSED/DEAD), with optional state scoping. This specific verb-resource combination clearly distinguishes it from sibling tools like compare_operators or market_summary.

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 implies usage for understanding outreach progress, but it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites. Some guidance is inferred from the stage list, but no direct comparison is offered.

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

fleet_rankingA

Operators ranked by fleet size (FAA tail count). Optionally scope to one state; otherwise ranks the whole ~1,890-operator US universe.

ParametersJSON Schema

Name	Required	Description	Default
`state`	No	Optional 2-letter US state code to scope the ranking.
`limit`	No	How many to return (default 20, max 100).

TDQS

A4.1/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 fully disclose behavioral traits. It identifies the ranking metric (FAA tail count) but omits details like sorting order (likely descending), data freshness, or that it is a read-only operation. This is adequate but not thorough.

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?

Two sentences, zero waste. The first sentence introduces the primary purpose, and the second adds key modifier. Efficient and well-structured.

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?

Given no output schema, the description should hint at return structure. It mentions operators ranked by fleet size but does not specify whether the actual tail count is included, or the sorting order. For a ranking tool with only two parameters, this is a notable gap.

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%, but the description adds practical context: state is optional and defaults to whole US, limit has default (20) and max (100). This goes beyond the schema's bare parameter descriptions.

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 returns operators ranked by fleet size (FAA tail count), with optional state scoping. This verb+resource structure is specific and distinguishes it from sibling tools like compare_operators or market_summary.

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?

Provides explicit context on when to use state parameter vs omitting for entire US universe, and mentions total operator count. Does not explicitly list exclusions or alternatives, but the guidance is clear and actionable.

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

market_summaryA

Analyst summary of a state's Part 135 charter market: operator count, total tails, avg/median fleet, largest operator, top-5 tail share, HHI concentration, and the top operators. Computed live over all operators in the state.

ParametersJSON Schema

Name	Required	Description	Default
`state`	Yes	2-letter US state code, e.g. AK, HI, TX.
`topN`	No	How many top operators to list (default 5, max 25).

TDQS

A4/5.0

Behavior4/5

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

With no annotations, description carries full burden. It discloses 'Computed live over all operators in the state,' indicating real-time computation and scope. Does not mention destructive actions or authentication, but for a read-only summary, this is reasonable.

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?

Single sentence packs many details (9 metrics) efficiently, but could be slightly dense. Front-loads key verb 'summary.' No wasted words, earning a 4.

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 no output schema, description lists all included metrics (operator count, tails, avg/median fleet, largest operator, top-5 tail share, HHI, top operators) and states live computation. This is comprehensive for the tool's purpose.

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%, so parameters are well-documented. Description adds no extra meaning beyond schema: 'state' and 'topN' are already clear from schema descriptions. 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?

Description clearly states it provides an analyst summary of a state's Part 135 charter market, listing specific metrics (operator count, total tails, etc.). It distinguishes from siblings like compare_operators (which compares operators) and fleet_ranking (which ranks fleets).

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?

Description implies usage for summary of single state's market but does not explicitly state when to use this tool over siblings or provide exclusions. No guidance on when not to use.

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

A4.1/5.0

Disambiguation5/5

Each tool targets a distinct analytical task: operator comparison, state market structure, CRM pipeline, fleet ranking, and market summary. There is no functional overlap or ambiguity between tools.

Naming Consistency4/5

All tool names use lowercase with underscores and follow a descriptive pattern (verb_noun or noun_noun), but 'competitive_landscape' uses an adjective rather than a verb, creating a slight inconsistency.

Tool Count5/5

With 5 tools, the server is well-scoped for its purpose of analyzing Part 135 charter operators. Each tool fills a distinct and necessary role without excess or deficiency.

Completeness4/5

The tool set covers core analytical needs (comparison, market structure, CRM, ranking, summary) but lacks a tool for viewing detailed information about a single operator, which would be a minor but useful addition.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

GitHub Repository

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

nyc-property-intel
io.github.ccedacero
MCP server giving Claude AI access to 22+ NYC public-record databases for real estate due diligence
Real Estate Government Data
27
DataDoe MCP
com.datadoe
Hosted Amazon Seller and Vendor MCP server for Claude, ChatGPT, Cursor, Codex, Gemini, Copilot.
E-commerce & Retail CRM
212
agentcentral A
to.agentcentral
Hosted Amazon Seller Central and Amazon Ads MCP server for Claude, ChatGPT, Cursor, and agents.
E-commerce & Retail Customer Support
26
UnifAPI
com.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
Open Data Search AI & Machine Learning
2

Related MCP Servers

flightradar24-mcp-server
Travel & Transportation Search Open Data
sunsetcoder
A
license
B
quality
B
maintenance
A Claude Desktop MCP server that helps you track flights in real-time using Flightradar24 data. Perfect for aviation enthusiasts, travel planners, or anyone curious about flights overhead!
Updated 2 years ago (2025-01-29 15:17 UTC)
2
22
47
MIT
beast-baseball
Sports Web Scraping
mw-jeong
F
license
Not graded
quality
C
maintenance
MCP server for natural language analysis of baseball league data, enabling team statistics, standings, lineup suggestions, and scouting reports via Claude Desktop.
Updated 3 months ago (2026-06-10 08:51 UTC)
Aviation MCP Server
Travel & Transportation Weather Services
AiAgentKarl
A
license
A
quality
C
maintenance
MCP server giving AI agents access to real-time aviation data — live flight tracking, airport weather, airline and airport information.
Updated 5 months ago (2026-03-24 10:19 UTC)
10
3
MIT
city-data-mcpofficial
Government Data Open Data
zencity-product
F
license
Not graded
quality
D
maintenance
An MCP server that gives Claude deep access to US public data -- demographics, economics, crime, employment, weather, housing, transit, schools, budgets, and more across 30+ cities for government intelligence workflows.
Updated 5 months ago (2026-04-19 06:52 UTC)

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/portofcams/clearspar-part135-mcp'

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

Clearspar Part 135 MCP

What it is (honest scope)

Tools

Not built (data doesn't support it)

Install

Configure

Claude Desktop config

Demo prompts

How it talks to the API

Live data sanity (as of build)

Work with me

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

city-data-mcpofficial

Latest Blog Posts

MCP directory API