Skip to main content
Glama
r28ai

GitHub + Linear Dev Workflows

by r28ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

github_dependabot_list_alerts

Read-onlyIdempotent

Lists a repository's Dependabot alerts with dependency, severity, and first fix version; supports filters for state, severity, ecosystem, and package.

Instructions

List a repository's Dependabot alerts: which dependency, how severe, and the first version that fixes it. Several filters take a comma-separated list, so state='open,dismissed' is valid. Needs the security_events scope. This endpoint has no page parameter — raise per_page rather than paging.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
hasNoOnly alerts with the given property. Currently only `patch` is supported, which restricts results to alerts that have a fix available.
repoYesThe name of the repository without the `.git` extension. The name is not case sensitive.
sortNoThe property by which to sort the results. `created` means when the alert was created. `updated` means when the alert's state last changed. `epss_percentage` sorts by estimated exploitation probability. GitHub uses `created` when this is absent.
ownerYesThe account owner of the repository. The name is not case sensitive.
scopeNoThe scope of the vulnerable dependency. `runtime` is what ships; `development` is what only the build sees.
stateNoA comma-separated list of states. If specified, only alerts with these states will be returned. Can be: `auto_dismissed`, `dismissed`, `fixed`, `open`.
packageNoA comma-separated list of package names to restrict the results to.
perPageNoThe number of results to return (max 100). Defaults to 30.
assigneeNoFilter alerts by assignees, as a comma-separated list of user handles. Use `*` for alerts with at least one assignee or `none` for alerts with no assignees.
manifestNoA comma-separated list of full manifest paths.
severityNoA comma-separated list of severities. Can be: `low`, `medium`, `high`, `critical`.
directionNoThe direction to sort the results by. GitHub uses `desc` when this is absent.
ecosystemNoA comma-separated list of ecosystems. Can be: `composer`, `go`, `maven`, `npm`, `nuget`, `pip`, `pub`, `rubygems`, `rust`.
relationshipNoA comma-separated list of relationships of the vulnerable dependency to your project. Can be: `unknown`, `direct`, `transitive`, `inconclusive`.
classificationNoA comma-separated list of vulnerability classifications. Can be: `malware`, `general`.
epssPercentageNoFilter by EPSS percentage — the estimated probability of exploitation. An exact number, a comparator such as `>0.5`, or a range `0.1..0.4`, with values from 0.0 to 1.0.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/openWorld, yet the description adds a genuine auth requirement ('Needs the `security_events` scope') and a behavioral quirk (no page parameter, so raise per_page). It stops short of covering rate limits or result shape.

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?

Three short sentences, purpose first, then invocation tips. No filler and every clause 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?

For a 16-parameter filtered-list tool with a fully documented schema but no output schema, the description supplies the essentials an agent needs (scope, filter syntax, pagination convention). Sibling disambiguation is the only notable gap.

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 100% (baseline 3), and the description still adds a concrete comma-separated example (`state='open,dismissed'`) plus the pagination guidance for per_page/perPage. Minor naming mismatch (`per_page` vs schema's `perPage`) keeps it from the top.

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?

States a specific verb and resource ('List a repository's Dependabot alerts') and previews the payload ('which dependency, how severe, and the first version that fixes it'). It is unambiguous against the sibling alert tools (code_scanning_list_alerts, secret_scanning_list_alerts).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides operational invocation context (comma-separated filters, no paging) but never says when to choose this over the sibling scanning-alert tools or any exclusions. Usage is implied from the Dependabot-specific purpose rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools