Skip to main content
Glama

avito_check_auth

Read-only

Check if required Avito credentials are present in the environment and report missing variable names without revealing secret values.

Instructions

Check whether the required credentials are present in the environment.

Does NOT reveal secret values — only reports which variables are set. Returns JSON: {"ready": bool, "missing": [str], "required": [str]}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.3

TDQS

A4.4/5.0
Behavior4/5

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

Annotations declare readOnlyHint=true, which aligns with the description's non-mutating nature. The description adds value by explicitly promising not to reveal secret values — a key behavior not inferable from annotations alone. It also discloses the return format, which is helpful for downstream use.

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?

Two concise sentences with no fluff. The first sentence quickly states the function, the second emphasizes the security guarantee, and the third states the return format. All essential information is front-loaded, making it easy for an agent to parse and act.

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 check tool with a clear output schema, the description fully covers what an agent needs to know: what it does, what it doesn't do, and what it returns. There's no missing information given the low complexity.

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 tool has zero parameters)Skip the redundancy. The description clarifies that no parameters are needed, which is implicit in an empty schema. Since there are no parameters, the baseline for this dimension is high (4) even without description. The description adds no param info because there are none, so it doesn't need to compensate. Given the rule '0 params = baseline 4', and the description's clarity about the tool's purpose, a 5 is justified.

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?

States a specific verb ('check') and resource ('credentials'), and the environment context. Distinguishes itself from sibling auth checks (e.g., 'wb_check_auth', 'ozon_check_auth') by the 'avito_' prefix and the explicit mention of environment credentials. It clearly indicates it is a readiness check for authenticated use.

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 when to use it (checking credentials before operations) but does not explicitly state when to use it versus alternatives like 'avito_set_key' or 'avito_whoami'. It doesn't mention prerequisites or exclusions, but it clearly says it does NOT reveal secrets, which is a useful boundary.

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