MWAA MCP Server
Server Quality Checklist
This repository includes a README.md file.
Add a LICENSE file by following GitHub's guide.
MCP servers without a LICENSE cannot be installed.
Latest release: v0.1.0
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.
- This server provides 21 tools. View schema
No known security issues or vulnerabilities reported.
Are you the author?
Add related servers to improve discoverability.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While it mentions the return type ('Dictionary containing task instance details'), it lacks critical behavioral context such as read-only safety, error handling (404 vs 500), authentication requirements, or what specific details are included in the response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses a structured Args/Returns format that is clear and front-loaded with the purpose statement. While this docstring style is slightly verbose for MCP conventions (repeating parameter names already in the schema), each section earns its place and there is no redundant prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 0% schema coverage and lack of annotations, the description provides the bare minimum for a 4-parameter retrieval tool. It acknowledges the output format but misses critical contextual information such as entity relationships, error scenarios, or architectural context (that this queries Amazon MWAA specifically).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides minimal compensation: it identifies 'environment_name' as the MWAA environment but offers tautological descriptions for the other three parameters ('The DAG ID', etc.). It fails to explain the relationship between DAG runs and task instances or clarify that these IDs likely need to be obtained from prior API calls.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence clearly states 'Get details about a specific task instance,' providing a specific verb and resource. It implicitly distinguishes from the sibling tool 'list_task_instances' by emphasizing 'specific,' though it doesn't explicitly clarify when to use this versus 'get_task_logs' or other retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'list_task_instances' or 'get_task_logs'. It fails to mention prerequisite steps (e.g., needing to obtain dag_run_id from elsewhere) or error conditions when the task instance doesn't exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. While 'Get' implies read-only behavior, the description does not confirm idempotency, disclose log retention limits, truncation behavior, or whether multiple calls are needed for streaming logs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
Follows docstring structure with front-loaded purpose, but contains inefficient repetition in Args ('The X ID' patterns). The Returns section is appropriately terse given the existence of an output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a log retrieval tool with 5 parameters, though it misses Airflow-specific context (e.g., DAG execution flow) and log availability constraints. The output schema absolves the description from detailing return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates via an Args block. 'environment_name' notes the MWAA context, but 'dag_id', 'dag_run_id', and 'task_id' are documented tautologically ('The DAG ID'). 'task_try_number' notes optionality, providing minimal value beyond the schema's null default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Get' with resource 'logs' and scope 'specific task instance'. However, it does not explicitly distinguish from the sibling tool 'get_task_instance' (which likely retrieves metadata/status rather than logs), though the mention of 'logs' does imply a distinct purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives like 'get_task_instance', nor does it mention prerequisites (e.g., task must be started/running to have logs).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions return type ('Dictionary with deletion confirmation') but fails to disclose critical behavioral traits: that deletion is permanent/irreversible, may take time, requires the environment to exist, or what happens to dependent resources. For an infrastructure destruction tool, this is a significant safety gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
Uses docstring-style Args/Returns formatting which is somewhat redundant with MCP's structured schema/output definitions. The content is concise but the structure splits information awkwardly between description text and schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has output schema (not shown but indicated in context), so minimal return value description is acceptable. However, for a destructive infrastructure operation, the description lacks critical contextual warnings about permanent data loss and should explicitly state confirmation is required or that the operation is final.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage (name property has no description). The Args section compensates by documenting 'name: The name of the environment to delete', which adds necessary semantics. Could enhance by noting format constraints or that this refers to the EnvironmentName (not ARN).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb (Delete) and resource (MWAA environment), distinguishing it from sibling tools like create_environment, update_environment, and get_environment. However, it could explicitly clarify that this permanently removes the resource versus updating it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this versus update_environment, or prerequisites like ensuring no active DAG runs exist. No warnings about irreversibility or sync vs async behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full disclosure burden. While 'trigger' implies mutation, it fails to specify if the call waits for completion, what happens if the DAG is paused, potential failure modes, or required IAM permissions. The Returns section mentions output format but output schema exists separately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
Uses structured Args/Returns sections which aids readability, but the Returns section is redundant given the output schema exists. The opening sentence 'Trigger a new DAG run' is appropriately concise but minimal given the lack of behavioral annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, the description appropriately avoids detailing return values (though it repeats them). However, for a 5-parameter execution tool with zero annotations, it lacks critical operational context: side effects, prerequisites, and execution semantics that would guide safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, requiring the description to compensate fully. The Args section documents all 5 parameters, including helpful details like dag_run_id auto-generation behavior and optional flags. However, 'conf' lacks detail on expected JSON structure beyond 'Configuration JSON'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Trigger a new DAG run' with specific verb (trigger) and resource (DAG run). It implicitly distinguishes from sibling tools like get_dag_run (retrieve existing) and list_dag_runs (list multiple), though it could explicitly clarify this initiates execution versus monitoring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus alternatives, prerequisites (e.g., DAG must exist), or preconditions to check (e.g., checking DAG is not paused via get_dag). No mention of synchronous vs asynchronous behavior or polling strategies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but lacks critical behavioral details: whether creation is asynchronous (typical for MWAA), idempotency behavior (error if exists vs. update), required IAM permissions, or provisioning timeouts. Only the return value shape is documented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Uses standard docstring format (Args/Returns) appropriate for the parameter density. Minor inefficiency with tautological entries like 'name: Environment name', but generally information-dense given the need to compensate for the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Acceptable for basic invocation given the Returns section covers output, but incomplete for an infrastructure tool—missing operational context like prerequisite resource states, cost implications, and provisioning duration. Sufficient for constructing a valid request but not for operational success.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given 0% schema description coverage across 18 parameters, the description provides essential semantic compensation—examples (s3://bucket/dags), valid ranges (1-25 workers, 2-5 schedulers), and enum values (PUBLIC_ONLY/PRIVATE_ONLY). Minor gaps exist for complex nested objects like `logging_configuration` and `airflow_configuration_options`.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create a new MWAA environment' providing a clear verb and resource. However, it fails to distinguish from the sibling `update_environment` or explain when creation is preferred over updating an existing environment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus `update_environment` or prerequisites (e.g., IAM permissions, existing VPC). The Args section lists parameters but doesn't provide decision criteria for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the return format (Dictionary with state/timing), but this is redundant given the tool has an output schema. Critically, it omits error behavior (what happens if the DAG run doesn't exist?), authentication requirements, and does not explicitly confirm the read-only nature of the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear Args and Returns sections. Front-loaded with the core purpose. Slightly tautological param descriptions ('The DAG ID') but overall compact and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for basic usage: documents all required params (necessary due to 0% schema coverage) and mentions return content. However, given the lack of annotations, it should disclose error handling and authorization needs, which are missing. Also lacks explicit differentiation from sibling list/trigger tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage. The Args section in the description compensates by documenting all 3 parameters (environment_name, dag_id, dag_run_id), providing at least minimal semantic context for each (e.g., 'Name of the MWAA environment').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb 'Get' and resource 'DAG run', and uses 'specific' to implicitly distinguish from the sibling tool 'list_dag_runs'. However, it does not explicitly contrast with siblings like 'trigger_dag_run' or name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus 'list_dag_runs' (which retrieves multiple runs) or what prerequisites are needed (e.g., knowing the specific dag_run_id). No explicit when/when-not guidance is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, yet description provides minimal behavioral context beyond the Returns clause stating response format. Omits authentication requirements, rate limits, and what constitutes a valid environment_name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Uses structured Google-style docstring format (Args/Returns) that front-loads the purpose statement. Appropriate length given the need to document parameters that the schema leaves undocumented.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a listing tool with existing output schema, but gaps remain in behavioral disclosure (error handling, pagination behavior) thatannotations would typically cover.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Excellent compensation for 0% schema coverage: Args section documents all 3 parameters (environment_name, limit, offset) with clear semantics including MWAA context for the environment parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List all Airflow variables' with specific verb and resource. Distinguishes from siblings (list_dags, list_connections) by specifying 'Airflow variables,' though MWAA context is buried in parameter descriptions rather than the main statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus siblings, no pagination best practices for limit/offset parameters, and no mention of error conditions (e.g., invalid environment_name).
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It provides partial value by documenting the return type ('Dictionary containing list of import errors'), but fails to disclose safety properties (read-only nature), side effects, rate limits, or error handling behavior when the environment_name is invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The docstring format with Args/Returns sections is structured and readable, but somewhat verbose for an MCP description. The first sentence efficiently captures the purpose, but the subsequent sections, while informative, duplicate information that ideally would live in the schema (if coverage weren't 0%).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter retrieval tool with an output schema, the description provides minimally viable coverage. It documents the parameters and return structure, but given the complete absence of annotations and the importance of import errors in troubleshooting, it should disclose whether this retrieves real-time data or cached errors, and any limitations on historical error availability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given 0% schema description coverage, the Args section successfully compensates by adding semantic meaning to all three parameters: defining environment_name as the 'MWAA environment', limit as 'Number of items to return', and offset as 'Number of items to skip'. However, it omits that limit and offset are optional with default values (100 and 0 respectively), which is critical pagination context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (Get) and resource (DAG import errors), defining the scope to a specific environment. However, it lacks differentiation from sibling tools like `get_dag` or `get_environment`, which also retrieve information about DAGs/Environments, leaving ambiguity about when to choose this specific diagnostic tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., that the environment must exist) or when a user should check import errors versus triggering a DAG run or inspecting task logs. The Args section documents parameters but does not advise on tool selection.
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?
No annotations provided, so description carries full burden. It discloses the return structure (dictionary with schedule, tags, state) and MWAA context via parameter docs. However, lacks critical behavioral details like error handling (what happens if dag_id doesn't exist), permissions required, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Uses structured docstring format (Args/Returns) that is appropriately sized and scannable. Each section earns its place by conveying essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Reasonably complete for a simple 2-parameter read operation: documents parameters and return values. However, given zero annotations and lack of output schema visibility in the description, it could benefit from mentioning error cases (e.g., DAG not found) or MWAA-specific constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. The Args section compensates by providing clear semantic meaning for both parameters: 'environment_name' is identified as 'Name of the MWAA environment' and 'dag_id' as 'The DAG ID', giving agents necessary context to provide correct values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
States specific action ('Get') and resource ('details about a specific DAG'), implicitly distinguishing from sibling 'list_dags' which retrieves multiple DAGs. The Returns section clarifies specific details retrieved (schedule, tags, state).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'list_dags' or 'get_dag_run'. No mention of prerequisites (e.g., environment must exist) or error conditions.
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?
No annotations are provided, so description carries full burden. It discloses return value structure (dictionary with configuration, status, endpoints) which is helpful, but omits error behavior, permissions required, or what happens if the environment is not found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Uses structured docstring format with clear Args and Returns sections. Information is front-loaded and efficient. No redundant sentences, though Returns section partially duplicates unseen output schema it provides useful field hints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple single-parameter read operation with existing output schema, but gaps remain: zero schema coverage necessitates more detailed parameter documentation (e.g., validation patterns), and error conditions are not described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, requiring description compensation. The Args section documents the 'name' parameter as 'The name of the MWAA environment', providing basic semantics. Does not elaborate on format constraints (ARN vs simple name) but covers the essential meaning of the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb 'Get' with resource 'MWAA environment' and scope 'detailed information'. Use of 'specific' implies single-resource retrieval, distinguishing from sibling 'list_environments', though it does not explicitly name the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no explicit guidance on when to use this tool versus 'list_environments' or prerequisites (e.g., that the environment must exist). The word 'specific' only implies usage context rather than stating it clearly.
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?
With no annotations provided, the description carries the full disclosure burden. It usefully documents the return values (web token, hostname, IAM identity) but omits critical behavioral context such as token expiration time, whether previous tokens are invalidated, or required IAM permissions to invoke this operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Uses a standard Args/Returns docstring format that is structured and efficient. The information density is high with no redundant sentences, though the formal structure is slightly verbose compared to prose descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter mutation tool with a documented return structure (satisfying the output schema presence), the description is adequately complete. It identifies the domain (MWAA via the Args description) and explains the return dictionary contents sufficiently for invocation decisions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage (just type: string), so the description compensates by specifying that the 'name' parameter refers to 'The name of the MWAA environment'. This adds essential semantic context that the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific action (Create) and resource (web login token) along with the target system (Airflow UI). However, it does not explicitly distinguish this from the sibling tool `create_cli_token`, leaving ambiguity about which token type to use for different access patterns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the sibling `create_cli_token`, nor are there prerequisites mentioned (e.g., requiring an existing environment). The description only states what the tool does, not when to choose it over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states return type (Dictionary with list) but lacks critical behavioral context: no mention of read-only safety, pagination behavior implications, rate limits, or whether connections contain sensitive credentials that require special handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Docstring structure (Args/Returns) is logical and front-loads the purpose sentence. Some redundancy exists between Args section and required schema fields, but given zero schema coverage, this repetition is necessary rather than wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Acknowledges output exists ('Returns: Dictionary...') which aligns with having output schema, but fails to explain what constitutes an 'Airflow connection' (credentials, hooks, URIs) which would help an agent evaluate relevance. Adequate but incomplete for a 3-parameter resource listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by documenting all 3 parameters in the Args section (environment_name scope, limit/offset pagination semantics). However, it omits format constraints, valid ranges, or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States specific action 'List' and resource 'Airflow connections', clearly distinguishing from sibling tools like list_dags, list_variables, and list_environments. The scope 'in the environment' ties it to the MWAA context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus siblings (e.g., when to list connections vs. get_environment or list_variables). No mention of prerequisites, permissions, or workflow context.
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?
With no annotations provided, the description carries the full burden. It lists six content areas covered (DAG patterns, performance, security, etc.) providing scope transparency, but lacks operational details such as data source, caching behavior, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with a clear first sentence stating purpose, followed by a structured bulleted list of topic areas. No extraneous information is included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero input parameters and the existence of an output schema, the description adequately covers the tool's scope by enumerating specific best practice domains. It appropriately avoids duplicating return value documentation that belongs in the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters, which per guidelines warrants a baseline score of 4. The schema confirms this with an empty properties object and additionalProperties: false.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'MWAA and Apache Airflow best practices guidance' and enumerates specific content domains. However, it does not explicitly differentiate from the sibling tool 'dag_design_guidance' despite overlapping content (DAG design patterns).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this comprehensive best practices tool versus the specific 'dag_design_guidance' sibling, nor are prerequisites or exclusions mentioned.
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?
No annotations provided, so description carries full burden. Mentions 'Returns expert guidance' indicating read-only nature, but lacks details on whether guidance is static/dynamic, cached, or any rate limits. Adequate but minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded purpose statement followed by bulleted list of specific guidance topics. No redundant text. Each sentence earns its place by defining scope or output content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for a zero-parameter tool with output schema. Description adequately summarizes output content (guidance topics) without needing to duplicate full schema definitions. Could improve by mentioning this requires no inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters present per schema (empty object with additionalProperties: false). Per rubric, 0 params = baseline 4. Schema requires no additional semantic explanation in description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
States clear verb+resource ('Get detailed guidance on designing efficient Airflow DAGs') and distinguishes from operational siblings like get_dag or create_environment via specific topic coverage (XCom, Sensors, etc.). However, does not explicitly differentiate from sibling 'airflow_best_practices' which may overlap in scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Lists output topics but provides no guidance on when to use this tool versus 'airflow_best_practices' or other alternatives. No mention of prerequisites or when NOT to use (e.g., when seeking actual DAG code vs design guidance).
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It partially succeeds by documenting filtering capabilities (state values, date range boundaries, limit), but fails to mention pagination behavior, sorting order, required IAM permissions, or error conditions (e.g., invalid DAG ID).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The Google-style docstring format (Args/Returns) is well-structured and front-loaded with the primary purpose. The Returns section is appropriately brief given the existence of an output schema, though the description overall is slightly verbose with redundant 'Filter by' prefixes for date parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description adequately covers all input parameters with their formats and constraints. It sufficiently describes the operation for a filtered list query, though it could improve by mentioning pagination continuation tokens or default sorting behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Excellent compensation for 0% schema description coverage. The Args section documents all 6 parameters with clear semantics, including enumerating valid state values (queued, running, success, failed) and specifying the ISO format requirement for date parameters—critical details absent from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'List[s] DAG runs for a specific DAG' using a specific verb and resource. However, it does not explicitly differentiate from sibling tool `get_dag_run` (which retrieves a single run), leaving mild ambiguity about when to use the list operation versus the singular get operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like `get_dag_run` or `trigger_dag_run`, nor does it mention prerequisites such as requiring an existing DAG or specific permissions. It simply states what the tool does, not when to choose it.
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?
With no annotations provided, the description carries the full burden. It discloses the return structure (Dictionary with DAG details) and pagination model (limit/offset), but omits safety/disdestructive traits, error behaviors, or authentication requirements that annotations would typically cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The Args/Returns structure is appropriate for the 6-parameter complexity and zero schema coverage, though the Returns section is slightly redundant given the output schema exists. No sentences are wasted, but the docstring format is more verbose than a prose description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 6 parameters with zero schema coverage, the description provides sufficient detail by documenting each parameter and the return type. The existence of an output schema excuses the minimal return value description, though sibling differentiation is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the Args section fully compensates by documenting all 6 parameters with precise semantics, including critical constraints like 'max 100' for limit and '% wildcards' for dag_id_pattern that are absent from the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb (List) and resource (DAGs) with scope (MWAA environment). However, it does not distinguish from the sibling tool 'get_dag' (which retrieves a single DAG), leaving the agent to infer the list vs. single-item distinction from the tool names alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_dag' for single DAG retrieval, nor does it mention prerequisites or exclusion criteria for the filters.
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?
Without annotations, the description must carry the full burden. It discloses the return type ('Dictionary containing the DAG source code'), but omits critical behavioral details such as authentication requirements, rate limits, or whether the source code is returned as a string or file object.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The docstring-style structure with Args and Returns sections is appropriate and well-organized. Each sentence earns its place without excessive verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple 2-parameter input and presence of a Returns section, the description is sufficiently complete for a read-only operation, though mentioning MWAA context earlier and error scenarios would improve it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section compensates for the 0% schema description coverage by providing semantic meaning for both parameters ('Name of the MWAA environment', 'The DAG ID'), though it could further clarify formatting constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('source code of a DAG'), clearly distinguishing it from the sibling 'get_dag' tool which likely returns metadata rather than actual code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_dag', nor does it mention prerequisites such as requiring DAG deployment or specific permissions.
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?
Explains the partial update pattern well, but with no annotations provided, it omits operational details critical for AWS mutations: permissions required (IAM), whether the update is atomic, potential downtime for Airflow environments, or if the operation is async/sync.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with purpose front-loaded, followed by usage constraint, Args block, and Returns. The Args block is necessarily lengthy given zero schema descriptions, but earns its place by providing essential parameter semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Acknowledges the return value (environment ARN) which aligns with the existing output schema. However, for a complex 17-parameter AWS mutation tool, it lacks discussion of idempotency, update propagation delays, or validation behavior that would help an agent handle errors or retries.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by documenting all 16 optional parameters with concise semantic meanings (e.g., 'VPC configuration', 'Path to requirements.txt'). This successfully fills the schema gap, though it lacks format constraints or valid value ranges.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
States specific action ('Update') and resource ('MWAA environment configuration'). The word 'existing' implicitly distinguishes it from the sibling 'create_environment', though it could explicitly contrast with creation/deletion siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Only provide the parameters you want to change' provides crucial behavioral guidance for partial updates, indicating PATCH-like semantics. However, it lacks explicit guidance on when to choose this over 'create_environment' or 'delete_environment'.
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?
No annotations provided, so description carries full burden. Documents return value structure (Dictionary with token and hostname), but omits critical behavioral details: token expiration/TTL, required IAM permissions, and whether creation invalidates previous tokens.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Docstring format with Args/Returns sections is efficient and well-structured. Every clause earns its place; front-loaded purpose followed by input/output specifications.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a single-parameter tool with documented returns, but incomplete regarding sibling differentiation (create_web_login_token) and token lifecycle management details expected for a credential-generation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no parameter descriptions), but description compensates by documenting 'name' as 'The name of the MWAA environment', adding crucial domain context (MWAA) absent from the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Create' with clear resource 'CLI token' and purpose 'for executing Airflow CLI commands'. Explicitly distinguishes from sibling 'create_web_login_token' by specifying 'CLI token' versus web login.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage context (when you need CLI access), but lacks explicit 'when to use vs alternatives' guidance. Does not reference sibling 'create_web_login_token' to clarify selection criteria.
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?
No annotations provided, so description carries full burden. Adds AWS-specific context ('current AWS account and region') and return type structure. However, omits pagination continuation behavior, API rate limits, credential requirements, or whether results are cached/live.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Uses structured Args/Returns format effectively. First sentence clearly states purpose. Slightly redundant to include Returns section when output schema exists, but necessary given overall schema coverage gaps. No filler words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for a single-parameter list operation. Covers resource scope, pagination limit constraints, and return structure. Missing only AWS-specific behavioral details (pagination tokens, throttling). Acceptable given output schema exists to document return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description compensates fully by documenting max_results with validation range (1-25) and semantics ('Maximum number of environments to return'), providing critical constraints absent from the JSON schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb ('List') + resource ('MWAA environments') + scope ('current AWS account and region'). Clearly distinguishes from sibling 'get_environment' (single) and mutation tools like 'create_environment'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives mentioned. While naming convention implies enumeration vs. retrieval, lacks guidance like 'use this to discover environments before calling get_environment' or pagination behavior when results exceed max_results.
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?
No annotations provided, so description carries full burden. Explains wildcard query behavior (omitting params queries across all DAGs/runs) and time-filtering logic. Missing safety/performance warnings about expensive cross-DAG queries, but clear on pagination and defaults.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with purpose front-loaded, followed by Args, Returns, and Example. Args section is repetitive but necessary given zero schema coverage. Concrete example with inline comments adds value without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Excellent coverage for complex query tool: purpose, wildcards, all 16 parameters, return type (briefly acceptable since output schema exists), and working example. Complete despite no annotations and zero schema descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the Args section comprehensively documents all 16 parameters including semantics (e.g., 'Filter by DAG ID (optional - omit for all DAGs)') and format hints ('ISO format'). Fully compensates for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb 'List' with resource 'task instances across DAGs' and key capability 'flexible time-based filtering'. Distinguishes from sibling 'get_task_instance' by emphasizing plural listing and cross-DAG queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly states 'key tool for finding what tasks were running during a specific time window' and explains wildcard behavior (omit dag_id/dag_run_id to query across all). Includes concrete code example. Lacks explicit 'when not to use' or named sibling alternatives.
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:
Score Badge
Copy to your README.md:
How to claim the server?
If you are the author of the server, you simply need to authenticate using GitHub.
However, if the MCP server belongs to an organization, you need to first add glama.json to the root of your repository.
{
"$schema": "https://glama.ai/mcp/schemas/server.json",
"maintainers": [
"your-github-username"
]
}Then, authenticate using GitHub.
Browse examples.
How to make a release?
A "release" on Glama is not the same as a GitHub release. To create a Glama release:
- Claim the server if you haven't already.
- Go to the Dockerfile admin page, configure the build spec, and click Deploy.
- Once the build test succeeds, click Make Release, enter a version, and publish.
This process allows Glama to run security checks on your server and enables users to deploy it.
How to add a LICENSE?
Please follow the instructions in the GitHub documentation.
Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear on the server after some time, you can manually trigger a new scan using the MCP server admin interface.
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.
Latest Blog Posts
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/paschmaria/mwaa-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server