Live flight radar: real-time position of any aircraft transmitting ADS-B right now. Search by regist
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.1/5 across 12 of 12 tools scored. Lowest: 3/5.
The flightradar_* tools are clearly distinct from each other, but the server mixes them with generic platform tools (authenticate, connect, marketplace, toolkit_info) that serve different purposes and some overlap (connect vs. authenticate; marketplace vs. toolkit_info). This creates ambiguity about what the server is actually for.
There is a clear pattern for flightradar_* tools (prefix + resource), but the rest are named inconsistently: simple verbs (authenticate, connect), nouns (marketplace), and verb_noun (report_bug, show_version). No single naming convention is applied across the whole set.
Twelve tools is a reasonable number, but the count is inflated by six unrelated platform management tools that don't belong in a flight radar server. The set feels over-scoped for its stated name and under-scoped for a general MCP platform.
The flightradar_* tools cover core needs: aircraft lookup, airport info, nearby traffic, closest aircraft, military and type filters. Minor gaps exist (e.g., no flight tracks or scheduled arrivals), but the domain is well covered. The platform tools are irrelevant to flight radar but complete in themselves.
authenticateAMCP.AI for IDE agents (Cursor, etc.): log in in the browser, copy the access token. Best: add it to this server's config as a header Authorization: Bearer <token> for a permanent, non-expiring connection. Or paste it here for a session-only login: call with { token: "" } after the user pastes, or with no args to get the link.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true, which makes this a non-read-only, idempotent operation. The description adds context about persistence (permanent vs session-only) and where the token should be placed, but does not elaborate on side effects, security considerations, or failure modes. Given the annotation coverage, 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?
The description contains several sentences but each adds value: it explains the browser flow, the permanent config option, the session-only option, and the invocation methods. It is front-loaded with the purpose and concise enough given the multiple modes. Could be tightened slightly but remains efficient.
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 simple auth tool with one optional parameter and no output schema, the description covers the main use cases: getting a link and authenticating with a token. It explains both permanent and temporary approaches. It does not mention error handling or specific response format, but that is not critical for such a tool. Overall it is sufficiently complete.
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 single optional parameter 'token' is described in the text as a JWT ('<jwt>') and its usage is explained: pass it for session-only login after the user pastes it. Since schema description coverage is 0%, the description fully compensates by explaining the parameter's format and purpose, and also clarifies the no-arg invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: authentication for IDE agents. It specifies the resource (MCP.AI server) and the action (log in), and explains how to obtain and provide the token. It implicitly distinguishes itself from sibling tools by focusing on the authentication flow rather than data queries or marketplace operations.
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 gives explicit usage instructions: either add a permanent header to the server config or call with a token for session-only login. It also explains the no-arg call to get a link. It does not explicitly mention when NOT to use it (e.g., for other auth methods), but the two modes cover the main scenarios clearly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
connectAReturns connection status and URLs. When all providers are connected, returns authenticated:true and empty pending[]. When credentials are missing, returns connect_url for the toolkit and per-install URLs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior, so the description does not need to repeat those. It adds meaningful conditional behavior: fully connected returns authenticated:true with empty pending[], while missing credentials produce connect_url and per-install URLs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact sentences, front-loads the main purpose, and uses conditional phrasing efficiently. Every sentence adds meaningful behavioral detail without unnecessary repetition.
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 simple, read-only status tool with no parameters and no output schema, the description covers the two most important states (all connected vs missing credentials). It could clarify what pending[] contains in partial-connection scenarios, but overall it is sufficiently complete for basic invocation and interpretation.
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 has zero parameters and schema coverage is effectively complete with an empty properties object. There is no parameter information for the description to add, so the baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns connection status and URLs, with specific details about successful and missing-credential states. It is distinct from siblings like authenticate, but does not explicitly position itself as the status-check counterpart to that action.
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 gives concrete scenarios (all connected vs credentials missing), which helps interpret output. However, it does not explicitly say when to use this tool versus alternatives such as authenticate, and there is no direct usage guidance or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
flightradar_aircraftAPosição ao vivo de aeronaves específicas, por matrícula (registration), código hex ICAO 24-bit e/ou callsign. Aceita até 50 identificadores numa chamada (misturando os 3 tipos). Retorna por identificador: { found, aircraft: [{ registration, callsign, type, lat, lon, alt_ft, gspeed_kt, vspeed_fpm, track, squawk, on_ground }] }. Aeronave sem resultado esta fora de cobertura ou nao esta transmitindo ADS-B agora (ex.: no chao), isso nao e erro.
| Name | Required | Description | Default |
|---|---|---|---|
| hexes | No | ||
| callsigns | No | ||
| registrations | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds important behavioral context: it accepts up to 50 identifiers mixing three types, returns per-identifier results with a found flag, and clarifies that missing results are not errors. This goes beyond the annotations by explaining the response semantics and error interpretation, though it does not disclose any rate limits or authentication requirements beyond what is typical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured paragraph that is front-loaded with the core purpose, includes key usage details (limit of 50, mixing types, response structure), and ends with a practical note about missing results. No redundant information; every sentence adds value.
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?
The tool is relatively simple with 3 optional parameters and no output schema, but the description is quite complete: it explains the input types, the limit, the response format per identifier, and the interpretation of missing results. It does not address pagination (not needed) or error cases, but given the simplicity and annotations, this is close to complete. Small deduction for lacking a concrete example of the identifier formats (e.g., exact hex format).
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 0% (property names are descriptive but no descriptions in schema). The description adds semantic meaning by explaining the three types of identifiers (hexes, callsigns, registrations) and their formats, but it does not provide detailed syntax examples or constraints (e.g., string length, case sensitivity). It adds value, but the description is not exhaustive; however, the parameter semantics are fairly self-explanatory from the names and the description compensates partially.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides live position of specific aircraft by registration, ICAO hex code, and/or callsign. It distinguishes itself from siblings by specifying the exact identifiers used and the response structure, making it clear this is for querying specific aircraft rather than airport/nearby/closest types.
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 when to use this tool (to query specific aircraft by identifier) and implicitly differentiates from sibling tools like flightradar_closest and flightradar_nearby which would cover broader spatial queries. It also notes a limitation (aircraft not found may be out of coverage or not transmitting ADS-B), but does not explicitly state when not to use it versus alternatives, so a small deduction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
flightradar_airportAInformações de aeroportos por código IATA, ICAO, GPS ou local (aceita vários códigos numa chamada). Base offline com ~90 mil aeroportos do mundo todo (incl. heliportos e pistas pequenas). Retorna por código: { found, matched_by, airport: { icao, iata, name, city, region, country, country_name, lat, lon, elevation_ft, tz, type, scheduled_service, wikipedia } }. Combine com flightradar_nearby pra ver o trafego ao redor de um aeroporto.
| Name | Required | Description | Default |
|---|---|---|---|
| codes | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) already establish a safe read profile, and the description adds meaningful context: an offline ~90k-airport base, inclusion of heliports and small runways, acceptance of multiple formats, and per-code matched_by feedback. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three terse sentences, front-loaded with the purpose. The inline return shape is compact but informative, and the reference to flightradar_nearby-ear is a single clause. No fluff.
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 one parameter and good annotations, the description covers the purpose, database coverage, lookup formats, a complete inline return-object shape, and a sibling combination tip. Remaining gaps are minor: error behavior when no airport matches and case-sensitivity or exact matching for 'GPS/local' values.
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 0%, so the description carries the full burden, and it largely does: it explains the accepted inputs (IATA, ICAO, GPS or location), that multiple codes are allowed per call, and the per-code result shape. Slightly missing are constraints like maximum code count, normalization rules, or ambiguity handling between same.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair ('Informações de aeroportos por código IATA, ICAO, GPS ou local') and clearly defines the scope: accept multiple codes and return airport metadata. It distinguishes from siblings by naming flightradar_nearby for traffic, making the static-info purpose explicit.
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 gives clear usage context: when you need informational airport data from an offline database, and explicitly recommends combining with flightradar_nearby to see traffic around an airport. It lacks explicit when-not-to-use statements for other siblings, but the channel of 'combine with X' provides adequate guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
flightradar_closestAA aeronave mais próxima de um ponto (dentro do raio em milhas náuticas). Retorna { found, aircraft } com distance_nm e bearing_deg. Bom pra responder "que avião é esse passando aqui em cima?".
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | ||
| lon | Yes | ||
| radius_nm | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, which cover the safety profile. The description adds that the tool returns a found flag and aircraft object, which is useful behavioral information. It does not mention limitations like whether it requires a connection or what happens when no aircraft is found, but with annotations covering safety and the description covering return format, it is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that packs purpose, return shape, and a usage example into two lines. It is front-loaded with the core function and has zero waste.
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 tool's moderate complexity (3 params, 2 required, no output schema, no nested objects), the description is mostly complete: it explains the return structure and gives a use case. However, it does not explain what happens when no aircraft is found (the 'found' flag is mentioned but not what the caller should do with it), and it does not mention any required authentication or connection, but those are likely implied by the sibling `authenticate` tool. With good annotations and a clear return description, a 4 is justified.
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 input schema provides parameter names and types but no descriptions, and schema description coverage is 0%. The description mentions the radius in nautical miles ('raio em milhas náuticas') but does not clarify the units or format for lat/lon (assumed decimal degrees) or the default/optional nature of radius_nm. Since the description adds minimal parameter semantics beyond the schema's types, it barely compensates, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
A description states the tool's specific verb+resource: returns the closest aircraft to a point within a radius in nautical miles, and clarifies it returns { found, aircraft } with distance_nm and bearing_deg. It clearly distinguishes from siblings like flightradar_nearby (likely returns multiple nearby aircraft) and flightradar_aircraft by focusing on the single closest aircraft.
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 includes an example of a user query ('que avião é esse passando aqui em cima?') that signals a clear use case. However, it does not explicitly state when not to use this tool or name alternatives like flightradar_nearby, so it lacks exclusions but has clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
flightradar_militaryBAeronaves militares transmitindo ADS-B agora no mundo. Retorna { total_airborne, aircraft[] } com posição, tipo e callsign de cada uma.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds only that the data is 'now' (live), which is minimal. No extra disclosure about side effects, rate limits, or data freshness is provided, so it adds little beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct and to the point, conveying the essential purpose without fluff. However, it lacks structure (e.g., separate sections for parameters or output), but for a simple tool it is appropriately concise.
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?
While the output structure is partially described (total_airborne and aircraft[] with fields), the description omits any explanation of the 'limit' parameter and does not fully specify the aircraft object fields (only position, type, callsign are mentioned). Given the lack of output schema, this description is not complete enough for reliable usage.
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 only parameter, 'limit', is not explained at all in the description or schema. With 0% schema description coverage, the agent cannot infer what 'limit' does (e.g., maximum number of aircraft returned). This is a significant 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?
The description clearly states the tool's purpose: it returns military aircraft currently transmitting ADS-B, with total count and an array of aircraft details (position, type, callsign). It also distinguishes from other flightradar tools like flightradar_aircraft by focusing on military craft.
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 military aircraft data is needed) but lacks explicit guidance on when to prefer this over alternatives like flightradar_aircraft or flightradar_nearby. No comparison or context is provided, so the decision is left to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
flightradar_nearbyAAeronaves transmitindo ADS-B agora num raio (em milhas náuticas) de um ponto, ordenadas da mais próxima pra mais distante. Retorna { total_in_radius, aircraft: [{ registration, callsign, type, lat, lon, alt_ft, gspeed_kt, track, distance_nm, bearing_deg }] }. Use com flightradar_airport pra converter um aeroporto em lat/lon.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | ||
| lon | Yes | ||
| limit | No | ||
| radius_nm | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations already mark the tool as read-only and non-destructive, the description adds important behavioral detail: it returns live/current ADS-B aircraft, orders by proximity, and exposes the exact aircraft fields and units. This goes well beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main behavior, and includes the response format without filler. Every sentence 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?
The description provides strong context: live aircraft, sorting, units, and the return shape, plus an integration hint. It falls slightly short on documenting the optional limit parameter and specific bounds/defaults, but overall is complete enough for effective use.
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 description clarifies that radius_nm is in nautical miles and that lat/lon define the point of reference. However, with 0% schema description coverage, it does not explain the limit parameter or any constraints/defaults on the coordinates, so the parameter semantics remain partially incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool as listing ADS-B-transmitting aircraft within a nautical-mile radius of a point, sorted from nearest to farthest. It also gives the full return payload structure, which removes ambiguity and distinguishes it from related flightradar_* sibling tools.
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 explicitly suggests pairing with flightradar_airport to convert an airport into lat/lon, giving actionable usage context. However, it does not explicitly say when to prefer this over flightradar_closest or other nearby-aircraft siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
flightradar_typeAAeronaves de um tipo ICAO especifico transmitindo agora no mundo (ex.: PC12 = Pilatus PC-12, E195 = Embraer 195, AS50 = Esquilo). Retorna { total_airborne, aircraft[] } com posição de cada uma. Funciona melhor com tipos menos comuns (até algumas centenas no ar); pra tipos muito comuns (A320, B738, milhares no ar) prefira flightradar_nearby numa região e filtre por type.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds real behavioral context: it only sees currently transmitting aircraft globally, returns a specific object shape, and has practical scale limitations.
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 dense, front-loaded sentences with no filler or repeated title. Each sentence contributes meaning: what the tool returns, output format, and usage guidance.
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 simple read-only lookup with no output schema, the description provides return shape, behavior, and a related alternative. The only real gap is not describing the optional `limit` parameter, which makes it slightly incomplete but not ambiguous.
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 description adds useful semantics for the `type` parameter by explaining ICAO format and providing examples. However, the `limit` parameter is not explained at all, and schema description coverage is 0%, so the tool description only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: it returns aircraft of a specific ICAO type currently transmitting, along with their positions. It also distinguishes itself from sibling tools like flightradar_nearby, which is a region-based alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when the tool works best (less common ICAO types) and when to avoid it, recommending flightradar_nearby as an alternative for common types like A320 and B738. This is concrete, actionable usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
marketplaceAInspectThe official mcp.ai marketplace — the in-platform catalog of every MCP/tool, AND the way to run them. Covers capability requests like "find an MCP that does X", "consulta um CPF", "is there a tool for Y". Core flow: action=search discovers MCPs by intent → describe returns one MCP's full profile (every tool with its id + params, pricing, auth) so you pick the right tool_id → invoke RUNS that tool. KEY: invoke works even when the MCP is NOT installed — it runs the tool pontualmente (one-off), without adding the MCP to the toolkit and without bloating the tool list. If the MCP needs a credential/login, invoke returns a connect link; if it is paid and the wallet is empty, invoke returns a checkout/top-up link (the user opens it, then you retry). Use install only to make an MCP PERMANENT in the active toolkit (its tools then show up natively in future sessions); prefer invoke for a single/occasional use. list_tools lists what is callable right now. subscribe/cancel handle per-MCP billing; report_bug sends feedback; request_mcp asks us to build a NEW MCP when nothing fits. Search/describe flag installed_in_toolkit vs installed_in_workspace. Writes (install/uninstall/subscribe/cancel and the one-off install behind invoke) require workspace owner/admin. It also carries the mcp.ai PROMPT LIBRARY, which is about ready-made prompt TEXT rather than MCPs: search_prompts finds one, get_prompt returns its full text with {{variables}} filled, and publish_prompt saves a prompt and returns a shareable mcp.ai/p/ link that opens without login.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| action | No | search | |
| mcp_id | No | ||
| message | No | ||
| tool_id | No | ||
| arguments | No | {} | |
| immediate | No | ||
| tier_slug | No | ||
| prompt_body | No | ||
| prompt_slug | No | ||
| prompt_tool | No | ||
| prompt_vars | No | {} | |
| conversation | No | [] | |
| prompt_title | No | ||
| request_name | No | ||
| cancel_reason | No | ||
| cancel_comment | No | ||
| prompt_targets | No | ||
| report_context | No | ||
| prompt_category | No | ||
| request_details | No | ||
| prompt_description | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations. Annotations only say readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description discloses critical behaviors: invoke runs even when the MCP is not installed, returns connect/checkout links and requires a retry, install makes permanent, writes require owner/admin, and search/describe flag installation status. It also explains the billing and auth implications. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but dense. Every sentence adds value: it explains the core flow, the key distinction between invoke and install, the behavior when credentials/payment are needed, permission requirements, and the prompt library. It is front-loaded with the purpose and then follows a logical sequence. There is no filler or tautology. The structure helps the agent scan for the needed action.
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 tool's complexity (many actions, no output schema), the description covers a lot: it explains the flow, payment/auth behavior, permission needs, and even the prompt library. However, it does not explicitly mention the return format for actions like search, describe, list_tools, or get_prompt. For an agent to know what to expect, some output hints would be helpful. Still, it is comprehensive enough for most use cases, so a 4 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 23 parameters, all optional, and the description covers 0% of them explicitly. However, the description explains the action enum thoroughly, and indirectly clarifies key parameters like action, mcp_id, tool_id, and arguments (via 'invoke RUNS that tool' and 'pick the right tool_id'). It also explains the purpose of list_tools and the subscription actions. But it does not detail parameters like limit, query, prompt_* fields, or immediate. Given the low schema coverage, the description compensates reasonably well but not exhaustively, hence a 4 rather than a 5.
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 starts with a clear definition: 'The official mcp.ai marketplace — the in-platform catalog of every MCP/tool, AND the way to run them.' It specifies the verb (marketplace, but really the tool is a façade for many actions) and resource, and clearly distinguishes from sibling flightradar tools and other utilities like authenticate or report_bug. It enumerates the capabilities (search, describe, invoke, install, etc.) and gives concrete examples of requests it covers, so there is no ambiguity about its purpose.
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 provides explicit guidance on when to use which action: it describes the core flow (search → describe → invoke), contrasts invoke vs install ('prefer invoke for a single/occasional use' and 'Use install only to make an MCP PERMANENT'), explains when to use subscribe/cancel, and when to use request_mcp ('asks us to build a NEW MCP when nothing fits'). It also notes permission requirements for writes. This is exactly the kind of when-to-use vs alternatives guidance we want.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
report_bugAReport a bug, missing feature, or send feedback. Include the conversation array with recent messages for reproduction.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | ||
| message | Yes | ||
| conversation | No | [] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds the 'for reproduction' rationale for including conversation data, but it does not disclose whether the report is transmitted externally, stored, or whether duplicate reports are possible despite the idempotency hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with the purpose front-loaded and no filler. Every phrase earns its place, and the key usage instruction is presented immediately after the purpose.
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 simple feedback tool with no output schema, the description covers the core purpose and the most important reproduction instruction. However, it leaves message and context semantics unspecified and does not mention any response behavior, making it minimally complete rather than thorough.
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 0%, so the description must compensate for the undocumented parameters. It explains the purpose of the conversation parameter (recent messages for reproduction) but calls it an 'array' while the schema types it as a string, and it does not clarify the required message parameter or the optional context parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Report') and names three concrete resources: a bug, a missing feature, and feedback. It clearly distinguishes this tool from the unrelated flightradar and authentication siblings by establishing it as the user-reporting channel.
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 provides a concrete usage instruction: include the conversation array with recent messages for reproduction. It does not explicitly state when not to use the tool or name alternatives, but no sibling tool serves a similar reporting purpose, so this is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
show_versionAShow the current MCP platform and adapter versions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe, non-mutating behavior is established. The description adds no additional behavioral context beyond stating that it shows versions, which is consistent with the annotations but not richer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and object. Every word earns its place, and there is no redundant or filler content.
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 zero-parameter, read-only version tool, the description is largely complete. It does not describe the exact output format, but given the simplicity of the tool and the absence of an output schema, the current wording is sufficient for an agent to invoke it 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?
The tool has zero parameters, and schema description coverage is 100%. There is no parameter information needed beyond the empty schema, so the baseline of 4 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?
The description uses a specific verb ('Show') and identifies a precise resource ('current MCP platform and adapter versions'). This clearly distinguishes it from sibling tools like flightradar_* or toolkit_info, which cover different concerns.
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 the tool is used when the agent needs version information for the MCP platform or adapter. However, it provides no explicit guidance on when to use this versus related tools like toolkit_info, and no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
toolkit_infoAReturns the current toolkit state: installed MCPs, their connection status, the accounts connected to each one, and how many catalog tools each exposes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating it is a safe read operation. The description adds that it returns the 'current toolkit state' and enumerates what that includes, which aligns with the annotations. The description does not contradict the annotations. Since annotations cover safety, the description's contribution is to enumerate what 'state' means, which is helpful. Given the strong annotation coverage, a 4 is appropriate because the description adds meaningful context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the main purpose ('Returns the current toolkit state') and then lists specific components. It is efficient with no fluff, and the structure is well-organized. Every part adds value.
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 tool's simplicity (no parameters, returns a state report) and the strong annotations, the description is quite complete. It enumerates the major components of the returned state: installed MCPs, connection status, accounts, and catalog tool counts. There is no output schema, but the description adequately conveys what the agent can expect. It could be more detailed about the exact structure of the output, but for a zero-parameter info tool, it is sufficient.
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 has zero parameters, so the description's job is to explain what the tool does, not parameter syntax. The description clearly outlines what information is returned, which is the key semantic content. Since there are no parameters, a baseline of 4 is fair: the description is clear about the tool's function even though it doesn't need to explain 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?
The description clearly states that this tool returns the current toolkit state, including installed MCPs, connection status, accounts, and catalog tool counts. It doesn't just repeat the name ('toolkit_info') but elaborates on the specific content returned, which distinguishes it from sibling tools like 'marketplace' or 'show_version' that might be related but serve different purposes.
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 does not explicitly state when to use this tool versus alternatives. However, the purpose is clear: it is a general status/state tool, so an agent could infer it is appropriate when needing an overview of the toolkit. No explicit exclusions or mentions of alternatives are provided, but the tool's name and description imply it is the go-to for state inspection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
