Skip to main content
Glama

A1RO — Irish employment tools

About A1RO

about_a1ro
Read-onlyIdempotent

What A1RO's products do and cost: A1ROTime (timesheets, payroll calculation and invoicing for staffing agencies), A1ROMatch, A1ROHire, SafeHandle (online manual handling training) and the AI screening bot.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the agent knows this is a safe, closed-world read. The description adds useful scope by enumerating the product catalogue and mentioning cost/pricing content, but says nothing about the shape or depth of the response. With annotations carrying the safety profile, this is reasonable but not rich.

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?

A single sentence with the core content front-loaded ('What A1RO's products do and cost'), followed by the product list. Every item in the list aids recognition of coverage. Slightly list-heavy but no wasted clauses or filler.

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 zero-parameter 'about' tool with no output schema, the description covers what an agent needs: the subject matter (products and pricing) and the breadth of the portfolio. It could note whether the response includes contact or licensing details, but nothing essential for correct invocation 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?

The tool takes zero parameters, so there is no parameter semantics for the description to explain. Baseline 4 applies; the description correctly avoids inventing inputs.

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 specific informational resource: what A1RO's products do and cost, naming each product line (A1ROTime, A1ROMatch, A1ROHire, SafeHandle, AI screening bot). It is clearly distinct from the sibling tools, which perform concrete lookups and calculations. It lacks an explicit verb like 'Returns', but the scope is unmistakable.

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?

Usage is only implied: an agent can infer this is the tool for orienting itself on A1RO's product portfolio and pricing. There is no explicit statement of when to call it versus the sibling tools, nor any exclusion or prerequisite. Adequate but leaves routing to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources