CO₂ estimates for general-aviation flying: by aircraft and hours, by fleet, or by fuel.
Scored across 10 tools
Most tools target clearly distinct actions (estimating emissions, searching aircraft, importing logbooks, fetching account/certificate data). However, get_my_impact, get_api_impact, and list_my_offsets all report on offset activity and could be confused, though the descriptions distinguish total impact vs API-specific vs order lists.
Consistent snake_case verb_noun pattern throughout: estimate_flight_hours, get_certificate, list_my_offsets, quote_offset, search_aircraft, etc. No mixing of conventions or vague verbs.
10 tools is well-scoped for a carbon-offsetting assistant, covering estimation, lookup, account, and offset reporting without redundancy. Each tool earns its place.
Covers the core lifecycle well: emissions estimation (hours and fuel), aircraft lookup, logbook import, pricing, account and offset history, and certificates. Minor gap in that actual offset purchase is delegated to the website, so no in-tool transaction, but that appears intentional.
Estimates the CO₂ from flying hours in one or more aircraft types: one row for a pilot, several rows for a fleet (a school, club or operator). CO₂ = hours × the type’s kg of CO₂ per flight hour, from its fuel flow at about 75% power. Types match by name, ICAO type designator or page slug.
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | "year" when the hours are per year, "total" for a one-off total | year |
| flights | Yes | One row per aircraft type |
| Name | Required | Description |
|---|---|---|
| rows | Yes | |
| period | Yes | "year" when the hours are per year, "total" for a one-off total |
| tonnes | Yes | |
| totalKg | Yes | kg of CO₂, rounded |
| totalHours | Yes | |
| dataUpdated | Yes | When the aircraft figures last changed |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, closed-world behaviour. The description adds genuinely new context: the estimation method and its key assumption (kg CO₂ derived from fuel flow at ~75% power), so the agent knows the output is an approximation with a stated basis rather than measured data.
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?
Three tight sentences: purpose first, then the scope/row semantics, then the formula and matching rule. No filler, though the formula detail in the final sentence is dense enough to warrant a second read.
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?
With an output schema present, return values need no explanation, and annotations cover the safety profile; the description completes the picture by explaining the estimate's basis and row semantics. The one missing piece is sibling differentiation against estimate_fuel_burn.
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 description coverage is 100%, so parameters (period enum, flights rows, aircraft, hours) are already documented. The description restates the aircraft-matching semantics (name, ICAO designator, page slug) and the hours-to-CO₂ relationship, adding marginal value over the schema rather than filling a gap.
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?
States a specific verb+resource ('Estimates the CO₂ from flying hours') and the scope (one aircraft type for a pilot, several for a fleet). It also gives the computation basis (hours × kg CO₂ per flight hour). However, it never names or distinguishes itself from the very close sibling estimate_fuel_burn, which shares the emissions-estimation territory.
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 explains the input shape (one row per type) but gives no guidance on when to choose this tool over estimate_fuel_burn or the impact tools (get_my_impact, get_api_impact). There are no exclusions, prerequisites, or routing conditions — an agent must infer the choice from parameter availability alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimates the CO₂ from burning an amount of aviation fuel: avgas 100LL, mogas (motor gasoline) or Jet A, in US gallons, liters or kg. Uses the US EPA factor per US gallon and the fuel’s density for liters and kg.
| Name | Required | Description | Default |
|---|---|---|---|
| fuel | Yes | The fuel burned | |
| unit | Yes | US gallons, liters or kg | |
| amount | Yes | How much fuel, in `unit` |
| Name | Required | Description |
|---|---|---|
| kg | Yes | kg of CO₂, rounded |
| fuel | Yes | |
| unit | Yes | |
| amount | Yes | |
| tonnes | Yes | |
| pageUrl | Yes | The page that explains the factor |
| dataUpdated | Yes | When the fuel figures last changed |
| kgCo2PerUsGal | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful methodology beyond annotations: it specifies the US EPA factor per gallon and density-based conversion for liters and kilograms. It does not disclose precision, rounding, or error behavior, but those are minor for a deterministic read-only estimator.
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 sentences, front-loaded with the core action and scope. The second sentence supplies the calculation basis without padding, and every clause earns its place.
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 output schema exists and annotations already declare the safety profile, the description needs only to explain the estimation scope and method. It does so completely: inputs (fuel type, amount, unit) and the conversion approach are covered, and return values are handled by the output schema.
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 description coverage is 100%, so the baseline is 3. The description expands the fuel enum values (e.g., 'avgas 100LL', 'mogas (motor gasoline)', 'Jet A') and clarifies the unit handling and conversion basis, adding meaning beyond the schema's bare enum labels.
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?
States a specific verb ('Estimates'), resource ('the CO₂ from burning an amount of aviation fuel'), and enumerates the supported fuel types and units. This clearly distinguishes it from sibling tools like estimate_flight_hours, which address a different estimation task.
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 when you need to estimate CO₂ from a known fuel quantity, but it never explicitly says when to use this tool versus alternatives (e.g., estimate_flight_hours). No exclusions or prerequisites are given, leaving usage to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
For a company that uses the TrimCarbon offset API: how much CO₂ it has offset through the API, in total, in the last 30 days and by month, and its API access status. Needs the user to connect their TrimCarbon account.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| kg | Yes | kg of CO₂ bought through the API, live mode |
| apiUrl | Yes | |
| months | Yes | The last 12 months with purchases, newest first |
| status | Yes | |
| purchases | Yes | |
| kgLast30Days | Yes | |
| lastPurchase | Yes | YYYY-MM-DD |
| testPurchases | Yes | Simulated test-mode purchases, not counted |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description usefully adds the account-connection/auth prerequisite and the shape of the returned data, but says nothing about freshness, caching, or failure modes when the account is not connected.
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?
A single front-loaded sentence that leads with the scope qualifier ('For a company that uses the TrimCarbon offset API') before enumerating outputs. It is slightly dense but every clause earns its place; no redundant filler.
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 an output schema exists, the description need not detail return values, and it still gives a useful summary plus the connectivity prerequisite. The only omission is how this differs from get_my_impact, which an agent could reasonably confuse it with.
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 tool takes zero parameters, so the baseline is 4 — there is no argument syntax an agent needs documented, and the schema is trivially complete at 100% 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 names a specific verb+resource (API CO₂ offset impact) and enumerates the exact breakdown returned: total, last 30 days, by month, plus API access status. The 'TrimCarbon offset API' scope implicitly separates it from the broader get_my_impact and list_my_offsets, but it never explicitly routes the agent away from those siblings.
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?
It states a precondition — the company must use the TrimCarbon offset API and the user must connect their TrimCarbon account — which is genuine usage context. However, it gives no when-to-use vs. when-not guidance and never mentions the closely related get_my_impact or list_my_offsets, leaving the agent to infer selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Shows one of the signed-in user’s TrimCarbon certificates: kg of CO₂, holder, dates, projects with their registries and retirement serial numbers, and links to the public certificate and its PDF. Takes the certificate number (TC-7K2M-9QXF-4HJD) that list_my_offsets returns. Needs the user to connect their TrimCarbon account.
| Name | Required | Description | Default |
|---|---|---|---|
| certificate | Yes | Certificate number, such as TC-7K2M-9QXF-4HJD |
| Name | Required | Description |
|---|---|---|
| kg | Yes | |
| url | Yes | The public certificate page |
| holder | Yes | |
| number | Yes | |
| pdfUrl | Yes | |
| source | Yes | |
| status | Yes | |
| issuedOn | Yes | YYYY-MM-DD |
| placedOn | Yes | YYYY-MM-DD |
| projects | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so safety is covered. The description adds genuinely non-annotated context: the authentication requirement to connect a TrimCarbon account. It does not cover error cases or pagination/rate limits, keeping it short of a 5.
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 sentences, front-loaded with the operation and its key output, followed by the prerequisite. The enumeration of returned fields is somewhat redundant given the tool has an output schema, which slightly dilutes density.
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?
With an output schema present, the description does not need to justify return values, yet it conveniently summarizes them. Auth requirement and parameter provenance are both covered, so an agent has everything needed to invoke this single-parameter read tool correctly.
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 an example value already in the schema, so the baseline is 3. The description adds provenance meaning beyond the schema by stating the identifier is the one returned by list_my_offsets, which helps the agent locate a valid value rather than guess.
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?
States a specific verb and resource ('Shows one of the signed-in user's TrimCarbon certificates') and enumerates the returned content (CO₂, holder, dates, projects, serial numbers, links). It also distinguishes itself from the sibling list_my_offsets by naming it as the producer of the required identifier.
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?
Explains where the certificate number comes from ('that list_my_offsets returns') and states the prerequisite ('Needs the user to connect their TrimCarbon account'). It gives clear context for when this tool applies, though it stops short of explicitly naming conditions where another tool would be the better choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Shows the signed-in TrimCarbon account: email, current offset plan (monthly or yearly, kg of CO₂ per period, renewal date) and offset API access. Needs the user to connect their TrimCarbon account.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| plan | Yes | |
| Yes | ||
| language | Yes | |
| apiAccess | Yes | |
| accountUrl | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds the non-obvious connection/auth prerequisite that the annotations do not convey, though it says nothing about failure modes when no account is connected.
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 tight sentences with the returned data front-loaded and the prerequisite last; every clause earns its place and nothing is repeated from the schema or annotations.
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?
An output schema exists, so return-value detail is technically redundant, yet the description still summarizes the payload and adds the connection prerequisite. Nothing an agent needs in order to call this correctly is missing.
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?
Zero parameters, so baseline is 4. The description correctly implies a no-argument call by framing everything around the signed-in user, with no phantom inputs suggested.
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?
States a specific verb (shows) and resource (the signed-in TrimCarbon account) and enumerates exactly what the account view contains: email, offset plan cadence, kg CO₂ per period, renewal date, and API access. This clearly separates it from siblings like get_my_impact and list_my_offsets without needing to name them.
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 prerequisite ('Needs the user to connect their TrimCarbon account') gives an actionable condition, but there is no guidance on when to prefer this over get_my_impact or list_my_offsets. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Shows how much CO₂ the signed-in user has offset with TrimCarbon: the total, what is still being processed, by source (one-time, subscription, offset API), by year, and the projects funded. Needs the user to connect their TrimCarbon account.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| byKind | Yes | |
| byYear | Yes | |
| orders | Yes | Placed or certified orders |
| kgOffset | Yes | kg of CO₂ in placed or certified orders |
| projects | Yes | Projects of the issued certificates, most kg first |
| impactUrl | Yes | |
| lastOffset | Yes | YYYY-MM-DD |
| firstOffset | Yes | YYYY-MM-DD |
| kgProcessing | Yes | kg of CO₂ paid for and not yet ordered |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world safety. The description adds an auth prerequisite (account connection) and summarizes the returned data categories, but does not disclose rate limits, pagination, or error behavior. With annotations covering safety, this is adequate but not rich.
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?
Single sentence, front-loaded with the purpose, then enumerates data categories and prerequisite. No filler; every clause adds information.
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 a zero-parameter read-only tool with full annotations and an output schema, the description supplies the needed scope and the account-connection prerequisite. Nothing critical is missing for correct 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 tool takes zero parameters, so there is nothing for the description to clarify beyond the schema. Baseline 4 applies for zero-parameter tools.
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 states a specific metric and resource: how much CO₂ the signed-in user has offset, with total, processing, by source, by year, and projects funded. This goes beyond the title and implicitly differentiates it from siblings like list_my_offsets by being an aggregate impact summary rather than a list of individual offsets.
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?
No guidance on when to choose this over list_my_offsets, get_api_impact, or get_my_account. The only usage condition is a prerequisite ('Needs the user to connect their TrimCarbon account'), not an alternative-based guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Opens a card where the user picks a logbook export from ForeFlight, Garmin Pilot or LogTen. The card reads the file on the user’s device, uploads nothing, and shows the flight hours and CO₂ by aircraft type. The user can then share those totals with this conversation. Use it when someone wants the CO₂ of their flying from their logbook.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| mode | Yes | |
| formats | Yes | |
| methodUrl | Yes | How the CO₂ per hour is worked out |
| importerUrl | Yes | The same importer on trimcarbon.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (read-only, idempotent, non-destructive), but the description adds distinct behavioral facts the annotations cannot convey: the tool opens an interactive card the user must act on, the file is read on-device with nothing uploaded, and the totals must be shared back into the conversation by the user. These are essential operational characteristics.
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?
Four sentences, each carrying information: source formats, privacy behavior, resulting output, and usage trigger. It is front-loaded with the mechanism, though the output-content sentence partially overlaps the output schema and could be trimmed.
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?
An output schema exists, so return values need not be restated. Given the zero-parameter, annotation-rich, interactive nature of the tool, the description covers everything an agent needs to know before invoking it.
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 tool takes zero parameters, so the baseline is 4. The description correctly implies no input is needed and compensates by explaining the user-driven flow that replaces formal parameters.
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?
States a specific verb and resource (import a logbook export) and immediately scopes it to the concrete sources (ForeFlight, Garmin Pilot, LogTen). This cleanly separates it from estimate_flight_hours, which computes rather than imports an actual logbook.
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 final sentence gives an explicit trigger: 'Use it when someone wants the CO₂ of their flying from their logbook.' That is a clear usage context, though it stops short of naming alternatives or stating when NOT to use it (e.g., when the user has no logbook export).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the signed-in user’s TrimCarbon offset orders, newest first: date, source, kg of CO₂, status and the public certificate link once issued. Needs the user to connect their TrimCarbon account.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many orders to list, newest first |
| Name | Required | Description |
|---|---|---|
| total | Yes | All the user’s orders |
| offsets | Yes | |
| ordersUrl | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds value beyond them: the newest-first ordering and the account-connection/auth requirement, which the annotations do not convey.
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 sentences, zero filler. The resource and result ordering are front-loaded, and the prerequisite is appended only after the core purpose is established.
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?
For a one-parameter read tool with an output schema, an account prerequisite, and annotations that carry the safety semantics, nothing an agent needs in order to call this correctly is missing. Return values are already enumerative and the output schema covers structure.
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 a single, well-described 'limit' parameter (default 10, max 50). The description's 'newest first' phrasing aligns with the schema's own description but adds no new syntax or format detail — baseline 3 is appropriate when the schema does the heavy lifting.
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?
States a specific verb (Lists) and resource (the signed-in user's TrimCarbon offset orders) and even enumerates the relevant fields returned (date, source, kg CO₂, status, certificate link). This is clearly distinguishable from siblings like get_certificate (single certificate) or get_my_impact (aggregate impact figures).
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?
Gives a real precondition — the user must have connected their TrimCarbon account — which is actionable context for selecting this tool. It stops short of naming alternatives or when-not-to-use cases (e.g., preferring get_certificate for a single order's certificate), so it is clear context without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns what TrimCarbon charges to offset an amount of CO₂: a one-time purchase in whole tonnes, and for yearly amounts the monthly and yearly plans. Each option has a link to continue on trimcarbon.com, where the user signs up and pays. This tool does not buy anything. It is for when the user asks what offsetting costs.
| Name | Required | Description | Default |
|---|---|---|---|
| kg | Yes | kg of CO₂ to offset, usually from an estimate tool | |
| hours | No | Hours per year, to prefill sign-up | |
| period | No | "year" for yearly CO₂ (plans apply), "total" for a one-off amount | year |
| aircraft | No | The main aircraft type, to prefill sign-up |
| Name | Required | Description |
|---|---|---|
| kg | Yes | |
| period | Yes | |
| yearly | Yes | |
| monthly | Yes | |
| oneTime | Yes | |
| currency | Yes | |
| contactUrl | Yes | For amounts above the caps |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safe-read semantics (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower. The description still adds real value: it clarifies no purchase occurs, that results include links to continue on trimcarbon.com where signup/payment happens, and that pricing comes in whole-tonne increments with monthly and yearly plan variants.
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?
Four tight sentences, front-loaded with what is returned before the scope caveat and the usage condition. Every sentence carries distinct information: return shape, the outbound links, the no-purchase boundary, and the trigger condition.
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?
With an output schema present, the description need not enumerate return fields, and the annotations already establish it as a safe read. What remains valuable — that no transaction occurs and that the user completes signup on trimcarbon.com — is stated. It is complete enough, though it could note that inputs are usually fed from an estimate tool, which it only implies indirectly.
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 description coverage is 100%, so all four parameters (kg, hours, period, aircraft) are already documented in the schema. The description hints at the year/total distinction via 'for yearly amounts the monthly and yearly plans,' but adds no syntax, units, or format detail beyond what the schema provides, so the baseline of 3 applies.
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?
States a specific verb and resource: returns TrimCarbon's pricing to offset a given amount of CO₂, broken into one-time purchase and monthly/yearly plans. This clearly separates it from the sibling estimate_* tools (which compute emissions) and the get_certificate/list_my_offsets tools (which retrieve existing purchases).
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?
Gives an explicit usage condition ('for when the user asks what offsetting costs') and an explicit negative boundary ('This tool does not buy anything'), which prevents an agent from misusing it as a purchase action. It does not name a sibling alternative for the actual sign-up/purchase path beyond pointing at trimcarbon.com, so it falls just short of full when/where routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds the aircraft types TrimCarbon has figures for, by name (e.g. "Cessna 172", "Skyhawk"), ICAO type designator (e.g. "C172", "PA28") or page slug. Returns each type with its kg of CO₂ per flight hour. The list covers about 60 general-aviation types, plus a few airliners (per passenger) and business jets.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Most types to return | |
| query | Yes | A name, ICAO type designator or page slug |
| Name | Required | Description |
|---|---|---|
| aircraft | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond them: the corpus size (~60 GA types), that airliner results are expressed per passenger, and that business jets are included — all of which shape how an agent interprets matches.
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?
Three sentences, purpose front-loaded, then input formats, then dataset scope — each sentence carries distinct information and there is no filler or repetition of the title.
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?
With an output schema present the description needn't explain the return shape, and it still briefly notes the CO₂-per-flight-hour payload. The only real omission is any guidance on result cap or how to widen/narrow the search, which leaves a small gap for a search tool with a 'limit' parameter.
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 baseline is 3, but the description earns a bump by giving worked query examples ('Cessna 172', 'Skyhawk', 'C172', 'PA28') that show the accepted value formats. It still says nothing about the limit parameter's behavior, which the schema handles on its own.
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?
States a specific verb and resource ('Finds the aircraft types TrimCarbon has figures for') and enumerates the three query forms — name, ICAO designator, page slug — with concrete examples. Nothing among the siblings (estimate_*, get_*, import_logbook) could be mistaken for this lookup.
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?
Usage is only implied: it is clearly a prerequisite lookup for the CO₂-per-hour figures that the estimate_* siblings consume, but the description never says to call this before estimate_fuel_burn/estimate_flight_hours, nor does it state when not to use it. No alternative retrieval path is named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
estimate_flight_hoursestimate_fuel_burnget_api_impactget_certificateget_my_accountget_my_impactimport_logbooklist_my_offsetsquote_offsetsearch_aircraftFerry-flight price estimates + aircraft, airport, FAA-registry, route & live-flight data.
Climatiq MCP — carbon footprint calculator with emission factors
Verified CO2e for any transaction, activity, flight, shipment or CBAM import. 200+ countries.
Carbon footprints for products, carts, receipts and files — with one-step offsetting.
Add one secure layer between your agents and this server.