metaflow-mcp-server

by npow

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.5.0
Disambiguation5/5
Each tool has a clearly distinct purpose, from run management (get_run, run_flow, resume_run) to artifact handling (get_artifact, list_artifacts, search_artifacts) to comparisons (diff_runs, compare_cards). There is no ambiguity between similar-sounding tools like get_recent_runs and search_runs, as their descriptions clarify different scopes and filters.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., add_run_tags, get_config, list_flows). Even compound names like get_latest_failure or get_triggered_run_status adhere to the pattern. No mixing of conventions (camelCase or other styles) is present.
Tool Count4/5
With 24 tools, the set is slightly above the typical well-scoped range (3-15) but remains justified for the Metaflow domain, which involves many distinct operations (runs, artifacts, cards, deployments, tags, etc.). The count is not excessive given the platform's complexity.
Completeness4/5
The tool surface covers most core workflows: running flows (locally and triggered), monitoring, fetching artifacts and logs, comparing runs, managing tags, and viewing cards and deployments. Minor gaps exist, such as no explicit tool to abort a locally run flow (only triggered runs) and no tool to delete runs or artifacts, but these do not severely hinder typical agent tasks.
Average 4.3/5 across 24 of 24 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on May 11, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose any behavioral traits beyond basic action. Output schema exists but description itself lacks transparency about read-only nature, failure modes, or return format.
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?
Description is short and to the point, but includes an 'Args:' section that could be integrated more concisely. Efficient overall.
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 output schema exists, description does not need to explain return values. It addresses both parameters and purpose, but could mention that the artifact value is the return.
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 0% schema coverage, description adds clear meaning to both parameters with examples: pathspec format and artifact name examples, fully compensating for schema gaps.
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?
Description clearly states 'Get the value of a data artifact from a task' with specific verb and resource, and distinguishes from sibling tools like list_artifacts and search_artifacts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like list_artifacts or search_artifacts. No exclusions or contextual cues provided.
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 the description carries the full burden. It discloses the return values and hints at usage, but does not mention any behavioral traits such as authentication, rate limits, or side effects. For a simple read-only tool, this is adequate but could be more informative.
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 three sentences that front-load the purpose, then list returned values, and finally give a usage hint. Every sentence adds value without redundancy or waste.
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 an output schema and zero parameters, the description adequately covers the return values and usage context. It is complete for a configuration retrieval 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, and schema coverage is 100%. The description does not need to add parameter info; it correctly focuses on the tool's purpose and output. Baseline score for zero parameters is appropriate.
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 the tool shows current Metaflow configuration and lists specific return fields like metadata provider, datastore, namespace, and profile. It is distinct from siblings like get_environment and get_run, though no explicit differentiation is given.
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 advises using this tool first to understand the backend, and explains how the returned namespace can be passed to other tools. It provides clear context for usage but does not mention when not to use it or compare to alternatives.
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 details behavior for different pathspec levels (run, step, task) but lacks information on side effects, permissions, rate limits, or what happens when no cards exist.
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 with a concise main sentence, followed by a bulleted explanation of pathspec levels and a clean Args list. Every sentence adds value; no fluff.
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?
Covers input parameters and usage behavior. Since an output schema exists, the description does not need to explain return values. Slightly missing explicit mention of output format, but output schema fills that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It provides brief parameter descriptions (e.g., 'Only list cards of this type') but adds only basic meaning beyond the schema titles. Does not elaborate on format or constraints.
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 'List cards attached to a run, step, or task' and differentiates from sibling 'get_card' by explaining this discovers cards before retrieval. The verb and resource are specific and the scope is well-defined.
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?
Explicitly says 'Use this to discover available cards before retrieving them with get_card,' providing clear usage context. However, no explicit when-not-to-use or alternative tools beyond get_card are 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?
Describes that it creates an HTML page and returns it, and that text summaries are returned. Lacks details on side effects, prerequisites (cards must exist), or error handling, but sufficient given no 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?
Well-structured with bullet points and code examples. Slightly lengthy but all info is relevant. Front-loaded with main purpose.
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?
Explains functionality, parameters, and return value adequately for a comparison tool. Lacks error cases or limitations, but overall complete given no annotations and good schema coverage via description.
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?
Adds significant meaning beyond schema: explains how run_ids resolve to pathspecs, default card_index, and filtering by type/id. Schema had no descriptions, so description compensates well.
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?
Description clearly states the tool compares Metaflow cards across runs side by side, creates an HTML page, and returns text summaries. It distinguishes from siblings like get_card and diff_runs by focusing on comparison.
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 two clear methods (pathspecs or flow+step+run_ids) with examples. Does not explicitly compare to siblings, but usage context is well explained.
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 burden. It warns about multi-megabyte HTML but does not state that the operation is read-only, require any permissions, or disclose side effects. Missing critical behavioral context for a tool with no 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 efficiently structured: front-loaded purpose, then return type, then usage guidance, then param details. Every sentence adds value with no redundancy. The bullet list is clear.
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 that an output schema exists, the description covers the main return types (text or HTML) and warnings about large payloads. It lacks error handling or card-not-found scenarios, but overall it is complete for typical use.
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?
Schema coverage is 0%, but the description fully compensates by listing all 5 parameters with explanations of their purpose, defaults, and when to use include_html. It adds significant meaning beyond the schema's type information.
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 a Metaflow card's content' and explains the default return type (text). It distinguishes from the sibling tool list_cards by mentioning discovery first. The verb+resource is specific.
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 explicit context: 'Use list_cards first to discover available cards' and advises when to use include_html (only when saving to a file). It lacks explicit when-not-to-use scenarios for other siblings like compare_cards, but the guidance is clear for typical usage.
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 that only Deployer-deployed flows are listed and supports auto-detection of backend, but omits details on permissions, rate limits, pagination, or safety.
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?
Description is concise with a single sentence summary followed by bullet-pointed parameter explanations. No redundant content; front-loaded with main action.
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 an output schema exists and only two optional parameters, the description covers essential context: what is listed, backend options, and filtering. Could mention if results are sorted or paginated, but overall adequate.
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?
Schema description coverage is 0%, but the description explains both parameters clearly: flow_name filters to a specific flow or all, impl specifies backend or auto-detects. Examples add value beyond the 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 'List Metaflow flows deployed to the configured orchestrator', using a specific verb and resource. It distinguishes from sibling 'list_flows' by specifying the deploy context and backend support.
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 lacks explicit when-to-use or when-not-to-use guidance. It implies it is for flows deployed via Deployer but does not compare with alternatives like 'list_flows' or discuss prerequisites.
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?
With no annotations provided, the description fully explains the tool's behavior: it scans recent runs, finds all failures, and returns details per failure (step/task, exception, stderr). It does not mention side effects or safety, but the behavior is clearly described. A score of 4 is appropriate as it adds value beyond the minimum.
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: two short paragraphs. The first sentence states the purpose, and subsequent lines explain parameters efficiently. No wasted words; every sentence adds information.
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 that an output schema exists (context signals), the description appropriately covers the tool's behavior and return values (failing step/task, exception, stderr). It also explains the scanning scope via last_n_runs and namespace. However, it does not mention edge cases like no failures found or performance implications. Still, it is largely complete for a focused 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?
Schema description coverage is 0%, so the description must compensate. It provides meaningful context for each parameter: explains 'last_n_runs' as number of recent runs to scan (default 20), and 'namespace' with a hint to use get_config. 'flow_name' lacks additional context, but given the coverage gap, the description adds significant 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?
Description clearly states the tool finds failed runs and returns error details, including the failing step/task, exception, and stderr. The verb 'find' and resource 'failed runs' are specific, and it distinguishes from sibling tools like get_recent_runs or search_runs by focusing on failures.
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 implies usage by describing what the tool does but does not explicitly state when to use it versus alternatives or when not to use it. It provides some guidance on the namespace parameter ('Use get_config to find your default_namespace') but lacks a broader usage 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?
No annotations are provided, so the description carries the full burden. It explains the parameters and their sources but does not disclose behavioral traits such as idempotency, side effects, or polling behavior. The description does not contradict any annotations as none exist.
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 with a brief header followed by parameter descriptions. Every line adds value, though a slightly more compact structure could improve front-loading. Overall, it is efficient and well-organized.
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 presence of an output schema (which likely explains return values), the description does not need to cover return structure. It sufficiently explains how to obtain the required parameters. Minor improvements could mention whether the tool is idempotent or read-only, but it remains adequate for the tool's purpose.
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?
Schema description coverage is 0%, so the description must compensate. It adds meaning to all three parameters: identifier is a deployment identifier, run_id is the ID returned by trigger_run, and impl is an orchestrator backend that can be auto-detected. This significantly aids parameter understanding.
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 'Check the status of a previously triggered run', using a specific verb and resource. It distinguishes from sibling tools like trigger_run and get_run by explicitly referencing the trigger context and linking parameters to trigger_run.
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 clear usage guidance by specifying that identifier is the same as passed to trigger_run, run_id is returned by trigger_run, and impl is auto-detected. However, it does not explicitly state when not to use this tool or mention alternatives beyond the implicit connection to trigger_run.
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, description explains asynchronous nature and subprocess execution, but omits error handling, permission details, and potential side effects. Adequate but not comprehensive.
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?
Description is well-structured with a clear main sentence and a separate Args section. Slightly verbose but efficient; front-loads purpose.
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?
Covers all necessary aspects: purpose, usage, parameters, and behavior. With an output schema present, return value details are not required. Missing error handling but sufficient for typical agent use.
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 'Args' section adds detailed meaning to all parameters beyond the schema, including types and usage (e.g., flow_file as path, parameters as overrides). Fully compensates for 0% schema description coverage.
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 'Run a Metaflow flow from a local source file' with a specific verb and resource, distinguishing it from siblings like trigger_run or get_run.
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 context on asynchronous execution and local requirement, and suggests using get_run for monitoring. Lacks explicit alternatives for non-local scenarios, but the local constraint is well-stated.
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 defaults (last_n=5) and filter fields but lacks details on ordering, pagination, or underlying behavior beyond the basic query.
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?
Description uses a clean Args block format with bullet points, is well-organized, concise (no superfluous text), and front-loads the main 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 parameters with helpful details, and since an output schema exists, the description does not need to explain return values. Complete for this tool's complexity.
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?
Schema coverage is 0%, yet description adds detailed semantics for all 7 parameters including examples (e.g., 'MyFlow', ISO format hints, default values), significantly exceeding schema information.
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 uses a specific verb ('Find') and resource ('recent runs of a flow') with clear optional filters. It distinguishes from siblings like get_recent_runs, get_run, and search_artifacts which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states typical usage (find recent runs with filters) but does not provide explicit when-to-use or when-not-to-use guidance relative to alternatives like get_recent_runs or get_run.
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 present, so the description must fully disclose behavior. It correctly indicates a mutation (adding tags), but does not mention idempotency, effect on existing tags, authentication needs, or error conditions. This is adequate but not thorough for a mutation tool.
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 with two short paragraphs plus an Args list. Every sentence adds value, and the most important information (verb, resource, examples) is front-loaded.
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 that an output schema exists, return value details are not needed. The description covers purpose, parameters, and usage context. However, it lacks behavioral details like idempotency or side effects, which would add completeness.
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 input schema has 0% description coverage, but the description's Args section fully explains both parameters: 'pathspec' (format example) and 'tags' (value example). This compensates completely for the schema gap.
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 action ('Add user tags to a Metaflow run') with a specific verb and resource. It explains the utility of tags for filtering, distinguishing it from sibling tools like 'remove_run_tags' and 'search_runs'.
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 tags are useful (marking runs, filtering) but does not explicitly contrast with alternatives like 'remove_run_tags'. However, the purpose is clear enough for an agent to infer 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?
With no annotations, the description adequately discloses behavioral traits: it returns a full list of packages, metadata, and truncation behavior when max_packages is set. It also explains how run pathspecs scan steps. However, it does not mention permissions or potential side effects, but as a read-only tool, this is acceptable.
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 purpose sentence, a summary of return data, and an 'Args:' section. It is slightly verbose but every sentence adds value. The front-loading of the purpose is effective.
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 presence of an output schema (context signal), the description provides sufficient context: it explains the return value and covers all parameters with edge cases (e.g., run pathspec scanning, truncation). It is complete for a tool with four parameters and no annotations.
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?
Schema description coverage is 0%, so the description compensates fully. It explains all four parameters clearly: pathspec format, package_type filtering, package_name substring matching, and max_packages truncation. Each parameter gains significant meaning beyond the bare 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 conda/pypi environment details for a Metaflow task or run. The verb 'Get' and specific resource 'environment details' distinguish it from sibling tools like get_artifact or get_config.
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 does not explicitly provide usage guidelines or compare with sibling tools. It only mentions compatibility with Netflix and OSS Metaflow, which is not guidance on when to use this tool over alternatives. The purpose is narrow enough that usage might be implied, but explicit guidance is lacking.
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 are provided, so the description carries the full burden. It discloses that the action is irreversible and stops the workflow on the orchestrator, which is critical behavioral info for a termination tool.
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 with three short paragraphs: purpose, notable behavior (irreversible), and parameter explanations. It is front-loaded with the key action and contains no unnecessary words.
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 presence of an output schema, the description covers the action, irreversibility, and parameter details. It could mention that only running runs can be terminated, but overall is sufficiently complete.
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 includes an 'Args' section that explains each parameter (identifier, run_id, impl) beyond what the input schema provides (schema description coverage is 0%). This adds significant semantic 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 clearly states the verb 'Terminate' and resource 'running triggered run', with additional context 'Stops the workflow on the orchestrator'. This distinguishes it from sibling tools like trigger_run or resume_run.
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 implies usage for stopping a running run and mentions irreversibility, but does not explicitly state when to use versus alternatives or provide exclusions (e.g., not for already stopped runs).
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. It details diff sections (code, metadata, parameters, environment) but does not discuss side effects or performance; the read-only nature is implied.
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?
Well-structured with clear sections and examples, but slightly longer than necessary; could be more concise without losing clarity.
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 output schema exists, description does not need to detail return values. It covers purpose, parameters, and diff sections completely.
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?
Schema coverage is 0%, but description explains both parameters with format examples and purpose (source_pathspec, target_pathspec), adding value beyond the 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 compares two Metaflow runs, listing specific aspects (source code, parameters, environment, system metadata) and distinguishes from sibling tools like compare_cards.
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 provides usage context (debugging regressions, understanding failures, auditing) but does not explicitly state when not to use or mention alternatives.
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?
No annotations are present, so the description fully discloses behavior. It explains that the tool retrieves logs, which fields (stdout/stderr) can be included, and that tail/head/pattern filters are applied. The description is honest about the head parameter being ignored if tail is set, and there are no contradictions.
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 structured with an initial sentence followed by bulleted parameter descriptions. It is clear and readable, but could be more concise by reducing wordiness in parameter explanations. However, it earns a 4 for efficiency and good structure.
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 an output schema (not shown but present), the description does not need to explain return values. It covers all 6 parameters, their defaults, and special behaviors (e.g., head overridden by tail). For a log retrieval tool with moderate complexity, this is fully complete.
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?
Schema description coverage is 0%, so the description must add meaning. It does so thoroughly: explains pathspec format, defaults for stdout/stderr, the behavior of tail, head (and the interaction between them), and pattern as regex filtering. This is essential semantic information beyond the schema's property names and types.
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 stdout/stderr logs for a specific task. The verb 'Get' and resource 'logs for a specific task' are specific. Among sibling tools, none focus on logs, so it is well differentiated.
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 implies use when logs are needed but does not provide explicit when-to-use or when-not-to-use guidelines. No alternatives are suggested, and the context for using this over other tools is not elaborated.
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?
With no annotations, the description bears full burden. It explains the return content (names, data types, metadata) and implies read-only behavior. It describes pathspec format clearly. But it does not disclose potential side effects, rate limits, authorization needs, or error conditions.
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 short and to the point: four sentences (purpose, return content, guidance to sibling, parameter format). No filler or redundancy. The Args block is a minor repetition but clarifies the parameter. Overall, every sentence earns its place.
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 single parameter, output schema existence, and a clear description of return content and parameter format, the description is largely complete for basic usage. However, it omits potential nuances like pagination, filtering options, or performance notes that could be relevant for a list operation.
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?
Schema coverage is 0% (no parameter descriptions in schema), so the description must compensate. It provides a detailed explanation of the pathspec parameter, including examples for both task and step pathspecs, and the behavior of using the first task for a step. This adds significant meaning beyond the schema's type=string.
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 action ('List') and the resource ('artifacts produced by a task or first task of a step'). It specifies the scope (task or step) and distinguishes from sibling get_artifact (retrieve values) and search_artifacts (search).
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 tells when to use this tool ('List all artifacts') and directs to get_artifact for retrieving values. However, it does not specify when not to use it or contrast with search_artifacts, and lacks prerequisites or context about pagination or limits.
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?
With no annotations, description covers key behaviors: starts new run, reuses results, returns immediately, runs as subprocess. Lacks details on auth, rate limits, or failure handling, but sufficient for core understanding.
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: one-line summary, a paragraph explanation, then Args section. Every sentence adds value, no fluff.
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 output schema existence and 2 parameters, description provides sufficient context: prerequisites, monitoring advice, and parameter examples. Covers essential aspects for effective tool use.
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?
Schema coverage is 0%, and description adds meaning: flow_file is a path, origin_run_id is a run ID with example and suggestion to use get_run or get_latest_failure. Compensates well for missing schema 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?
Clearly states 'Resume a failed Metaflow run from the point of failure.' and explains it starts a new run reusing successful steps and re-executes from failure onward. Distinguishes from siblings like run_flow or get_latest_failure.
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 usage context: requires local filesystem, returns new run ID immediately, and recommends get_run for monitoring. Implicitly suggests use when a run fails, but does not explicitly list when not to use or name alternatives beyond get_run and get_latest_failure.
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. It discloses read-only behavior ('does not load artifact data'), performance considerations, and scoping capability. Lacks details on authorization or rate limits, but these are typical for a read-only search tool.
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: starts with a clear purpose sentence, followed by brief explanation and a note about performance, then an Args section. Every sentence adds value without 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 output schema exists, return values need not be described. Covers all parameters and usage context adequately. Could mention that it returns matching artifacts, but the output schema likely handles that. Sibling differentiation is partially addressed.
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?
Schema description coverage is 0%, but the description explains each parameter's meaning, defaults, and usage (e.g., 'last_n_runs: Number of recent runs to scan (default 5)', 'step_name: Only search within this step (e.g. train)'). This adds significant value beyond the 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 'Search for a named artifact across recent runs of a flow', specifying verb, resource, and scope. It distinguishes from siblings like get_artifact (does not load data) and implicitly from list_artifacts.
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?
Explicitly advises to use get_artifact when data is needed, and suggests using step_name for large flows to improve performance. Could also mention list_artifacts for listing all artifacts, but the provided guidance is clear and actionable.
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 are provided, so the description carries full weight. It discloses that the tool 'scans all flows in the namespace' and 'returns runs sorted by creation time (newest first).' This gives clear behavioral insight beyond the name.
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: one sentence for purpose, one for usage context, and a bulleted list for parameters. It is front-loaded and contains no redundant 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?
Given the tool's 4 parameters and no annotations, the description covers all essential aspects: purpose, when to use, parameter explanations, and sorting behavior. Output schema exists, so return value details are handled externally.
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?
Schema description coverage is 0%, but the description compensates with a detailed 'Args' section explaining each parameter, including defaults, an example for namespace, and valid status values. It also cross-references get_config.
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: 'Find the most recent runs across all flows in a namespace.' It uses a specific verb-resource pair and distinguishes from sibling tools like get_run and search_runs by specifying 'when no specific flow name is given.'
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 says when to use: 'when no specific flow name is given and you need to find what the user ran recently.' It also references get_config for finding the namespace, but does not mention alternative tools like search_runs when a filter is needed.
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?
Describes default behavior (returns every task, potentially huge payload) and the effect of summary=True, disclosing important behavioral traits despite no 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?
Two paragraphs with front-loaded purpose, each sentence adds value with no fluff or repetition.
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 presence of output schema and simple parameters, description covers all necessary context, including edge cases (large payloads) and parameter guidance.
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?
Adds significant meaning beyond the schema: explains pathspec format and summary parameter's purpose, recommended usage, and default value, compensating for 0% schema coverage.
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?
Description clearly states 'Get detailed status of a run including per-step breakdown,' using a specific verb and resource, and distinguishes from siblings like get_recent_runs.
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?
Explicitly recommends using summary=True for foreach-heavy flows to avoid large payloads, guiding the agent for appropriate usage, though lacks explicit when-not-to-use statements.
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 are provided, so the description carries full responsibility. It discloses that the tool returns the main FlowSpec file and file listing without file_path, and the specific file content with file_path. It implies a read-only operation, with no behavioral contradictions.
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 a brief introduction, behavioral details, and an Args section. Every sentence adds value without unnecessary repetition. It is concise yet complete.
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 complexity (two parameters, conditional behavior) and the presence of an output schema, the description provides sufficient context. It covers the main scenarios and parameter usage, 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameter meaning. It does so thoroughly: pathspec is described as a Run or task pathspec with examples, and file_path is explained as optional, with the default behavior of returning the main flow file and listing.
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 the source code from a Metaflow run's code package,' with a specific verb and resource. It distinguishes itself by explaining the two modes of operation (with and without file_path) and lists sibling tools that serve different functions.
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: 'to inspect the exact code that was used in a run.' It provides context about remote runs storing a snapshot. While it does not explicitly list alternatives or when not to use it, the purpose is clear and distinct from sibling 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?
No annotations provided, so description carries full burden. It explains scope behavior (namespace) and defaults for parameters. It does not disclose rate limits or side effects, but being a read-only list operation, transparency is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise paragraphs: first states purpose, second details parameters. Every sentence adds value. No redundancy, efficient and 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 output schema exists, return value explanation is unnecessary. Covers use case, parameter semantics, and prerequisite hint. Complete for a straightforward listing tool.
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?
Schema description coverage is 0% yet the description adds full meaning for all three parameters: last_n (max number, default 50), offset (pagination skip, default 0), namespace (scope with hint to use get_config). This compensates entirely for the schema gap.
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 'List available Metaflow flows' and positions it for discovering flows before searching for runs. This clearly distinguishes it from sibling tools like search_runs.
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 advises using this tool to discover flows before searching for runs, and recommends using get_config to find default_namespace. It lacks explicit when-not-to-use or comparisons to other sibling tools but provides clear context.
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?
With no annotations, the description fully discloses behavioral traits: system tags cannot be removed, removing non-existent tags is a no-op, and the operation modifies the run. This is comprehensive for a mutation tool.
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 extremely concise, front-loading the purpose, then listing constraints and arguments without any extraneous wording.
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 that an output schema exists (so return values don't need explanation), the description fully covers the tool's behavior, constraints, and parameters, making it complete for an agent to use 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 description provides an Args section that explains the format of 'pathspec' ('FlowName/RunID') and clarifies 'tags' are the tags to remove, adding value beyond the schema's basic type information despite 0% schema description coverage.
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 user tags from a Metaflow run' with a specific verb and resource, and distinguishes itself from the sibling tool 'add_run_tags' by focusing on removal.
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 important usage details like system tags cannot be removed and non-existent tags are no-ops, but lacks explicit guidance on when to use this tool versus its sibling 'add_run_tags'.
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?
With no annotations, the description fully discloses asynchronous execution (returns immediately with tracking identifiers), required identifier, optional parameters, and auto-detection of impl. It sets proper expectations for subsequent polling.
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 with a one-sentence summary followed by logical paragraphs. Each sentence adds value; no fluff. Args section clearly maps to parameters.
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 prerequisites (list_deployments), async nature, how to retrieve results, parameter defaults, and auto-detection. Output schema exists so return format need not be explained. Complete for a tool with moderate complexity.
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?
Schema coverage is 0%, but description adds example values for identifier (e.g., 'myproject.test.staging.TrainFlow'), explains parameters as optional key-value overrides, and notes impl auto-detection. This goes well beyond the bare type information in the 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?
Description clearly states action (trigger a new run), specific resource (deployed Metaflow flow), and differentiates from sibling tools like list_deployments and get_run. It also helps with prerequisites by mentioning list_deployments to discover identifiers.
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?
Description explains when to use (for deployed flows) and provides explicit references to companion tools (list_deployments, get_triggered_run_status, get_run). Lacks explicit 'when not to use' but context is sufficient.
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:

[![metaflow-mcp-server MCP server](https://glama.ai/mcp/servers/npow/metaflow-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/npow/metaflow-mcp-server)

Score Badge

Copy to your README.md:

[![metaflow-mcp-server MCP server](https://glama.ai/mcp/servers/npow/metaflow-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/npow/metaflow-mcp-server)

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/npow/metaflow-mcp-server'

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