engineering-audit

by rodlunt

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.10.0
Disambiguation5/5
Each tool occupies a clear, distinct role in the audit lifecycle: configuration, run status, domain listing, rule text retrieval, feedback, run management, result recording, issue filing, and report rendering. There is no overlapping purpose; even start_config and get_config are cleanly separated as initiating versus polling for configuration. The descriptions further disambiguate any apparent similarity.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using lowercase snake_case: get_config, list_domains, begin_run, render_report, etc. No mixed conventions or vague verbs. The naming makes the tool's action and object predictable at a glance.
Tool Count5/5
Ten tools is well within the ideal range and each tool maps to a necessary step in the audit workflow. The count feels neither sparse nor bloated, and every tool earns its place by serving a distinct function in the overall process.
Completeness5/5
The toolkit covers the full audit lifecycle: configuration, run initialization and resumption, domain and rule access, result recording with validation, report rendering, issue filing with preview, and feedback submission. There are no obvious dead ends or missing operations; even re-recording and discarding runs are handled via parameters like replace=True.
Average 4.7/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 236 commits in the last 12 weeks
- Last stable release on August 18, 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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It transparently discloses both the main listing action and a notable edge case (skipped files with no Trigger line). While it doesn't explicitly state read-only status or permissions, 'List' strongly implies a non-mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with two closely related clauses. Every word contributes meaning, with no fluff or repetition of schema 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?
For a parameterless list tool with an output schema present, the description covers the core purpose and a valuable edge-case behavior. The output schema likely handles return-value details, so the description is sufficiently complete for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already fully covers the input surface. The baseline of 4 applies, and the description appropriately adds no parameter-specific noise.
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 a specific verb ('List') and resource ('every domain loaded from the rules pack'), and adds a distinct secondary behavior about reporting skipped files. This clearly differentiates it from sibling tools like get_domain, which likely fetches a single domain.
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 context is clear: this is for enumerating all domains in the rules pack, not for looking up one specific domain (which get_domain likely handles). However, it does not explicitly state when to use this tool versus alternatives or mention any exclusions, stopping short of a 5.
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 carries the full burden. It explicitly discloses the tool is read-only (non-destructive) and mentions the queued warning behavior, which is a useful nuance. It doesn't go into details like rate limits or auth, but for a simple status check it provides adequate transparency.
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 two concise sentences, front-loaded with the primary purpose ('Report progress for the current run'). Every clause adds information: what is reported, the read-only nature, and the additional warning behavior. No 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?
For a zero-parameter tool with an output schema, the description fully covers what the tool does and what the response will contain (progress details plus optional warning). It is complete given the simplicity of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (vacuously). The description doesn't need to explain any parameters. Baseline for zero-parameter tools is 4, and the description adds no unnecessary parameter detail.
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 with a specific verb ('Report') and resource ('progress for the current run'). It enumerates what it reports (which selected domains have recorded results, which are missing, findings count), distinguishing it from sibling tools like get_domain or record_domain_result.
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 gives clear context for when to use this tool: it is read-only over the run itself and additionally surfaces queued crash-recovery warnings that haven't been reported yet. It doesn't explicitly name alternatives, but the sibling set contains no similar status tool, so usage is fairly clear.
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 carries the full burden and delivers: it details validation layers, error types (IncompleteResultError, UnknownRuleIdError), the deliberate recording of unfetched domains with a warning, refusal of two specific fields, and the rationale for these behaviors. This is exemplary disclosure of edge-case handling and error semantics.
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 and dense, but every sentence contributes substantive guidance—validation rules, errors, edge cases, and rationales. It is front-loaded with the core purpose and organized into coherent paragraphs. It would be slightly more scannable with bullets, but the length is justified by the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of DomainResult validation and the absence of annotations, the description is remarkably complete: it covers success criteria, failure modes, exceptions, overwrite protection, unfetched domains, and field refusals. The output schema covers return values, and the description fills the behavioral gap thoroughly.
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 top-level schema has 0% description coverage, so the description must compensate. It adds significant meaning: constraints on DomainResult (every rule verdict required, consulted_sources rule_id association), replace semantics, and rejection criteria. It does not restate the JSON shape, but the nested schema $defs cover structure. Slightly more explicit field-level guidance would raise it further.
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 a specific verb+resource: 'Record the audit result for one domain.' It further specifies scope (domain must be selected for this run, replace=True for re-recording), clearly distinguishing it from sibling tools like get_domain (fetching) and list_domains (listing). The purpose is unambiguous and actionable.
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 tool explains when to use it (after auditing a domain, with validation of completeness), when to use replace=True (re-recording), and when results are refused (missing precondition or uninspected_evidence). It references AUDIT.md steps 3 and 4 for deeper context. It does not explicitly name alternatives, but the operational context is clear.
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 provided, the description carries the full burden and it excels: it discloses atomic writes, file locations (deliverables_dir vs output_dir), removal of crash-recovery file, changes in run reachability, failure modes (raises on incomplete runs), and the response's 'rules_fetched' field. This is comprehensive behavioral 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 well-structured: the core purpose is front-loaded, and each subsequent paragraph covers a distinct behavioral aspect (server_finished, feedback ordering, atomicity, response). Some historical detail like 'issue #109' could be trimmed, but the length is largely justified by the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description is remarkably complete. It covers prerequisites, side effects, ordering with sibling tools, failure modes, and response content. The output schema handles return structure details, so the description needs no further additions.
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 only parameter, 'finished', has 0% schema description coverage, but the description adds meaning by calling it an 'ISO timestamp' and explaining it sets meta.finished. This goes beyond the bare schema type, though it does not specify the exact ISO 8601 variant or format 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?
The description opens with 'Finish the run and render its report,' a specific verb+resource statement that distinguishes it from siblings like begin_run, record_domain_result, and submit_feedback. It further elaborates on deliverables and side effects, leaving no ambiguity about the tool's role.
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 clearly states a prerequisite ('Requires a resolved configuration') and explains interaction order with submit_feedback and begin_run. It references begin_run for a design rationale but does not explicitly say 'use this instead of X', so it lacks explicit exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states that an invalid config file produces a loud error rather than a silent default, that browser opening is best-effort with an opened_in_browser field in the response, and that the URL is returned as a fallback. This is comprehensive and goes well beyond a bare statement of purpose.
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, consisting of two sentences with a clear front-loaded purpose statement. Every clause provides meaningful behavioral or contextual detail, and there is no wasted 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 the tool's simplicity and the presence of an output schema, the description is complete. It covers both operating modes, error behavior, browser handling, and response contents, leaving no significant gap for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is an empty object with 100% schema coverage. The description doesn't need to elaborate on parameter semantics; the baseline for zero-parameter tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Begin configuring the audit run,' clearly identifying the tool's action and resource. It further distinguishes the headless/CI path from the interactive path, making its purpose distinct from sibling tools like get_config and begin_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 explains when the headless/CI path is triggered (when ENGINEERING_AUDIT_CONFIG is set) and when the interactive page is used, providing clear contextual guidance. It doesn't explicitly state alternatives or exclusions, but the context is sufficient for an agent to decide when to invoke this tool.
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 carries the transparency burden and delivers extensively. It discloses failure behavior (raises when nothing to send, mailto fallback on gh failure), consent-based telemetry inclusion, rewriting of report.html/run-state.json, and the deliberate warning rather than error after a failed rewrite to avoid double-filing.
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 information-dense and front-loaded with a clear first sentence, but the telemetry section list is an extremely long parenthetical that hurts readability. All content earns its place, yet tightening the structure would improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description covers all critical operational context: preconditions, content construction, parameter ethics, failure modes, timing relative to render_report, side effects, and idempotency concerns. This level of detail is necessary for correct invocation and retry behavior.
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 compensates thoroughly. It explains extra_text as agent-supplied free text, and provides extensive semantic and ethical guidance for report_conclusion and report_fix_first, including when they are ignored and that they must be the human's own words.
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 opening sentence, 'Send optional run feedback to the tool author,' identifies a specific verb, resource, and audience, clearly distinguishing this from sibling tools like file_issues and render_report. Additional details about filing a labeled issue on the author's feedback repository reinforce the tool's unique role.
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 context: it requires a resolved configuration, only sends if config.feedback_text or extra_text is present, and may be called before or after render_report with different behaviors. However, it does not explicitly contrast with sibling tools like file_issues, leaving some inference to the agent.
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 carries full burden and does so thoroughly: it discloses that double-calling without finishing is an error, that replace=True discards results, that progress is crash-recoverable, that resuming a different repo is refused, and the update-check behavior including user warning obligations. This is exemplary 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long and dense, covering many edge cases and implementation details. While well-paragraphed and front-loaded with the core purpose, it could be trimmed; sentences like those detailing provenance SHA mechanics and elapsed-time philosophy, though valuable, add length that a more concise version might compress.
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 (11 params, resume/replace flow, crash recovery, provenance, update checks), the description covers all critical aspects: what the call does, what it returns (run_started, meta absence, resumable), side effects, and error conditions. The presence of an output schema is noted, but the description still explains return semantics thoroughly.
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 schema has 0% description coverage, so the description must explain all parameters. It does: assistant/model/repo_name/repo_commit/started are caller-supplied, tool_version defaults, repo_dir is optional but needed for file_issues, environment has a closed key set, resume/replace semantics are defined, and started is a trust claim distinct from server-stamped times. Every parameter's meaning is addressed.
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 a clear, specific verb+resource: 'Start a fresh audit run and create its output directory, or resume an interrupted one.' This distinguishes it from sibling tools like run_status or render_report, which query or finalize rather than initialize or resume.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance, including the requirement to call begin_run before file_issues when repo_dir is needed, the error on calling twice without finishing, and clear conditions for resume=True vs resume=False. It also states prohibitions like refusing to resume for a different repository, leaving no ambiguity.
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 carries full responsibility and excels. It discloses that the call is recorded against the run, that it is the sole observable event supplying rules for a verdict, and that recording only happens when a run is active. It even clarifies that a fetch is merely 'fetched, never read,' adding nuanced context beyond the obvious read 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear purpose sentence. The following paragraphs are detailed and each adds valuable context about audit recording, but they are somewhat verbose. Still, no sentence is wasted, and the structure is logical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, an output schema, and rich behavioral nuances, the description is complete. It covers purpose, intended user, prerequisites, side effects, and the distinction from siblings. The existence of an output schema means return values need no elaboration.
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 only parameter, domain_id, is clarified with an example ('e.g. 'd01''), which adds meaning beyond the bare schema (0% coverage). It could go further by explaining how to obtain a valid domain_id (e.g., from list_domains), but the example and context are sufficient for basic invocation.
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 a specific verb and resource: 'Return the full document text for one domain, given its id.' It immediately distinguishes itself from siblings by stating 'Nothing else in this package returns rule body text,' making the tool's unique purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states it is meant for the local agent driving the audit and provides a prerequisite: 'call begin_run first, then fetch each domain as you come to it.' It also clarifies when the call is recorded (run in progress) and that no other tool returns rule body text, serving as an exclusion criterion.
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 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even without annotations, the description fully discloses the tool's blocking behavior (~25s per call), the cumulative timeout semantics, and the risk of host-level timeouts that can cancel the process (referencing issue #85). It also warns about not falling back to domain selections nobody chose, which is a significant behavioral constraint.
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?
Though lengthy, every paragraph serves a purpose: the first sentence states the purpose, the status list gives actionable branching logic, and the final paragraph justifies the polling interval and timeout behavior. The structure with clear bullet points and paragraph separation makes it navigable.
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 prerequisites, all response statuses, the response fields worth branching on, error behavior, and host timeout interactions. With a 1-parameter schema and no annotations, this description leaves no operational ambiguity.
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 schema only provides a title and default for timeout_s, but the description explains its true meaning: the overall waiting budget measured from when the page opened, cumulative across calls, and that extending it is an explicit decision. This is exactly the kind of semantic enrichment the schema lacks.
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 'Fetch the resolved audit configuration, or report that the user has not submitted the configuration page yet', which clearly identifies the operation and resource. It also distinguishes this from sibling tools like list_domains or run_status by framing it as a polling endpoint for configuration submission.
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 'Requires start_config to have been called first' and provides a decision tree for the three response statuses, instructing to call again while waiting and to stop once configured. It also clarifies behavior in preset mode, making it clear when this tool should be used.
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:

[![engineering-audit MCP server](https://glama.ai/mcp/servers/rodlunt/engineering-audit/badges/card.svg)](https://glama.ai/mcp/servers/rodlunt/engineering-audit)

Score Badge

Copy to your README.md:

[![engineering-audit MCP server](https://glama.ai/mcp/servers/rodlunt/engineering-audit/badges/score.svg)](https://glama.ai/mcp/servers/rodlunt/engineering-audit)

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

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