automation-audit

by zuperRuslana

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.1.0
Disambiguation5/5
Each tool targets a distinct resource or action: calculations, creation, saving answers/audits, and listing/retrieving audits. Even similar verbs like create_business and create_process are clearly separated by the object they operate on.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern, such as calculate_, create_, save_, list_, and get_. This makes the set predictable and easy to navigate.
Tool Count5/5
Eight tools is a well-scoped set for an automation audit workflow. Each tool serves a clear purpose in the process from creating businesses and processes to calculating metrics and managing completed audits.
Completeness4/5
The core audit lifecycle is covered: create businesses/processes, capture discovery answers, calculate cost and automation score, and save/retrieve audits. Minor gaps exist around updating or deleting businesses/processes, but these are not essential to the main workflow.
Average 3/5 across 8 of 8 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Save or update', but does not clarify upsert semantics, overwrite behavior, idempotency, error handling, or any side effects. The agent cannot predict what happens if the answer already exists or what the response will be.
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 a single concise sentence with no wasted words. However, it is under-specified rather than efficiently informative, so it does not fully earn a 5 for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four required parameters, no annotations, and no output schema, the description is grossly incomplete. It lacks context on what constitutes a discovery answer, how question_key is derived, and what the expected return value is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no explanation of any parameters. None of the four required parameters are described, leaving the agent to guess the meaning of process_id, question_key, question_text, and answer_text.
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 verb 'Save or update' and the resource 'discovery answer for a business process'. It distinguishes the tool from siblings like save_audit by specifying the unique concept of a discovery answer, though it does not explicitly contrast it with alternatives.
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 is given on when to use this tool vs alternatives. It does not mention any conditions for use, prerequisites, or differences from sibling tools such as save_audit or create_business.
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?
With no annotations, the description carries full responsibility for behavioral disclosure. It only states the calculation purpose and implies no side effects, but does not disclose anything about the input ranges, output format, or any constraints. An agent cannot predict what the function returns or how it behaves with varying inputs.
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 a single concise sentence with no fluff, but it is under-specified for a tool with five parameters. It is well-structured in its brevity but fails to provide necessary context, making it merely a bare statement rather than an effective guide.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five required parameters and no output schema, annotations, or parameter descriptions, the description is severely incomplete. It does not explain the scoring scale, how to interpret results, or any prerequisites, leaving an agent largely in the dark about correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description makes no mention of the five required parameters, their meanings, or how they relate to the automation score. The parameter names (frequency, rule_clarity, etc.) are self-descriptive but the description adds zero value in interpreting them or their expected values.
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 states a clear verb (calculate) and resource (business process suitability for automation), distinguishing it from siblings like calculate_time_cost which focuses on cost. However, it does not specify the nature of the score or how it is derived, which slightly weakens differentiation but remains unambiguous.
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?
There is no guidance on when to use this tool versus alternatives. It does not mention that it should be used when evaluating a process for automation, nor does it differentiate from calculate_time_cost or the create/save tools. No context or exclusions are provided.
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 the full burden. It only states that a process is created, but does not disclose side effects, permissions required, idempotency, or what happens to existing processes. For a create action, this is a minimal disclosure that leaves behavioral expectations largely unspecified.
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 a single sentence, concise and front-loaded with the core action and purpose. However, it is so brief that it omits necessary detail; while it earns its place for purpose clarity, it sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three required parameters and no output schema, the description should explain parameter roles and perhaps return behavior. It does neither. The description only clarifies the 'what' and 'why', leaving the 'how' (parameter usage) and 'what to expect' completely unaddressed. Given the tool's simplicity, a bit more context would be expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for all three parameters (business_id, name, description), and the description provides no additional meaning for any of them. The description does not compensate for the schema's lack of doc comments, so an agent has to infer parameter semantics purely from their names. This is a significant gap for a tool with required parameters.
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 states a specific verb ('Create'), a resource ('business process'), and the intent ('to evaluate for automation'). This clearly distinguishes it from siblings like create_business or save_discovery_answer, which target different entities.
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?
There is no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The description does not mention conditions under which another tool (e.g., create_business) would be more appropriate. An agent would have to infer usage from the name and schema alone.
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?
With no annotations provided, the description carries the full behavioral burden. It states that the tool creates and stores a business, which implies persistence, but it does not mention whether creation is idempotent, whether duplicates are allowed, what authorization is needed, or what happens on success or failure.
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 a single, focused sentence that front-loads the action and object. It is concise and easy to parse, though it sacrifices detail that other dimensions need.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a small schema and no output schema, but the description does not mention return values, error behavior, or required-field semantics. For a create operation with no annotations, an agent would still need more context to use it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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, but it does not explain any of the three parameters. The parameter names are self-explanatory at a basic level, but units, constraints, and how they relate to an automation audit are left unspecified.
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 uses a specific verb ('Create and store') with a clear resource ('a business') and a domain purpose ('for an automation audit'). It is clearly distinct from sibling tools like create_process and save_audit because it targets the business entity specifically.
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 phrase 'for an automation audit' gives implied context about when this tool is relevant, but it does not explicitly state when to use it versus alternatives like create_process or save_audit. No exclusion criteria or preferred ordering is provided.
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 must carry the full burden of behavioral disclosure. It only says 'save', which implies a write operation, but it does not mention whether the tool is idempotent, whether it overwrites existing audits, what permissions are required, or any side effects. This is insufficient for a mutation tool without annotation support.
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 a single, concise sentence with no wasted words. It is appropriately sized for a simple save operation, though it could be expanded to cover essential context. It is front-loaded with the action and object, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 required parameters, no output schema, and no annotations, the description is far too minimal. It does not clarify what values are expected for parameters like automation_score, category, or monthly_hours, nor does it describe the overall workflow context (e.g., that the audit must be calculated first). An agent would struggle to populate the parameters correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/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 by explaining the parameters. It mentions none of the six parameters, their meanings, or their relationships. The schema titles (e.g., 'Automation Score') provide minimal clues, but the description adds no additional semantic value, making it impossible for an agent to understand parameter intent from the description alone.
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 a specific verb ('Save') and a specific resource ('completed automation audit'), and it distinguishes from sibling calculation tools (calculate_time_cost, calculate_automation_score) and retrieval tools (list_audits, get_audit) by indicating a persistence action. The word 'completed' also hints at its position in the workflow.
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 after an audit is completed, but it does not explicitly state when to use it relative to the calculation tools, nor does it mention prerequisites or alternatives. The guidance is implicit rather than explicit, so it earns a middle score.
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 must carry all behavioral disclosure. It only states a retrieval action with no mention of side effects, permissions, or return characteristics. The term 'complete' is vague and does not reveal what fields or structure are returned.
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, short sentence with no filler. It front-loads the action and resource, making it easy to parse. There is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description is incomplete. It does not describe the return value's structure, possible errors, or the meaning of 'complete audit.' For a simple retrieval by ID, some context like typical usage or response format is expected but missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% coverage—audit_id is defined only by its runtime type and title. The description does not explain what audit_id refers to or how to obtain it, beyond the implication from the tool name. It relies on the property name to carry meaning, which is minimal but not entirely useless.
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 'Retrieve' and the resource 'one complete automation audit,' which distinguishes it from sibling tools like list_audits that likely return multiple audits. The word 'one' and 'complete' make the scope specific and unambiguous.
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 is given about when to use get_audit versus alternatives such as list_audits or save_audit. An agent is left to infer that this retrieves a single audit, but there is no explicit statement of conditions or exclusions.
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?
There are no annotations, so the description carries the behavioral transparency burden. It only states that the tool 'calculates,' implying a read-only, side-effect-free operation, but it does not disclose assumptions like weeks-per-month conversion, rounding, or whether the result includes both time and cost as separate outputs.
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 no filler. Every word contributes to the purpose, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, so the description does not need to explain return values. However, it omits key assumptions (e.g., how weeks are converted to months) and does not clarify when to prefer this tool over calculate_automation_score, leaving some context gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needs to compensate by clarifying parameter semantics. It adds only the 'monthly' context, which helps interpret frequency_per_week, but it does not explain units, formulas, or relationships among the required parameters.
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 ('Calculate') and resource ('monthly time and labor cost of a manual process'). This clearly distinguishes it from the sibling calculate_automation_score, which focuses on a scoring metric rather than cost/time calculation.
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 intended use is implied by the description: use this tool when you need the monthly time/labor cost of a manual process. However, it does not explicitly mention when not to use it or contrast it with alternatives such as calculate_automation_score.
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, the description must carry behavioral disclosure. The word 'list' conveys a read-only operation and 'all saved' signals no filtering, which is useful. However, it does not explicitly state that the operation is non-destructive, nor does it mention pagination, ordering, or side effects, though the output schema may cover the return 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?
The description is a single, front-loaded sentence that states exactly what the tool does without any filler. Every word 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 parameterless listing tool with an output schema, this description is largely complete: it names the resource, the operation, and the scope. It only falls short in not pointing the agent to get_audit for single-audit scenarios, which is a minor gap given the sibling list.
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 accepts zero parameters, so there is no parameter semantics burden on the description. The baseline of 4 applies, and the description appropriately requires no additional param details.
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 ('list') and identifies the exact resource ('saved automation audits'), adding a scope marker ('all') that distinguishes it from the sibling get_audit, which implies retrieving a single audit. This is unambiguous and directly tells an agent what the tool returns.
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 the tool should be used when an agent needs a collection of all saved audits, but it does not explicitly state when it should not be used or name get_audit as the alternative for a single audit. The usage context is present but left to inference.
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:

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

Score Badge

Copy to your README.md:

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

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/zuperRuslana/automation-audit-mcp'

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