Skip to main content
Glama

Velvoite — EU Financial Regulatory Compliance

get_company_profile

Read-only
Get the calling company's regulatory posture — saved entity types,
actor roles per regulation, and active conditions.

The profile defines WHICH regulations and roles apply to this company.
Use the actor_roles to filter obligations with get_obligations(actor_role=...).

The profile is the baseline — you can extend beyond it using get_actor_roles()
to discover additional roles if your analysis suggests they may be relevant.

If the profile is empty (profile_complete=false), the company hasn't completed
onboarding yet. Guide them to set up their profile at app.velvoite.eu/account.

No parameters needed — the profile is determined by the API key.

Returns:
    company_name: Company name
    jurisdictions: Active jurisdictions (always includes 'eu')
    profile:
        entity_types: List of entity type codes (e.g. ['credit_institution'])
        actor_roles: Dict of regulation_code -> list of role codes
            (e.g. {'dora': ['financial_entity'], 'ai_act': ['ai_deployer']})
        conditions: Dict of regulation_code -> list of active conditions
            (e.g. {'dora': ['uses_ict_third_party'], 'ai_act': ['always']})
    profile_complete: Whether the company has selected at least one actor role

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

TDQS

A5/5.0
Behavior5/5

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

Annotations declare readOnlyHint=true, and the description adds meaningful context: the profile is determined by the API key, profile_complete=false indicates incomplete onboarding, and the profile serves as a baseline. It also details the returned structure. No contradiction with annotations.

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?

The description is front-loaded with a clear purpose, then provides structured usage guidance, edge-case handling, and a detailed return section. Every sentence adds value, and the length is justified by the complexity of the return object.

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 description comprehensively covers the tool's role within a workflow, its output structure with examples, the meaning of profile_complete, and what to do in the incomplete case. It pairs well with the existing output schema (or provides sufficient detail if none exists).

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?

There are zero parameters, and the description explicitly states this and explains why ('No parameters needed — the profile is determined by the API key.'). This exceeds the baseline for 0-param tools by adding clarity about authentication context.

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's purpose: retrieving the calling company's regulatory posture (entity types, actor roles, conditions). It also distinguishes itself from siblings like get_obligations and get_actor_roles by explaining how the profile relates to them.

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 explains when to use this tool ('The profile defines WHICH regulations and roles apply'), how to use it for filtering obligations, and when to consider get_actor_roles for extension. It also provides guidance for the incomplete profile case, directing the agent to help the user complete onboarding.

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.3/5.0
Disambiguation4/5

Each tool targets a distinct resource (obligations, documents, enforcement, Finnish statutes, CJEU cases) with clear parameter differences. Minor overlap exists between get_obligations and get_canonical_obligations, but descriptions explicitly differentiate them.

Naming Consistency5/5

All tools consistently use verb_noun patterns: get_ for retrievals, search_ for queries, list_documents, and audit_taxonomy. No mixed casing or inconsistent verb styles are present.

Tool Count2/5

At 26 tools, the surface exceeds the 25-tool threshold for 'too many'. While the domain is broad, the large number of specialized search/get tools could be consolidated without losing functionality.

Completeness4/5

The API covers the full regulatory compliance workflow: company profile, obligations, deadlines, documents, enforcement, and multiple legal sources (EU, Finnish, CJEU). Some Finnish/KHO tools return URLs requiring web fetch rather than direct data, which is a minor but by-design gap.

Resources