Skip to main content
Glama
VericyIO

AIR MCP Server

by VericyIO

Re-check the tier under the current AIR rules

air_recheck_tier
Destructive

Re-check an assessment's EU AI Act tier using existing facts and current AIR rules, returning previous and new tiers plus questions that can still change the result.

Instructions

Re-check a scan's EU AI Act tier under the current AIR rules from the facts it already holds. Reads no documents and spends no credit. Returns previousTier, the new tier, and the questions that can still change it. Requires assessments:write.

Input Schema

NameRequiredDescriptionDefault
assessmentPidYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.4

TDQS

A4.2/5.0
Behavior4/5

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

Annotations declare readOnlyHint=false and destructiveHint=true; the description is consistent, implying the stored tier is recalculated and revealing previousTier plus the new tier. It adds genuinely useful context beyond annotations: an explicit permission requirement ('Requires assessments:write') and zero credit cost. It does not explicitly state that the prior stored tier is overwritten, which is why destructiveHint is only partly explained.

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?

Three short sentences with zero filler, moving from what it does, to cost/no-document behavior, to return values and permission requirement. Front-loaded and efficient.

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?

With no output schema, the description usefully enumerates the return shape (previousTier, the new tier, and open questions that can still change it) and states the auth requirement. The only omission is any explanation of assessmentPid's expected format.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the single parameter assessmentPid is never mentioned in the description. However, the name is largely self-explanatory and there is only one required parameter, so the gap is small rather than fatal.

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 gives a specific verb and resource ('re-check a scan's EU AI Act tier'), plus the source of truth ('from the facts it already holds') and the ruling basis ('current AIR rules'). It is clearly distinguishable from heavy siblings like air_run_full_assessment_pipeline or air_retry_assessment.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It implicitly but strongly routes usage: 'reads no documents and spends no credit' tells the agent this is the cheap path when facts already exist, which naturally excludes the full pipeline. It stops short of naming an explicit alternative or exclusion condition, so it is not a 5.

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