Skip to main content
Glama
rodlunt

engineering-audit

by rodlunt
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

get_config

Fetch the resolved audit configuration from an interactive setup, reporting whether the user has submitted the configuration page and returning the config when ready.

Instructions

Fetch the resolved audit configuration, or report that the user has not submitted the configuration page yet.

    Requires start_config to have been called first. Every response carries
    a "status" field, and it is the only field worth branching on:

    - "configured": the configuration is resolved and is in the response's
      "config" and "selected_domain_ids". Stop calling this tool.
    - "waiting": the interactive page is up and nobody has submitted it
      yet. This is NOT a failure and NOT a configuration. Tell the user the
      audit is waiting on them at the "url" in the response, then CALL THIS
      TOOL AGAIN. Keep calling it while the status says "waiting".
    - a raised error: the run's overall deadline (timeout_s) elapsed with
      no submission. Tell the user the audit is not proceeding. Never fall
      back to a domain selection nobody chose.

    In preset mode the configuration is already known and comes back as
    "configured" on the first call.

    This tool deliberately blocks for at most a short interval per call
    (about 25 seconds) and then returns "waiting", rather than holding one
    call open for the whole of timeout_s. Hosts impose their own per-tool
    timeouts, independent of timeout_s (Codex has
    mcp_servers.<name>.tool_timeout_sec), and a call held open past one of
    those is cancelled by the host, which can take the whole MCP process
    and this run's configuration page down with it (issue #85). timeout_s
    remains
    the run's overall waiting budget and is enforced here, cumulatively,
    across however many calls it takes: it is measured from the moment the
    page opened, so polling more often does not buy the user more time, and
    polling less often does not cost them any. To keep waiting past the
    deadline, call again with a larger timeout_s; that is an explicit
    decision to extend, not a silent one.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
timeout_sNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Tool Definition Quality

A5/5.0
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.

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