Skip to main content
Glama

Start a BotArmor audit

start_audit

Crash-test chatbots and AI agents with multi-level audits, then retrieve status and actionable reports containing exact prompt improvements.

Instructions

Crash-test a chatbot or AI agent with BotArmor: up to 12 attack levels (fake manager, angry customer, fake lawyer, prompt injection, role-play, phishing, AI disclosure under the EU AI Act, invented facts...) plus level 13 for agents with tools, 5 adaptive sessions each. Two modes. target_type 'prompt' (default when no endpoint_url): BotArmor plays the agent's system prompt on its own model; use it for an agent running on localhost or not deployed yet, reading the system prompt from the code. target_type 'openai-compatible' or 'webhook': a live audit of a running bot at a public https URL; requires authorization_confirmed: true, only after the user confirmed they own the bot or have written permission. Returns the audit id; an audit takes 5 to 20 minutes, then use get_audit_status and get_audit_report. Uses one audit credit.

Input Schema

NameRequiredDescriptionDefault
langNoReport language, default en.
nameNoName shown in the report.
modelNoopenai-compatible only: the model name sent in the request body.
levelsNoSubset of levels; default all 12 (plus 'agency' when tools are declared).
headersNoHeaders the target needs, e.g. {"Authorization": "Bearer ..."}. A credential header is stored encrypted by BotArmor.
min_gradeNoPass threshold shown by get_audit_status, default B.
target_typeNoDefault: 'webhook' when endpoint_url is given, else 'prompt'.
endpoint_urlNoPublic https URL of the running agent (live audits only). localhost cannot be reached from BotArmor's servers.
body_templateNowebhook only: JSON body with {{input}} (current message), "{{history}}" or "{{messages}}". Default {message: "{{input}}", session_id: "{{session_id}}"}.
response_pathNowebhook only: dot path to the reply text in the response JSON, e.g. data.reply.
system_promptYesThe agent's system prompt / instructions, as in its code. For a live audit it is also the rulebook the judge checks answers against.
authorization_confirmedNoLive audits only. true = the user confirmed they own the bot or hold the owner's written permission to test it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4.6/5.0
Behavior4/5

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

Annotations only declare openWorldHint=true and destructiveHint=false; the description goes well beyond that by disclosing duration (5 to 20 minutes), cost (one audit credit), the asynchronous pattern (returns an id, poll with get_audit_status), the credential-encryption behavior for headers, and the authorization gate for live targets. The only missing behavioral detail is what happens on failure or whether credits are refunded on a failed audit.

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?

Front-loaded with the core action and mode split, and nearly every clause carries operational information. The parenthetical enumeration of attack personas ('fake manager, angry customer, fake lawyer...') is illustrative rather than actionable and makes the block longer than strictly needed.

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 12-parameter, nested-object tool with no output schema, the description covers what an agent needs: mode selection, authorization gate, what is returned (audit id), latency, cost, and the follow-up tools. Nothing required to invoke it correctly is missing.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema only hints at: the 'agency' level applies to agents with tools, each level runs 5 adaptive sessions, and target_type selection is driven by whether endpoint_url is present. The system_prompt dual role (rulebook for the live judge) is also clarified beyond the schema text.

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?

Opens with a specific verb and resource ('Crash-test a chatbot or AI agent with BotArmor') and immediately scopes what the crash-test consists of (up to 13 attack levels, 5 adaptive sessions each). It also makes clear this is the audit-launching tool, distinct from the read-only siblings get_audit_status, get_audit_report and list_audits, which it names as follow-up steps.

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?

Gives explicit routing rules for the two modes: 'prompt' when there is no endpoint_url, for localhost or undeployed agents; 'openai-compatible'/'webhook' for a live public https URL. It also states the hard prerequisite for live audits (authorization_confirmed: true, only after the user confirms ownership or written permission) and names the exact tools to call afterwards.

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