Skip to main content
Glama

clausely

Check compliance obligations

check_compliance_obligations
Read-onlyIdempotent

Runs Clausely's compliance risk check for a UK business. Takes answers about how the business uses AI, its size, sector, and data handling, and returns which obligations are likely to apply under the EU AI Act, the Worker Protection Act 2024, and UK GDPR, plus which Clausely pack matches. Results are derived from the answers given, and any pack purchased afterwards is generated from the business's own declared circumstances rather than a generic template. Use this when someone wants to know whether a regulation applies to their specific business rather than reading general guidance.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
aiUsageYesDoes the business use AI tools? regular, occasional, or none.
aiPolicyNoDoes the business have a written AI policy?
headcountNoNumber of people working in the business.
aiUseCasesNoAll the ways AI is used. Empty or ['none'] if none apply.
euExposureYesAre any customers, users, or staff based in the EU?
businessTypeNoSector that best describes the business.
aiActReadinessNoHow prepared is the business for the EU AI Act deadline?
harassmentPolicyNoDoes the business have a written workplace harassment policy?

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already mark the tool readOnly and idempotent. The description adds meaningful context beyond that: results are 'derived from the answers given' and any purchased pack is generated from the business's declared circumstances 'rather than a generic template.' This clarifies the deterministic, input-driven nature of the tool.

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 sentences, each earning its place: the first defines what the tool does, the second clarifies behavior and downstream implications, and the third gives usage guidance. It is front-loaded with the tool's main purpose and avoids redundancy.

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?

The description covers the tool's purpose, inputs at a category level, output, and usage context, which is sufficient given 100% schema coverage and no output schema. It could have sketched the response format, but the key decision-relevant information is present.

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 description coverage is 100%, so the schema already documents every parameter. The description adds useful categorization—AI use, size, sector, and data handling—but does not provide additional semantics for individual parameters beyond what the schema supplies.

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 names a specific verb and resource: 'Runs Clausely's compliance risk check for a UK business.' It clearly states the output—which obligations apply under EU AI Act, Worker Protection Act 2024, and UK GDPR, plus a matching pack—and is distinct from sibling tools that fetch articles or list packs.

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?

The description explicitly says 'Use this when someone wants to know whether a regulation applies to their specific business rather than reading general guidance.' This gives a clear decision rule, though it does not name the specific sibling tool or content type to use instead.

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.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool targets a distinct action and resource: checking obligations, retrieving a blog article or pack, listing articles or packs, and getting partner programme details. The slight overlap between check_compliance_obligations and list_compliance_packs is resolved by the descriptions: one is a diagnostic based on user answers, the other is a catalogue listing.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern using check, get, and list. The pattern makes the action and object immediately predictable across the entire set.

Tool Count5/5

Six tools is well-scoped for the apparent domain: compliance risk checking, pack catalogue access, blog content retrieval, and partner information. Each tool earns its place with no redundant or excessive additions.

Completeness5/5

The tool set covers the full informational journey: check which obligations apply, browse and inspect packs, read relevant articles, and learn about the partner programme. There are no obvious dead ends for the intended non-transactional scope.

Resources