Skip to main content
Glama
Sign In
Automation Auditor MCP

Automation Auditor MCP

by ahamdjin
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

list_supported_platforms

Lists exact export types and audit limitations for n8n, Dify, Trigger.dev, Activepieces, and OpenAPI; unsupported platforms are not called safe.

Instructions

List exact export types and limitations; unsupported platforms are never called safe.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_supported_platforms"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.8/5.0
Behavior2/5

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

With no annotations, the description carries full behavioral burden, but it only offers a cryptic policy statement ('unsupported platforms are never called safe'). It does not disclose what the tool returns, whether it is a read operation, or any other behavioral trait.

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, short sentence with no wasted words, and the main action is front-loaded. However, the phrasing is slightly ambiguous, which keeps it from being perfect.

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 no annotations and no output schema, the description is too minimal. It does not clarify what 'export types and limitations' means for platforms, nor does it indicate what the returned list contains, leaving an agent unable to call it confidently.

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 takes zero parameters, so there are no parameter semantics to document. The baseline of 4 applies because the schema is effectively complete and the description need not add parameter information.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description says 'List exact export types and limitations,' which is a verb but does not name the resource 'platforms' even though the tool name does. It fails to distinguish the tool from siblings like audit_workflow or preflight_url, leaving the actual scope vague.

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. No context or exclusions are provided, so the agent must infer its purpose from the name alone.

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