CorporateTravel Dispatch MCP

Official

by CorporateTravelDC

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap between raw and enriched TFR endpoints (dispatch_get_tfr vs dispatch_get_tfr_enriched) and between multiple refresh admin tools. However, descriptions clarify differences, so agents can usually select correctly.
Naming Consistency4/5
Tools follow a consistent prefix pattern (dispatch_*, flight_*) with verb_noun structure. However, there are minor inconsistencies such as 'force_opsplan_snapshot' vs 'refresh_feed', and some verbs are ambiguous (e.g., 'get' vs 'health_check').
Tool Count4/5
25 tools is on the higher end but still appropriate for a comprehensive dispatch platform covering weather, flight tracking, alerts, admin, and watchlist features. Each tool has a specific role, and no obvious bloat.
Completeness3/5
Core data retrieval is well covered, but there are gaps in trip management (no create/update/delete for runsheet) and limited watchlist editing beyond add/remove. Missing CRUD for some entities, but the surface is functional for monitoring and alerting.
Average 4.4/5 across 25 of 25 tools scored. Lowest: 3.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 16 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint. The description adds significant behavioral context: Tailscale network requirement, 403 error if not on Tailscale, and the structure of the return value. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is about 10 lines, containing a note, return format, and examples. While informative, some parts like the return format could be more concise. It is not overly long but could be streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and the presence of an output schema, the description provides enough context: return value structure, network requirement, and examples. It is fairly complete for a read-only, parameterless tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description adds meaning by detailing the return format and access constraints, which compensates for the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the active trip runsheet for today's chauffeur operations. The verb 'Get' and resource 'active triprunsheet' are specific. However, it does not explicitly differentiate from sibling tools, though the tool name itself offers some distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a note about network access requirements (Tailscale) and provides example queries that indicate when to call. It does not discuss when not to use or mention alternatives, but the context is clear for this read-only tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the env var requirement, the target (configured ntfy topics on Pi), and the return type (JSON or error string). This adds context beyond annotations (which only indicate readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear overview, Args, Returns, and Examples. It is somewhat repetitive in the first two sentences but overall concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic functionality, env var requirement, and return type. However, it lacks details on failure modes, rate limits, or what happens if the token is missing, which would be helpful given there is no output schema providing such info.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section explains each sub-parameter (message, title, priority) with max lengths, defaults, and usage hints (e.g., priority 5 for urgent). This adds value beyond the input schema's descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends a push notification via ntfy through the dispatch platform. It is distinct from siblings like dispatch_get_alerts and dispatch_admin_health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage guidance for priority levels and notes the requirement for DISPATCH_TOKEN env var. It includes examples but does not explicitly list when not to use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds that the TFRs are enriched with 'AI-generated threat interpretation' and 'plain-language summary', which provides additional behavioral context. However, it does not disclose potential downsides like latency or cost, so it adds moderate value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: first sentence gives the core purpose, then details the extra fields, then specifies the return type, and ends with practical examples. No extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and the presence of an output schema (though not fully shown), the description covers the return format and fields thoroughly. It provides enough context for an agent to understand what the tool returns. Could be improved by mentioning any access restrictions or data volume, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so schema coverage is 100%. The description explains the return value and additional fields, which compensates for the lack of parameters. Baseline for 0-param tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get active TFRs with AI-generated threat interpretation and enrichment.' It distinguishes itself from the sibling dispatch_get_tfr by listing the additional fields (threat_level, movement_type, etc.). This makes the purpose specific and distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage examples for common queries (e.g., 'Any Marine One TFRs right now?'), guiding when to call this tool. However, it does not explicitly state when not to use it or compare with alternatives like dispatch_get_tfr beyond mentioning that it has the same data with extra fields.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds context beyond annotations: it triggers an immediate fetch/parse and requires a token. No contradiction with annotations. Could mention error behavior if token is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with no wasted words; includes purpose, trigger, requirement, and example in a few sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and presence of an output schema, the description is complete: explains what it does, prerequisite, and usage example.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters so baseline 4 is appropriate; the description adds no parameter info but also needs none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'force an immediate snapshot' and the resource 'ATCSCC ops plan', and distinguishes from the sibling dispatch_get_opsplan by noting it triggers a fetch outside normal schedule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides the token requirement and an example, but does not explicitly contrast with alternatives like waiting for normal polling or other dispatch_admin tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive. Description adds value by noting it pulls from an external API, returns active alerts, and specifies the return format with fields and example usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise and well-structured: purpose, source, return format, examples. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully adequate for a no-parameter read tool with annotations and output schema present. Describes output structure and common use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so baseline 4 is appropriate. The description correctly omits parameter details as none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states it gets active NWS alerts for the DC metro region, with specific verb and resource. Clearly distinguishes from siblings like weather or other dispatch tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for DC weather alerts via api.weather.gov, but does not provide when-to-use vs alternatives or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds value by detailing the return structure (per-feed metadata with last_updated, age_seconds, error, error_msg) and examples, without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and well-structured: a one-line purpose, a bulleted return format, and concrete examples. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and the presence of an output schema, the description is complete. It explains the return format, lists specific feed names, and provides typical use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is fully covered (100%). The description does not need to add parameter semantics; a baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Get freshness and error state for all dispatch data feeds,' using a specific verb and resource. It clearly distinguishes this tool from siblings that fetch individual feed data (e.g., dispatch_get_tfr) by focusing on metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides example questions implying usage (e.g., checking stale feeds), but it does not explicitly state when to use this tool versus alternatives like dispatch_get_tfr. No exclusions or when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is well-covered. The description adds that it evaluates TFRs, weather, and airspace restrictions, and returns impact levels and recommendations, which complements the annotations but doesn't disclose additional behavioral traits beyond the annotated safe operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise, with a clear title, a short description, a well-structured return format, and useful examples. Every sentence adds value, and the information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, full annotations, and an output schema described inline, the description is complete. It specifies the geographic and operational scope (DC-area chauffeur operations), what factors are evaluated, and the exact return structure. No gaps are apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters in the input schema, so the description has no parameter details to add. Baseline score of 4 applies as there is no parameter information needed that the schema doesn't already provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Get current ground route impact assessment' with specific verb and resource. Distinguishes from sibling tools like dispatch_get_alerts and dispatch_get_tfr by focusing on DC-area chauffeur operations and route impact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides examples of when to call the tool (e.g., 'Will TFRs affect our route today?') and what to check in the response. While it doesn't explicitly state when not to use it, the context is clear and the examples guide appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral context beyond annotations: describes return format, data source (AviationWeather.gov), and example queries; annotations already cover idempotency and read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded with purpose, followed by structured return fields and usage examples; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Completely covers the tool's behavior for a no-param function with rich output; details return format and example use cases, matching the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline 4 applies; description adds value by detailing output fields and examples, compensating for lack of input parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves METAR weather snapshot for DC-area airports, specifying the data source and location, distinguishing it from sibling tools that handle alerts, briefs, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Purpose is implied but no explicit guidance on when to use vs alternatives; context suggests weather-related queries but lacks exclusions or when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show destructiveHint=true and readOnlyHint=false. The description confirms the tool is destructive by stating 'stopping automated monitoring' and that it removes data. However, it does not detail additional behavioral traits like irreversibility or authorization needs beyond what annotations hint. With annotations present, the description adds some context but not extensively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for Args, Returns, and Examples. It is concise, using only necessary sentences, and is front-loaded with the core purpose. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (two optional parameters, destructive behavior) and the presence of annotations and output schema, the description covers the essential aspects: purpose, input usage, and examples. It could be considered complete, though it might benefit from a note on idempotency or error cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides clear semantics for both parameters: session_id removes a specific session, hex removes all sessions for that aircraft. This adds value over the schema's brief descriptions ('Watchlist session ID to remove' and 'ICAO hex of aircraft whose session to remove') by explaining the behavioral difference between the two.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Remove a session from the VIP watchlist, stopping automated monitoring.' It specifies the resource (VIP watchlist) and action (remove), and distinguishes itself from sibling tools like dispatch_watchlist_add and dispatch_watchlist_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use: to remove a session from the watchlist, and provides conditions: 'Provide either session_id (precise) or hex (removes all sessions for that aircraft). At least one of session_id or hex must be provided.' It includes examples that reference flight_get_by_callsign, giving context for alternative tool use. It lacks explicit 'when not to use' but is clear overall.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds value by explaining that the database entry including hex is returned even when the aircraft is not transmitting, which is beyond what annotations provide. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns, Examples) and front-loads the purpose. It is slightly verbose but each part adds value. Could be more concise, but it's effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of annotations, the description covers the essential behaviors and return format. It explains when to use and what to expect. The output schema is not shown, but the description's return info is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides an Args section with a usage example and a clear description of the 'registration' parameter, including format and examples. The input schema also includes a description. Together, this adds meaning beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves ADS-B position and ICAO hex by tail number. It uses a specific verb+resource and distinguishes itself from siblings that query by callsign or hex.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use this tool (preferred for confirming hex before adding to watchlist) and implies it works even when aircraft is not transmitting. It does not explicitly state when not to use or mention alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide idempotentHint=true and openWorldHint=true. The description adds that it bypasses normal polling and requires a token, and that it returns a JSON confirmation or error string. It lacks details on potential side effects (e.g., rate limiting) but is consistent 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (about 100 words) and well-structured with sections: summary, explanation, Args, Returns, Examples. Every sentence serves a purpose, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers purpose, usage, parameter, and return type. It includes the crucial env var requirement. However, it could mention error scenarios or validation details for the feed name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description carries the full burden. It lists the allowed feed names and provides examples, adding value beyond the schema's minimal description. However, the parameter is simple and well-covered by the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it forces an immediate refresh of a specific dispatch feed, distinguishing it from sibling read-only getters and other admin tools like dispatch_admin_force_opsplan_snapshot. The specific verb 'force refresh' and resource 'dispatch data feed' are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly mentions when to use: when a feed is stale or in error state. It also states the prerequisite (DISPATCH_TOKEN env var). However, it does not explicitly list alternatives or when not to use, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide read-only and idempotent hints. The description adds value by noting the configuration requirement and detailing the output format (JSON with train list, fields explained), which goes beyond annotation information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening, an output specification, and helpful examples. It is relatively concise but the examples add necessary context, justifying a score of 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with a thorough output specification and adequate annotations, the description covers all essential aspects: purpose, prerequisite, and return format. It is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. The description implicitly confirms no input is needed, aligning with the baseline score of 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves current Amtrak train status at Washington Union Station, specifying the resource (Amtrak trains) and action (get status). It distinguishes from sibling tools by focusing solely on Amtrak, while siblings handle flights or dispatch administration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the prerequisite of AMTRAK_FEED_URL configuration, indicating when the tool can be used. While it doesn't explicitly state when not to use it, the context from sibling tools implies it's the correct choice for Amtrak status queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description discloses that the brief is cached and periodically regenerated, helping agents understand possible staleness. No contradictions 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by the synthesis details, caching behavior, and a structured return format. It is concise with no extraneous content, earning its keep with every sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers input (none), output (detailed textual schema), behavioral details (caching), and usage examples. It adequately equips an agent to understand and invoke the tool, though a formal output schema JSON would further enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters (baseline 4), the description doesn't need to elaborate on parameter details. It instead explains the return format and provides usage examples, which is helpful but not required for parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving an AI-generated daily operational brief for CS Executive Services, specifying the synthesized components (TFR, weather, CPS, alerts, ops plan) and its use case (morning standup/client briefing). This distinguishes it from sibling tools that retrieve individual components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the brief is suitable for morning standup or client briefing, and examples imply it's for high-level summaries. While it doesn't explicitly contrast with siblings, the synthesis context makes it clear when to use this aggregated view versus specific tools like dispatch_get_cps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description discloses the need for an API key, the return type (JSON list or error string), and the content of each NOTAM object. This adds valuable behavioral context without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a clear explanation of purpose, requirements, return format, and examples. It could be slightly more compact, but it effectively communicates all necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no parameters and an output schema, the description fully covers prerequisites, return format, usage, and source. It provides examples and explains error conditions, making it complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With no parameters, the schema provides full coverage, so the description's mention of API key configuration is sufficient extra context. No further parameter information is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets active NOTAMs from the dispatch platform, specifying the source (FAA NOTAM API) and coverage (DC-area airports and airspace). The verb 'Get' and resource 'NOTAMs' are specific, and the tool is easily distinguished from sibling tools like dispatch_get_alerts or dispatch_get_tfr.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite (FAA_NOTAM_API_KEY configuration) and provides usage examples showing how to filter by location or text. However, it does not explicitly state when not to use the tool or compare it to alternatives, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, etc. The description adds value by detailing the return structure and the raw text field. No contradictions; it consistently describes a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured: first sentence states purpose, then bullet points for return fields, followed by examples. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and an output schema present (as per context signals), the description fully explains the tool's purpose, output format, and usage examples. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, baseline is 4. The description adds meaning by explaining what the tool does and the structure of its output, beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the FAA ATCSCC National Operations Plan snapshot, specifies the data source, and lists the returned fields (snapshot_time, programs, raw_text). This distinguishes it from sibling tools like dispatch_get_alerts or dispatch_get_weather.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete examples of when to call the tool (e.g., 'Are there any ground delays at IAD?'), showing the usage context. However, it does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds beyond annotations by detailing the data source (FAA XML feed), return format (JSON list or error string), and the fields included in each TFR object, providing useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: a single sentence states purpose, followed by one sentence on data source, another on distinction from sibling, then a clear return specification, and practical examples. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and existing output schema and annotations, the description fully covers the tool's purpose, behavior, return format, and usage guidance with examples. It is complete for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100%. The description does not need to explain parameters but still adds value by describing the return structure and fields, earning a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets all active TFRs from the dispatch platform, specifies the resource (TFRs) and action (get all active), and distinguishes from the enriched sibling by noting the lack of AI threat interpretation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides an alternative tool ('dispatch_get_tfr_enriched') for AI-enriched TFRs, and gives example use cases (checking for active TFRs, filtering by type), offering good guidance on when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds context about automatic ntfy push alerts when tracked events occur, which is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: purpose, what is tracked, alerts, return format, and two clear examples. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters, an output schema present, and comprehensive annotations, the description covers all necessary aspects including return format and example use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has no parameters (100% coverage), so the description correctly omits parameter details. The examples show client-side filtering, which adds value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb 'Get' and specifies the resource 'all active VIP watchlist sessions' from the dispatch platform. It distinguishes itself from siblings like dispatch_watchlist_add and dispatch_watchlist_remove.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Examples provide implicit usage guidance (e.g., 'What's on the watchlist?' and 'Is KLM651 being tracked?'). It explains the watchlist purpose and alerts, but lacks explicit when-not-to-use or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral details beyond annotations: requires token/env var, returns internal queue state, container status, error counts, and error string on failure. Annotations already mark readOnly, non-destructive, idempotent—description aligns and expands.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, but the example is somewhat redundant (calling becomes clear from the purpose). The Returns section is informative. Slight room for tightening without loss.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and an output schema present, the description covers all essential context: token requirement, what the tool returns, and error conditions. It is complete for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so baseline is 4. The description mentions the token requirement (env var, not a parameter) and does not need to add schema info. No parameter explanation is necessary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get extended admin health check for the dispatch platform', using a specific verb and resource. It distinguishes itself from the public /healthz endpoint and sibling tools like dispatch_health_check, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions the token requirement and contrasts with public health check. It provides a usage example. However, it does not explicitly state when not to use it or list alternatives among siblings, missing a chance for complete guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it explains the purpose (CPS recomputation), auth requirements (DISPATCH_TOKEN), return format (JSON state/score or error), and includes an example. Annotations already indicate idempotency and non-destructive nature, and the description aligns without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences) and front-loaded with the core action. Each sentence serves a purpose: purpose, context, auth, return format, and example. No unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and a simple action, the description fully covers what the tool does, when to use it, prerequisites, return type, and example. It is complete enough for an agent to understand and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so schema coverage is 100%. The description does not need to elaborate on parameters; baseline is 4 per rules for zero-param tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool forces immediate recomputation of CPS, a specific verb and resource. It distinguishes from siblings like dispatch_get_cps (read) and dispatch_admin_refresh_feed (feed refresh) by focusing on the CPS recomputation action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (e.g., after a manual feed refresh to trigger immediate recomputation) and notes the required env var. It does not explicitly exclude scenarios but provides clear context and an example.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations: it states the log is append-only, never leaves the Pi, and requires a token. It also describes the return format (JSON list with timestamp, action, detail). Annotations already indicate readOnlyHint and idempotence, and the description aligns without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, using bullet points and an example. Every sentence adds value: purpose, behavioral context, requirement, return type, and usage example. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and the presence of an output schema, the description sufficiently covers the tool's behavior and return format. It includes an example and clarifies the token requirement, making it complete for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (0 params), so schema coverage is 100%. The description does not need to add parameter info. It mentions the token requirement, which is an environmental variable, adding value. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the dispatch audit log, an append-only log with 90-day retention. The verb 'Get' and resource 'audit log' are specific and unambiguous. Among sibling tools, none are similar, so it is well-distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions the requirement for the DISPATCH_TOKEN env var, which is a usage guideline. It also explains the log's nature (append-only, retention). While it doesn't explicitly contrast with alternatives, the tool's uniqueness makes it clear when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, openWorldHint. The description adds significant behavioral detail: explains CPS computation from six factors, final states (GO/CAUTION/NO-GO), and return structure with nested factor objects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise yet informative: clear header, bulleted factors, return type description, and two relevant examples. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully describes the tool's purpose, computation, return structure, and example use cases. Given no parameters and supportive annotations, nothing is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (0 params, schema coverage 100%), so baseline is 4. Description adds no parameter info, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb and resource: 'Get the current Critical Predictability State (CPS) — the HEMS go/no-go score.' It specifies the purpose (HEMS go/no-go) and distinguishes from sibling tools by focusing uniquely on CPS.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes usage examples (e.g., 'Is it a go for HEMS operations?' and 'What's limiting the CPS score?') that clarify when to use the tool. However, it lacks explicit statements about when not to use or alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. Description adds details on return format (JSON with status and per-feed freshness) and potential error string, which goes beyond annotations but is not extensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at 4 sentences plus examples, front-loaded with purpose, usage, return format, and examples. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a health check tool with no parameters and annotations present, the description covers purpose, usage, and output format completely. It also provides example queries.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0 parameters, so description does not need to explain parameter details. It correctly implies no arguments needed. Baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'check' and the resource 'health of the CS Executive Services dispatch platform'. It distinguishes from sibling tools which perform specific data retrieval or admin actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use this tool first to verify platform reachability before querying individual feeds, providing clear usage context and examples of when to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. The description adds context beyond annotations: it discloses that the tool returns 'pipe-delimited aircraft state line with full telemetry' or 'No aircraft found' for edge cases. It also mentions the reliability advantage, which helps the agent understand behavior. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise: a clear first sentence, followed by usage context, then structured Args and Returns sections, and concrete examples. Every sentence adds value; no redundancy. The overall length is appropriate for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a single parameter, an output schema, and good annotations, the description covers all necessary aspects: purpose, when to use, parameter details, return format, and edge cases. It also references the related tool flight_get_by_registration, aiding the agent in understanding the workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the hex parameter in detail: format (6 uppercase hex), examples, and its reliability (airframe-bound). While the input schema also includes similar text, the description reinforces and adds the context of bypassing privacy filters. The 'Args' section clearly maps to the required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get current ADS-B position for an aircraft by confirmed ICAO 24-bit hex address.' It specifies the verb (get), resource (position), and identifier (hex). It also distinguishes from sibling tools by emphasizing hex reliability over callsign-based methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use this for all position polls once hex has been confirmed via flight_get_by_registration.' It explains when to use (after confirmation) and why (bypasses filters, avoids stale associations), effectively directing the agent away from alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate write operation (readOnlyHint=false) and description confirms creation of new session. Adds behavioral context: 'dispatch poller will send ntfy push alerts for tracked events.' No contradictions 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured: brief overview, parameter details, return format, and practical examples. No wasted words; each sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all aspects: purpose, parameters, return value, and integration with other tools. With annotations and output schema likely available, the description fully equips the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite schema description coverage reported as 0%, the description adds substantial context: explains hex requirement for flight sessions, mentions destination_icao, and gives examples of valid values (e.g., 'KIAD'), complementing the schema's minimal property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a subject to the VIP watchlist for automated dispatch monitoring' and explains it creates a new watchlist session. It differentiates from sibling tools like dispatch_watchlist_get and dispatch_watchlist_remove.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use: 'For flight tracking, provide the confirmed ICAO hex address' and directs to alternative tools (flight_get_by_callsign, flight_get_by_registration) for resolving hex. Includes example usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description discloses that callsign-to-hex mapping can be stale, the data source (airplanes.live), the return format (pipe-delimited string), and possible error messages. This adds significant behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for warning, args, returns, and examples. It is front-loaded with the primary purpose. While it could be slightly more concise, the information density is appropriate, and the structure aids readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, no enums, output schema present), the description covers all necessary aspects: purpose, usage guidance, return format, and examples. It also addresses potential pitfalls (stale mapping). The presence of an output schema reduces the burden, but the description still provides complete contextual information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the 'callsign' parameter with normalization examples. The tool description adds value by reiterating normalization rules in a different format and providing usage context (e.g., warning about staleness). However, the schema description is already quite comprehensive, so the added value is moderate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get current ADS-B position for a flight by ICAO callsign via airplanes.live', which specifies the verb, resource, and data source. It distinguishes from sibling tools like flight_get_by_hex and flight_get_by_registration by focusing on callsign lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a warning about stale hex mapping and explicitly advises verifying with flight_get_by_registration. It provides normalization rules for airline codes (e.g., KL->KLM) and explains when to use the tool versus alternatives. This offers clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![corporatetravel-dispatch-mcp MCP server](https://glama.ai/mcp/servers/CorporateTravelDC/corporatetravel-dispatch-mcp/badges/card.svg)](https://glama.ai/mcp/servers/CorporateTravelDC/corporatetravel-dispatch-mcp)

Score Badge

Copy to your README.md:

[![corporatetravel-dispatch-mcp MCP server](https://glama.ai/mcp/servers/CorporateTravelDC/corporatetravel-dispatch-mcp/badges/score.svg)](https://glama.ai/mcp/servers/CorporateTravelDC/corporatetravel-dispatch-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/CorporateTravelDC/corporatetravel-dispatch-mcp'

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