Skip to main content
Glama
rodlunt

engineering-audit

by rodlunt

file_issues

Preview or file GitHub issues for audit findings, requiring user confirmation before filing to prevent unwanted external actions. Tracks filed issues to avoid duplicates on retry.

Instructions

Preview or file GitHub issues for every recorded finding, via the user's own gh CLI.

    Requires config.issue_mode == "github": if the user chose in-report
    delivery instead, this raises rather than filing issues nobody asked
    for. Requires at least one recorded domain result.

    confirm=False (the default) NEVER files anything and never invokes
    gh at all: it returns a preview {repo, count, titles, instruction}
    so the calling agent can show the user exactly what is about to be
    filed on their repository, and get explicit agreement, before a
    single issue goes out. Filing on someone's repo is outward-facing;
    this confirmation step is mandatory, not decorative.

    confirm=True files one issue per finding that has not already been
    filed, so retrying after a partial failure does not double-file the
    ones that succeeded. Filed issues are tracked, and returned, per
    finding under a key of the form "<rule id>#<n>" (n counting that
    rule's findings in recording order), not per rule id: a domain result
    may carry two findings for the same rule, and both of their issue
    urls have to survive. The target repository is `repo` if given,
    otherwise detected from the audited repository directory recorded
    by begin_run's repo_dir. If any issue fails to file, filing stops
    immediately and the error lists exactly which findings were filed
    (with their URLs) and which were not, so a retry knows where to
    resume.

    Each filed issue carries the "engineering-audit" label. The label is
    checked once per call and created on the target repository if it is
    missing; the response's label field reports which of present,
    created or unavailable happened. Unavailable (creation failed) files
    the issues unlabelled and says so once, in warnings, rather than
    once per issue.
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
repoNo
confirmNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/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 confirm=False never invokes gh, that confirm=True is idempotent against partial failures, how issue keys are structured, how the target repo is resolved, what happens on failure (stops, lists filed vs unfiled), and the label creation fallback behavior. This is exemplary transparency.

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 long, but each paragraph covers a unique and necessary aspect: purpose, prereqs, confirmation, idempotency, repo resolution, failure handling, and label behavior. It is well-structured, though slightly verbose compared to a tighter alternative.

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?

The description covers all operational contexts: prerequisites, default preview behavior, retry semantics, error reporting, label handling, and repo selection. With an output schema present, return values are already defined, and the description still adds valuable context. It is fully complete for a safe-use 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?

The input schema provides only names and types with no descriptions (0% coverage). The description fully compensates: it explains confirm=False's preview behavior and that repo defaults to begin_run's repo_dir when absent. Both parameters are semantically defined.

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 opens with 'Preview or file GitHub issues for every recorded finding, via the user's own gh CLI,' which specifies a concrete action, target, and scope. This clearly distinguishes it from sibling workflow tools like get_domain or render_report.

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

Usage Guidelines5/5

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

It explicitly states the required config mode ('Requires config.issue_mode == "github"') and warns that in-report delivery raises instead. It also explains the two usage modes (confirm=False preview vs confirm=True filing) and stresses that confirmation is mandatory before outward-facing actions, giving clear when-to-use guidance.

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

Install Server

Other Tools

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/rodlunt/engineering-audit'

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