teckel: AI/MCP Services

teckel publishes and maintains a suite of “teckel Toolkits” designed to extend the utility of LLMs and AI Agents via MCP server plugins: each teckel Toolkit is an MCP server endpoint, accessible via the standard MCP protocols. These protocols are supported by a growing number of LLM/AI/Agentic vendors. For maximum utility, the Toolkits can also be called via standard RESTful API (POST) calls, enabling them to be used in any application, not just LLM/AI/Agents.

Access to the teckel Toolkit MCP/API endpoints is protected by API keys which are allocated to the developers’ Ethereum addresses. Developers can manage their API keys via the teckel App. Developers pay for API usage on a pay-as-you-go basis via teckel credits (tc) which can be purchased via the teckel App.

teckel hosts its MCP/API servers in private data centers located in Western Europe, i.e., they are “off-cloud”.

teckel Toolkits

The following Toolkits are currently available (also, on GitHub):

teckel Ethereum Toolkit

This Toolkit provides access to a subset of the teckel web3 Ethereum JSON-RPC services—namely those that require read only access to the blockchain. (For full access to the Ethereum blockchain including transaction execution and smart contract interaction, use the full teckel web3 services JSON-RPC API.)

The main purpose of the Ethereum Toolkit is to give LLM/AI/Agents real-time access to Ethereum blockchain basic information. Once connected to an LLM via your MCP-client-of-choice, the LLM can use the suite of tools in the Toolkit to provide answers to prompts such as:

“What is the current Ethereum price in USD on the mainnet and the sepolia testnet?”

“What is the current Ethereum gas price on the mainnet and the sepolia testnet?”

“What is the balance of my Ethereum Account on the mainnet and the sepolia testnet?”

“What transactions have been processed in the latest block on the mainnet and the sepolia testnet?”

teckel Navigation Toolkit

The main purpose of the Navigation Toolkit is to give LLM/AI/Agents the ability to provide accurate navigation information. There are three main application areas (all can be combined):

Time and Place

• Accurate determination of local time and sun position at any place in the world, taking into account time zones and daylight savings corrections.

• LLM prompt examples using these tools:

“How many hours of daylight will there be on the Isle of Man on June 15th this year?”

“What time is it in Hong Kong right now, and what are the light conditions (daylight, twilight, or darkness)?”

“What time is sunrise and sunset in Hamburg, Germany tomorrow?”

“My flight is departing for San Francisco from London at 3 hours from now. The flight will take ten hours. What time will it be when I arrive in San Francisco, and what will the lighting conditions be?”

Roadtrips

• Accurate determination of driving distances and times anywhere in the world, taking into account current traffic (and allowing for ferry trip times if water crossing required). Computation of latitude and longitude for any place specified by address, postal code, name, landmark, etc. Search for hotels, restaurants, or any other typical feature, within a specified range of any location.

• LLM prompt examples using these tools:

“What is the distance, and how long will it take, to drive from Joshua Tree to Oakland CA?”

“Find me 10 hotels within 20 miles of Prestwick Airport, UK”

“What is the latitude and longitude of UK postcode IM4 7BN?”

“If I drive from Berlin to Munich tomorrow, departing at 9am local time, will it be dark when I arrive?”

General Aviation

• Accurate computation of distances between points on Earth using the World Geodetic System 1984 (WGS84), the geodetic reference system that defines the Earth’s shape and size as an oblate spheroid, the standard for the Global Positioning System (GPS). The distances can be computed either as great-circles (i.e., shortest distance between the two points) or rhumblines (i.e., the distance measured along a straight line drawn on a mercator projection map).

• Accurate computation of the end-point for a given start-point, bearing, and range. The bearing can be referenced to either true or magnetic north (if magnetic, the magnetic variation is automatically calculated and corrected for), and the track can be specified as a great circle or rhumbline.

• Search for airports within a specified range from any location in the world, with multiple optional filters (such as “must have AVGAS” etc). For the US only, can also search for navaids, fixes, features, and obstacles.

• Obtain the latest aviation weather report (METAR) and forecast (TAF) for any worldwide ICAO designated weather station (in raw and decoded formats). Find the nearest ICAO designated weather station to a given location, or multiple stations within a specified range of that location.

• Computation of aviation-pertinent atmospheric parameters (versus altitude) given the measured temperature and pressure (from METARs).

• Perform VFR (Visual-Flight-Rules) flight route calculations between specified origin and destination airfields, plus up to ten optional intermediate waypoints (when not routing direct). Automatically computes wind corrections (using latest METARs along the route, and assuming a power-law extrapolation from METAR measured winds at 10m AGL to wind aloft), magnetic variation, and sunlight conditions (e.g., if daylight, twilight, or night-time at each waypoint plus direction (azimuth and zenith) to the sun relative to flight track (to assess if glare will be an issue). For the origin and departure airfields, gives essential information for each runway (surface, dimensions) plus the crosswind and headwind/tailwind components (computed from latest METARs), plus, where the information is available, details on runway lighting, visual approach aids, and instrument approach aids. Also provides the communication frequencies for the origin and departure airfields, plus where the information is available, telephone contact details, operating hours, and whether PPR is required. Utilizes current atmospheric conditions (from latest METAR data) to model the atmosphere (and its deviations from the International Standard Atmosphere) in order to compute for example, density altitude at the departure airfield, true airspeed (TAS), Mach number, and estimated cloud-base and freezing altitude along the route, and pressure altitude at each waypoint (i.e., the altitude displayed on the altimeter when set at standard pressure setting, useful for flight level determination). All navigation timings are presented in UTC as well as in local time (taking account of timezone and Daylight-Savings corrections). As well as providing a route summary (total distance, flight time, fuel consumption), all relevant data is provided per leg to facilitate the generation of a navlog (e.g., groundspeed, distance, timings, magnetic heading and true track, fuel used, etc). Aircraft Performance and route profile data (indicated airspeed, altitude, fuel flow rate) can be specified or default values (100kts, 2500ft 8 USgal/hour) are used if omitted. The latest METAR (current weather) and TAF (forecasts) reports are provided for each waypoint. A URL is also provided which enables the route to be viewed on skyvector.com (via any web browser). From there, the route can be exported to popular pilot apps such as Garmin Pilot, ForeFlight etc.

• LLM prompt examples using these tools:

“What is the great-circle distance between Prestwick Airport and Goodwood Airfield in the UK?”

“What is the latitude and longitude of the location 25 nautical miles on a true bearing of 335 degrees from EGNS?”

 “What is the latitude and longitude of the location 45 nautical miles on a magnetic bearing of 85 degrees from the Daventry VOR (DTY) in the UK?”

“What is the nearest METAR report for Wolverhampton Airport, UK?”

“Perform the flight route calculations for a VFR flight from Wolverhampton Airport, UK, to EGTK, with intermediate waypoint 15 nautical miles on a magnetic bearing of 210 degrees from Wolverhampton. Indicated airspeed will be 95 kts, altitude 2000 ft, departing Wolverhampton 45 minutes from now. Provide details for the navlog, plus a skyvector URL.”

Then,

“How long is the drive from EGTK to Chipping Norton?”

“Perform the flight route calculations for a VFR flight from Palo Alto Airport, CA, to Half Moon Bay airport, CA, with an intermediate waypoint overflying Stanford University. Indicated airspeed will be 100 kts, altitude 3000 ft, departing Palo Alto two hours from now. Provide details for the navlog, plus a skyvector URL.”

Then,

“Are there any Mexican restaurants within 10 miles of Half Moon Bay airport?”

In the following two examples note that any overwater routes are constrained.

An example of a more complex planning request and the resultant output via PDF file:

“Please provide a VFR flight plan departing Liverpool this week with final destination of Dublin. Please ensure all waypoints have AVGAS available and supply 3 overnight accommodations at each waypoint within a 5 mile radius of the waypoint. Please ensure no over water crossings greater than 50 nautical miles. Aircraft is a small single engine Cessna. Please keep maximum flight ceiling below 8000ft. Please ensure a minimum of 1 hour of daylight upon landing at each waypoint and final destination. Please provide the best flight itinerary to minimize flight times and total travel duration. Please check weather conditions enroute to safely accommodate flight restrictions. I must arrive in Dublin no later than 2pm on Dec 31st. Please also provide a skyvector url.”

Here is the corresponding output: example PDF transcript.

Another example of a more complex planning request and the resultant output via PDF file:

“Please create a VFR only flight plan for a small Cessna with a 300nm range only landing at airports with AVGAS departing tomorrow morning from Yucca Valley CA with final destination of MIA. Avoid any over water routes greater than 50nm. Maximum ceiling is 9000ft. Require at least 1 hr of sunlight left in the day upon landing at any waypoint including the Destination. List at least 3 available lodging accommodations within a 5 mile radius of any waypoint. Include a detailed itinerary to minimize total travel time. Include a skyvector url.”

Here is the corresponding output: example PDF transcript.

For a more in-depth and historical discussion of the teckel Navigation Toolkit, please see this blog article.

How to Use the teckel Toolkits

First generate an API key using the teckel App.

Using the MCP Servers

Configure your MCP client-of-choice

Whatever the client, the configuration is essentially the same. Namely, provide the client with the MCP server endpoint and access credentials. These are typically in the form of a configuration JSON snippet, using your API key as the “Bearer” token in the “Authorization” tag. For example, here is the precise configuration for use with the Cursor desktop app (navigate within the Cursor app to the Cursor Settings -> Tools & MCP -> + New MCP server and enter these details using your actual teckel API key to replace this fake one).

MCP JSON configuration (example for use with Cursor)

Using the RESTful API Servers

The benefit of using the MCP servers is that the connected LLMs can parse the natural language in the user prompts, populate the required parameters for calling the toolkit API functions, then likewise unravel the returned JSON structure into natural language for presentation to the user. However, if you wish to utilise the teckel Toolkits at a lower level (e.g., in your own app), you can call the functions directly using the RESTful (POST) API protocols. You are then responsible for populating the input parameters, and handling the returned JSON output.

The base API URL endpoint is identical to the MCP server endpoint:

The desired function name must be appended to this URL, and the function arguments must be added as query-string parameters. The teckel API key must be added as a Bearer Token in the Authorization header. The POST protocol must be used (rather than GET), but the body can be empty since the parameters are passed in the query-string.  Below is an example curl request for calling the eth_gasPrice method in the Ethereum Toolkit with the required network parameter:

Another example, calling the perform_sun_calculations from the Navigation Toolkit:

Tools Listing

The tools available in each teckel Toolkit are summarised in the tables below.

Ethereum Toolkit Tools

All functions in this Toolkit must be “awaited” by the client in order to retrieve the results from the request response, i.e., they are not “fire-and-forget”. Accordingly, the client timeouts must be adjusted to allow for the required response times.

Navigation Toolkit Tools

All functions in this Toolkit must be “awaited” by the client in order to retrieve the results from the request response, i.e., they are not “fire-and-forget”. Accordingly, the client timeouts must be adjusted to allow for the required response times.

Example call to the flight_route_calculations function

Teckel Credit Balance

Each toolkit also has a function for checking the teckel credit balance pertaining to the Ethereum address tied to the API key.

The LLM prompt would be:

“What is my teckel credit balance?”

The corresponding direct RESTful API method is:

get_teckel_credit_balance_for_apikey

Tools Pricing

MCP/API billing is accrued per call in real-time, but aggregated hourly in the teckel billing system, so recent calls will not show up immediately in your account balance (and statements), but will appear after the upcoming hourly billing cycle.

Ethereum Toolkit Tools

Pricing is identical to the Ethereum RPC Server (JSON-RPC Method) pricing for web3 services.

Navigation Toolkit Tools

The following table lists all the available MCP/API functions and the corresponding price per call. Some functions make nested calls to other functions. Each nested call is billed separately.

For MCP calls made via LLMs, the LLM fees are charged separately by the MCP client app and are not included in these API call fees.

For functions that rely on external third-party services such as Google APIs, the fees charged by the external service are handled by teckel and re-charged in these API call fees.

The Base Call Fee is 1 teckel credit (tc) for the Navigation Toolkit pricing.

Rate Limiting

All MCP/API calls are subject to rate-limiting per API key. The thresholds are not published, but if a given API key has exceeded the rate limit, a 429 error code will be returned on the given call.

Errors

If the MCP/API call fails due to user error resulting in a 4xx error code, the user is charged one Base Call Fee. If the API call fails due to server error resulting in a 5xx error code, the user is not charged. If the given call is part of a cascade of nested calls, the above rules apply to the “outer” call: In other words, if the outer call fails with a 4xx error code, the user is charged one Base Call Fee (for the failed outer call), and there will be no charge for any of the cascaded calls (whether they succeeded or not). Likewise, if the outer call fails with a 5xx error code, the user is not charged at all (even if the cascaded calls succeed).

Note on API Key Security

Should you have concerns that your API key has been compromised (and someone else may be consuming your teckel credits by using your key), simply replace the key via the API Key Manager → Replace API key in the teckel App. The old key will then be immediately disabled.