Ansvar: EU Compliance & Legal Intelligence

Get My Capabilities

get_my_capabilities

Read-only

Tier, capabilities, limits, and live usage for the calling identity. Use this to decide what tools and fan-out paths are available before calling them, or to check remaining quota before issuing more requests — lower-tier agents can avoid wasted retries and decide whether to upgrade mid-conversation rather than discover limits by hitting walls. Visible to all tiers; takes no arguments. Returns a JSON document with: tier (free/solo/premium/team/company), capabilities (workflows, audit_ledger, include_premium_fanout — bool flags from ADR-026 §2 and ADR-032 §1), limits (max_concurrent_jobs, daily_quota — map tool→limit from ADR-028 §4, listing only tools your tier, scopes, and actor policy admit), with daily_quota_note when tool rows share a budget. At the free tier, the provision-body lookups (get_provision, validate_citation) share one 200 calls/day budget; daily_quota_note names every tool on it. usage_today (active_concurrent_calls, remaining_quota — map tool→remaining, both read live from the configured cap store; team/company budgets pool per organisation, so seats of one org see a shared remaining number), documents (Team and Company only: count, cap and remaining for your organisation's registered-document library, read live from the document service; count and remaining are null with an unavailable_reason when that read fails, never zero), tool_surface (tool_count and a 16-character fingerprint of the caller-scoped tools/list, computed_at in UTC, and a refresh_hint for detecting a stale client-side tool cache), workflow_discovery (present only when you can start a run — the three calls that take you from here to a running workflow: list_workflow_types for the live type ids, describe_capabilities for the catalog, start_workflow to begin; the type ids come from that call, never from this one), upgrade_url (empty for company tier, otherwise the marketing page that explains the next tier up), and service_notices — subsystems currently in a known degraded state, each naming the exact affected tools/add-ons and the reason those tools return, so an advertised capability that is temporarily down is never a surprise (empty list when everything is healthy). Counters reset at UTC midnight. With Redis configured, daily quota and concurrency are shared across workers and replicas; adding workers does not multiply the allowance. Development without Redis uses in-memory counters local to each process.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedJul 31, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false. The description goes far beyond that by detailing counter reset at UTC midnight, behavior under Redis (shared counters, no multiplication with workers), failure handling for document service (returns null and reason instead of zero), and service_notices for degraded state. This is rich behavioral context that an agent needs, fully disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely long (~400 words) for a no-parameter tool, far beyond what is typically needed. While it is front-loaded with the main purpose and each sentence adds informational value, it is not 'appropriately sized' – details like development-without-Redis configuration and worker semantics could be trimmed. The structure is good (it flows from purpose to fields to limits), but it lacks conciseness.

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?

The tool has an output schema, but the description still explains every returned field (tier, capabilities, limits, usage_today, documents, tool_surface, workflow_discovery, upgrade_url, service_notices). It covers edge cases (null with unavailable_reason, team/company pooling, budget sharing) and provides the full context an agent needs to interpret the response. Nothing 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 has zero parameters and the schema confirms an empty object. The description explicitly says 'takes no arguments', which is all that is needed. Since there are no parameters to document, the baseline 4 is appropriate – the statement adds clarity without redundancy.

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 clearly states the tool returns 'Tier, capabilities, limits, and live usage for the calling identity' – a specific verb and resource. It also names the sibling tools that share the same budget (get_provision, validate_citation), preventing confusion with other metadata endpoints. The purpose is unambiguous and distinct.

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?

The description explicitly tells the agent when to call it: 'Use this to decide what tools and fan-out paths are available before calling them, or to check remaining quota before issuing more requests'. It also explains why (avoid wasted retries, decide whether to upgrade) and that it takes no arguments. This is direct guidance on when and why to use this tool instead of siblings.

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

All Ansvar: EU Compliance & Legal Intelligence tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.