Velvoite — EU Financial Regulatory Compliance
Server Details
EU financial regulatory monitoring: DORA, MiCA, MiFID II, AML, Solvency II and more.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.6/5 across 16 of 16 tools scored. Lowest: 3.9/5.
Most tools have distinct purposes with clear boundaries, such as get_obligations for raw obligations versus get_canonical_obligations for deduplicated ones. However, some overlap exists between get_enforcement_intelligence and get_canonical_obligations, as both involve enforcement data, which could cause mild confusion.
All tool names follow a consistent verb_noun pattern using snake_case, such as get_actor_roles, list_documents, and search_regulations. This uniformity makes the tool set predictable and easy to navigate.
With 16 tools, the count is slightly high but reasonable for the broad domain of EU financial regulatory compliance, covering obligations, documents, enforcement, and profiles. It might feel heavy but each tool appears to serve a specific function.
The tool set provides comprehensive coverage of the compliance domain, including CRUD-like operations for obligations and documents, enforcement tracking, deadlines, profiles, and audit tools. There are no obvious gaps, supporting end-to-end workflows.
Available Tools
16 toolsaudit_taxonomyARead-onlyInspect
Audit the actor role taxonomy: compare model-defined roles vs deployed roles in the database.
Returns per-regulation analysis showing:
- model_only: roles the enrichment model can produce but aren't in the DB yet (gap)
- deployed_only: roles in the DB but not in the model (unexpected — data quality issue)
- role_counts: each deployed role with obligation count
- known_issues: overlaps, naming issues, investigation items
Use this for QA validation of the actor role taxonomy.
Requires admin API key.
No parameters needed — returns full corpus audit.| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true; description adds critical behavioral context including authentication requirements ('Requires admin API key') and detailed output semantics (explaining that 'model_only' indicates gaps while 'deployed_only' indicates data quality issues). Does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Efficiently structured with purpose front-loaded, followed by detailed return value documentation using bullet points for scanability, then usage context and requirements. Every sentence provides unique information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters and an output schema exists, the description appropriately focuses on explaining the audit methodology, return value semantics, and access control rather than parameter mechanics. Covers all necessary context for a specialized QA tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0 parameters. Description explicitly confirms 'No parameters needed — returns full corpus audit,' which meets the baseline expectation for parameterless tools and prevents confusion about missing arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with specific verb+resource: 'Audit the actor role taxonomy' and immediately clarifies the scope ('compare model-defined roles vs deployed roles'). Distinct from sibling 'get_actor_roles' by focusing on comparative QA analysis rather than simple retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use this for QA validation of the actor role taxonomy.' Includes prerequisite restriction ('Requires admin API key') acting as an implicit exclusion. Lacks explicit naming of alternatives (e.g., 'use get_actor_roles for standard retrieval'), but the admin requirement and QA focus provide clear contextual boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_actor_rolesARead-onlyInspect
Get available actor roles per regulation with obligation counts.
Actor roles define WHO an obligation applies to within a specific regulation
(e.g. 'credit_institution', 'significant_institution' for CRD/CRR, or
'ai_provider', 'high_risk_deployer' for AI Act).
Use this to discover which roles exist before filtering obligations with
get_obligations(actor_role=...).
Returns roles grouped by regulation, sorted by obligation count.
Each role includes a human-readable label and description.
Args:
regulation: Filter to a specific regulation code (e.g. 'dora', 'ai_act'). If omitted, returns roles for all regulations.| Name | Required | Description | Default |
|---|---|---|---|
| regulation | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds valuable behavioral context beyond readOnlyHint annotation: specifies that returns are 'grouped by regulation, sorted by obligation count' and include 'human-readable label and description'. Minor gap regarding pagination or rate limiting prevents a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Efficiently structured across four logical blocks: operation summary, domain concept explanation with examples, usage guidance, and parameter documentation. No redundant or wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately covers the necessary context: domain terminology, return structure (grouping/sorting), and filtering semantics. Sufficient for correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the Args section fully compensates by explaining the regulation parameter filters to specific codes, providing concrete examples ('dora', 'ai_act'), and documenting the default behavior when omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with specific verb-resource combination ('Get available actor roles per regulation') and includes scope detail ('with obligation counts'). Distinguishes from sibling get_obligations by defining actor roles conceptually and explaining their relationship to obligations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly prescribes workflow: 'Use this to discover which roles exist before filtering obligations with get_obligations(actor_role=...)'. Names the sibling tool directly and clarifies the sequencing of calls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_canonical_obligationsARead-onlyInspect
Get deduplicated canonical obligations with enforcement intelligence.
Returns one obligation per unique legal requirement per actor role.
Each includes compliance difficulty, guidance, and enforcement metrics.
Use this instead of get_obligations when you want a clean, deduplicated
view of what a regulated entity must comply with, enriched with
enforcement risk data.
Args:
regulation: Filter by regulation code (e.g. 'dora', 'mica', 'aml').
actor_role: Comma-separated actor roles (e.g. 'credit_institution,significant_institution').
entity_type: Filter by entity type code (e.g. 'credit_institution').
compliance_difficulty: Filter by difficulty: 'low', 'medium', 'high', 'critical'.
min_enforcement_count: Only return obligations with at least this many enforcement actions.
sort: Sort order. Options: 'enforcement_count_desc' (default), 'compliance_difficulty_desc', 'regulation', 'actor_role'.
page: Page number (default 1).
per_page: Results per page (default 20, max 100).| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| sort | No | enforcement_count_desc | |
| per_page | No | ||
| actor_role | No | ||
| regulation | No | ||
| entity_type | No | ||
| compliance_difficulty | No | ||
| min_enforcement_count | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true; description adds valuable behavioral context about deduplication logic ('Returns one obligation per unique legal requirement per actor role') and output enrichment ('compliance difficulty, guidance, and enforcement metrics'). Does not disclose rate limits or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with purpose upfront, followed by behavioral details, explicit usage guidelines, and Args section. Every sentence serves a distinct function; no redundancy with schema titles.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description appropriately hints at return contents without over-explaining. Covers the critical deduplication logic distinguishing it from siblings. Could explicitly mention total count availability or pagination limits beyond parameter defaults.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage (only titles), but the Args section fully compensates with detailed descriptions for all 8 parameters including format examples ('dora', 'mica', 'aml'), syntax notes ('Comma-separated'), and valid enum values for sort options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with specific verb+resource ('Get deduplicated canonical obligations with enforcement intelligence') and immediately distinguishes from sibling get_obligations by emphasizing 'deduplicated' and 'enforcement intelligence' capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use this instead of get_obligations when...' providing clear sibling differentiation and when-to-use context ('clean, deduplicated view' vs presumably raw obligations).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_company_profileARead-onlyInspect
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| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations declare readOnlyHint, the description adds critical behavioral context: the profile is determined by API key (not parameters), explains the onboarding state edge case, and defines profile_complete semantics. Could mention caching or error states for a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Efficiently structured with purpose first, then usage patterns, edge case handling, and return value documentation. No redundant text; every sentence provides actionable guidance or structural clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite output schema existing, description provides comprehensive return value documentation with examples (e.g., {'dora': ['financial_entity']}) and semantic notes ('always includes eu'). Thoroughly covers the nested profile structure and completion status.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters present (baseline 4). Description adds value by explaining why no parameters are needed ('determined by the API key'), which clarifies scoping behavior beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with specific verb 'Get' and clear resource 'calling company's regulatory posture'. Distinguishes from siblings by explicitly referencing get_obligations and get_actor_roles with specific usage patterns ('Use the actor_roles to filter...', 'extend beyond it using get_actor_roles()').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit workflow guidance: use actor_roles to filter obligations, use get_actor_roles() to discover additional roles beyond the profile. Includes clear conditional logic for empty profiles (profile_complete=false) with specific remediation action (guide to app.velvoite.eu/account).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_deadlinesARead-onlyInspect
Get upcoming regulatory deadlines for compliance calendar tracking.
Returns obligations with deadlines in chronological order, annotated
with days remaining or days overdue. Essential for compliance planning.
Args:
entity_type: Filter by entity type code (e.g. 'credit_institution').
regulation: Filter by regulation code (e.g. 'dora').
days_ahead: How many days ahead to look (default 90, max 730).
include_overdue: Include past-due obligations (default true).| Name | Required | Description | Default |
|---|---|---|---|
| days_ahead | No | ||
| regulation | No | ||
| entity_type | No | ||
| include_overdue | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations indicate readOnlyHint=true, and the description adds valuable behavioral details beyond this: it specifies that results are returned in 'chronological order' and annotated with 'days remaining or days overdue.' This reveals sorting behavior and computed fields not evident in the schema or annotations. It does not contradict annotations, though it omits pagination or rate limit details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with no wasted words: a one-sentence purpose, a one-sentence return value description, a brief value statement ('Essential for compliance planning'), and a structured Args block. Information is front-loaded with the core action before details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (not shown but indicated), the description appropriately focuses on the purpose, filtering capabilities, and behavioral traits (chronological ordering) without needing to exhaustively document return fields. With four optional parameters fully documented and the read-only nature established, the description provides complete context for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage (only titles like 'Days Ahead'), the description fully compensates by documenting all four parameters in the Args section. It provides clarifying examples ('credit_institution', 'dora') and critical constraints ('max 730') that are absent from the JSON schema, effectively serving as the primary source of parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Get') and resource ('upcoming regulatory deadlines'), and immediately contextualizes it for 'compliance calendar tracking.' This distinguishes it clearly from sibling tools like get_obligations or get_canonical_obligations by emphasizing the deadline/calendar aspect rather than general obligation retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context through phrases like 'Essential for compliance planning' and 'compliance calendar tracking,' indicating when the tool is valuable. However, it lacks explicit guidance on when to use this versus siblings like get_obligations or get_obligation_summary, and does not state any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_documentARead-onlyInspect
Get full details of a specific regulatory document by its ID.
Returns the document metadata, AI summary, all classification tags,
inline obligations (up to 50 with total count), and a link to the original source.
Use the URL to access the full text on the official regulatory website (EUR-Lex, EBA, ESMA, FIN-FSA).
Get the document_id from search_regulations or list_documents results.
Args:
document_id: The Velvoite document ID (integer from search/list results).| Name | Required | Description | Default |
|---|---|---|---|
| document_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover read-only safety (readOnlyHint: true). Description adds valuable behavioral context beyond annotations: specific return structure (metadata, AI summary, tags, obligations), pagination limits ('up to 50 with total count'), and external source domains (EUR-Lex, EBA, ESMA, FIN-FSA). Does not mention error cases or rate limits, preventing a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear information hierarchy: purpose → return value details → usage guidance → parameter definition. The enumerated return fields (metadata, AI summary, etc.) justify the length. Minor deduction for slight verbosity in listing external sources, but every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (which reduces descriptive burden), the description comprehensively details what the tool returns, including behavioral limits (50 obligations) and external references. For a single-parameter retrieval tool with rich output, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by documenting the parameter in the Args section: specifies it is a 'Velvoite document ID', an integer, and crucially explains provenance ('from search/list results'). This semantic context (where to get the ID) is essential for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with specific verb ('Get') + resource ('regulatory document') + scope ('full details by ID'). It clearly distinguishes from siblings like search_regulations and list_documents by emphasizing ID-based retrieval and explicitly naming those tools as sources for the document_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit prerequisite guidance: 'Get the document_id from search_regulations or list_documents results.' Also guides usage of results ('Use the URL to access the full text'). Could be improved by explicitly stating when NOT to use (e.g., 'do not use for searching'), but the prerequisite instruction effectively implies the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_enforcement_decisionsARead-onlyInspect
Get enforcement decisions with structured penalty data.
Returns enforcement actions (fines, warnings, license withdrawals) imposed
by regulators. Each action includes penalty amount, sanctioned entity,
violation categories, and appeal status.
Use this to answer questions like:
- "What fines has FIN-FSA given to credit institutions?"
- "What are the largest penalties for AML violations?"
- "Has anyone been fined for ICT risk management failures?"
- "What's the total penalty exposure for my entity type?"
Combine with get_company_profile to find enforcement actions relevant
to the caller's entity type and regulations.
Args:
regulation: Filter by regulation code (e.g. 'aml', 'dora', 'mifid2', 'gdpr', 'crd_crr').
entity_type: Filter by sanctioned entity type (e.g. 'credit_institution', 'investment_firm', 'crypto_service').
authority: Filter by sanction authority (e.g. 'FIN-FSA', 'ECB', 'Data Protection Ombudsman').
penalty_min: Minimum penalty amount in EUR (e.g. 1000000 for fines >= EUR 1M).
violation_category: Filter by violation type (e.g. 'aml_cdd', 'ict_risk', 'sca', 'governance', 'conduct').
page: Page number (default 1).
per_page: Results per page (default 20, max 100).| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| per_page | No | ||
| authority | No | ||
| regulation | No | ||
| entity_type | No | ||
| penalty_min | No | ||
| violation_category | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, confirming safe read operations. The description adds valuable behavioral context about return content (penalty amount, sanctioned entity, violation categories, appeal status) that annotations don't cover. Does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with logical flow: purpose → return data → usage examples → cross-tool reference → parameters. Front-loaded with clear action statement. Minor verbosity in four example questions, but they serve legitimate guideline purposes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (not shown but indicated in context), the description appropriately focuses on query capabilities and data highlights rather than return structure. Coverage is complete for a 7-parameter filtering tool with optional cross-tool integration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage (only titles present), the Args section comprehensively compensates by documenting all 7 parameters with rich examples (e.g., regulation codes like 'aml', 'dora', 'mifid2'; entity types like 'credit_institution'). Essential semantics for filtering are fully provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Get enforcement decisions with structured penalty data' and specifies the exact resource (enforcement actions including fines, warnings, license withdrawals). It distinguishes from sibling get_enforcement_intelligence by focusing on structured penalty data and specific decision attributes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage patterns through four concrete example questions (e.g., 'What fines has FIN-FSA given to credit institutions?'). Explicitly names cross-tool workflow: 'Combine with get_company_profile to find enforcement actions relevant to the caller's entity type and regulations.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_enforcement_intelligenceARead-onlyInspect
Get top enforced canonical obligations. Returns obligations ranked by
enforcement activity for risk prioritization.
This is a focused view of canonical obligations filtered to only those
with at least one enforcement action. Use this to identify which
obligations regulators are actively enforcing.
Args:
regulation: Filter by regulation code (e.g. 'dora', 'mica', 'aml').
actor_role: Comma-separated actor roles (e.g. 'credit_institution,significant_institution').
entity_type: Filter by entity type code (e.g. 'credit_institution').
compliance_difficulty: Filter by difficulty: 'low', 'medium', 'high', 'critical'.
min_enforcement_count: Minimum enforcement actions (default 1 — only enforced obligations).
sort: Sort order (default 'enforcement_count_desc').
page: Page number (default 1).
per_page: Results per page (default 20, max 100).| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| sort | No | enforcement_count_desc | |
| per_page | No | ||
| actor_role | No | ||
| regulation | No | ||
| entity_type | No | ||
| compliance_difficulty | No | ||
| min_enforcement_count | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare read-only safety, allowing the description to focus on domain logic. Adds valuable context about ranking methodology ('ranked by enforcement activity'), default filtering behavior ('only enforced obligations'), and pagination constraints ('max 100').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Efficiently structured with purpose statement first, differentiation second, use case third, followed by comprehensive Args documentation. No redundant text; every sentence provides actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description appropriately focuses on input parameters and filtering logic. Covers all 8 optional parameters with business context (e.g., explaining that min_enforcement_count defaults to 1 to enforce the 'enforced only' constraint).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by documenting all 8 parameters with examples (e.g., 'dora', 'mica', 'aml' for regulation) and valid value ranges ('low', 'medium', 'high', 'critical' for compliance_difficulty). Essential for agent to construct valid calls.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States specific action ('Get top enforced canonical obligations'), resource type, and business purpose ('risk prioritization'). Clearly distinguishes from sibling 'get_canonical_obligations' by noting this is a 'focused view' filtered to obligations 'with at least one enforcement action.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use ('identify which obligations regulators are actively enforcing') and implicitly distinguishes from the broader 'get_canonical_obligations' by emphasizing the enforcement filter. Lacks explicit 'when not to use' or named alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_feedbackARead-onlyInspect
Get user feedback for QA review. Requires admin API key.
Filters: status (new/reviewed/resolved/dismissed), feedback_type (data_quality/bug/feature_request/other),
context_type (document/obligation/general).| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| status | No | ||
| context_type | No | ||
| feedback_type | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds critical auth requirement not in annotations. Enumerates valid filter values (new/reviewed/resolved/dismissed, etc.) that constrain input behavior, supplementing the annotations (readOnlyHint/openWorldHint) with domain-specific constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely efficient two-line structure: first line establishes purpose and auth, second line lists filters with values. No redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and safety annotations, the description adequately covers the essentials: purpose, authentication, and filter semantics. Only minor gap is omission of 'limit' parameter description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by documenting three of four parameters (status, feedback_type, context_type) including their valid enum values. Only omits the 'limit' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States specific action ('Get') and resource ('user feedback') with context ('for QA review'). Clearly distinct from sibling retrieval tools like get_document or get_obligations, though it could explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides authentication prerequisite ('Requires admin API key'), but lacks explicit guidance on when to use this versus other retrieval tools or what triggers a need for QA review.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_obligationsARead-onlyInspect
Get regulatory obligations - specific requirements extracted from regulations.
Each obligation includes the requirement text, applicable article reference,
deadline, which entity types it applies to, actor roles, and current status.
Results are paginated (max 50 per page).
Supports keyword search via the query parameter (trigram + ILIKE matching on obligation text).
Combine with regulation, entity_type, and actor_role filters for precise results.
Set canonical=True to get deduplicated canonical obligations with enforcement
intelligence instead. Canonical obligations return one entry per unique legal
requirement per actor role, with compliance difficulty and enforcement metrics.
Use get_actor_roles first to discover available actor roles per regulation.
Args:
entity_type: Filter by entity type code (e.g. 'credit_institution', 'payment_institution').
regulation: Filter by regulation code (e.g. 'dora', 'mica', 'aml').
status: Filter by status: 'upcoming', 'active', 'overdue', or 'expired'.
query: Keyword search on obligation text (e.g. 'ICT risk', 'strong customer authentication').
actor_role: Comma-separated actor roles to filter by (e.g. 'credit_institution,significant_institution'). Use get_actor_roles to see available roles.
canonical: If True, return deduplicated canonical obligations with enforcement intelligence instead of raw obligations.
page: Page number (default 1).
per_page: Results per page (default 20, max 50).| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| query | No | ||
| status | No | ||
| per_page | No | ||
| canonical | No | ||
| actor_role | No | ||
| regulation | No | ||
| entity_type | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true; description adds pagination limits (max 50), search algorithm details (trigram + ILIKE), and distinct behavioral modes (canonical vs raw obligations). Adds context about enforcement intelligence and compliance difficulty in results without contradicting safety annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear progression: purpose → result contents → search/pagination → canonical mode → prerequisites → parameter reference. Every sentence provides unique information; no repetition of schema or annotation data.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, complex filtering logic, and existence of output schema, description appropriately covers all operational modes (canonical vs raw), prerequisite workflows, and result characteristics without redundant return value documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the Args section comprehensively compensates by documenting all 8 parameters with data types, examples (e.g., 'credit_institution', 'dora'), and format constraints (comma-separated, max 50). No ambiguity remains.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with specific verb+resource ('Get regulatory obligations') and clarifies scope ('specific requirements extracted from regulations'). Effectively distinguishes from sibling get_canonical_obligations by explaining the canonical parameter as an alternative mode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit prerequisite ('Use get_actor_roles first'), explains when to use canonical=True versus default mode, and advises combining filters for precise results. Lacks explicit 'when not to use' guidance comparing to siblings like search_regulations or get_canonical_obligations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_obligation_summaryARead-onlyInspect
Get obligation counts grouped by regulation_code.
Returns total count and per-regulation breakdown with status counts
(active, upcoming, overdue, expired) plus verified and with_deadline counts.
No full obligation text — just counts for a quick overview.
Args:
entity_type: Filter to obligations applying to this entity type (e.g. 'credit_institution', 'payment_institution').
actor_role: Comma-separated actor roles to filter by (e.g. 'financial_entity,credit_institution').
Use get_company_profile to see the company's roles, or get_actor_roles to browse all available roles.| Name | Required | Description | Default |
|---|---|---|---|
| actor_role | No | ||
| entity_type | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true (safe read), so the description adds valuable behavioral context by detailing the return payload structure (per-regulation breakdown with specific status counts) and explicitly noting exclusions (no full obligation text). No contradictions 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with purpose first, return value specification second, scope limitations third, and parameter details last. Every sentence provides distinct value—no repetition of the tool name or tautology. The Args section is appropriately detailed without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema (not shown but indicated), the description appropriately summarizes rather than fully specifies return values. Both parameters are thoroughly documented despite zero schema coverage, and prerequisite workflows (discovering actor roles) are addressed via sibling tool references.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries the full documentation burden and excels: it explains entity_type filtering with concrete examples ('credit_institution'), clarifies actor_role formatting ('Comma-separated'), and provides discovery mechanisms via cross-references to get_company_profile and get_actor_roles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Get') and clearly identifies the resource (obligation counts) plus the grouping key (regulation_code). It distinguishes itself from sibling 'get_obligations' by explicitly stating 'No full obligation text — just counts,' clarifying this returns aggregations rather than complete records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool ('quick overview' vs full details) and provides explicit prerequisites by naming specific sibling tools ('Use get_company_profile... or get_actor_roles') for discovering valid parameter values. It lacks an explicit 'when not to use' contrast with get_obligations, though the limitation is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_recent_changesARead-onlyInspect
Get recently published or updated regulatory documents.
Shortcut for 'what is new this week' - returns documents from the last N days,
sorted by publication date (newest first). Useful for weekly regulatory briefings.
Args:
days: Look back N days (default 7).
entity_type: Filter by entity type code.
regulation: Filter by regulation family code.
urgency_max: Only include items at or above this urgency (1=critical, 2=high, etc.).| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| regulation | No | ||
| entity_type | No | ||
| urgency_max | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations establish readOnlyHint=true (safe read). The description adds valuable behavioral details beyond annotations: sorting behavior ('sorted by publication date, newest first') and the urgency scale semantics ('1=critical, 2=high, etc.'). Does not mention pagination or caching, but provides more behavioral context than typical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with front-loaded purpose statement followed by use case explanation and structured Args section. No redundant text; every sentence serves to clarify tool selection or parameter usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (per context signals), the description appropriately omits return value details. With 4 parameters fully documented in the Args section and clear behavioral scope, the description is complete for this tool's complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates via the Args section. It documents all 4 parameters (days, entity_type, regulation, urgency_max) with clear semantics, including the default for days (7) and the urgency scale mapping (1=critical), which is critical for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get recently published or updated regulatory documents' with specific verb and resource. It further distinguishes itself from siblings like search_regulations or list_documents by emphasizing the temporal focus ('recently', 'last N days', 'what is new this week').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context ('Useful for weekly regulatory briefings', 'Shortcut for what is new this week') implying when to select this tool. However, it lacks explicit 'when not to use' guidance or named sibling alternatives despite the 'Shortcut' phrasing implying their existence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_statsARead-onlyInspect
Get an overview of the Velvoite regulatory corpus.
Returns document counts by source, regulation family, entity type, urgency distribution, obligation summary, and date range.
Call this FIRST to orient yourself before running queries. No parameters needed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations declare readOnlyHint=true, the description adds valuable behavioral context by detailing exactly what the overview contains: document counts by source, regulation family, entity type, urgency distribution, obligation summary, and date range. This specifics what would otherwise be an opaque 'overview' return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences efficiently cover purpose, return value structure, usage guidelines, and parameter status. Each sentence provides distinct information without redundancy, creating a well-structured, front-loaded description that agents can scan quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (zero parameters, read-only), the presence of an output schema, and the description's enumeration of return fields (counts, distributions, summaries), the definition is complete. The guidance to 'Call this FIRST' appropriately contextualizes it within the broader tool suite.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage of the empty object, the description appropriately confirms 'No parameters needed,' aligning with the schema. This meets the baseline expectation for parameter-less tools by explicitly acknowledging the lack of inputs rather than leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific action 'Get' and resource 'overview of the Velvoite regulatory corpus.' It distinguishes itself from sibling query tools (like search_regulations or get_document) by positioning itself as a high-level aggregation tool that returns counts and distributions rather than specific records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Call this FIRST to orient yourself before running queries,' providing clear temporal guidance on when to use the tool. This implicitly defines the alternative workflow (direct querying) and establishes this as a prerequisite discovery step for unfamiliar users.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_verification_statsARead-onlyInspect
Get verification progress for obligations across all regulations.
Returns total, verified, unverified counts overall and per regulation, with percentage verified. Use this to track human review progress. No parameters needed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true. Description adds valuable behavioral context by detailing return structure (total/verified/unverified counts, percentages) and clarifying the domain purpose (tracking human review). No contradictions 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences efficiently structured: purpose, return values, usage context, and parameter note. No redundancy or filler. Information is front-loaded with the specific action in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, readOnly annotations, and an output schema exists, the description provides sufficient completeness. It summarizes return values appropriately without needing to fully document the output schema structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters. Description explicitly states 'No parameters needed,' which confirms the schema structure. With 100% schema coverage of an empty parameter set, this meets the baseline for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Get' with clear resource 'verification progress' and scope 'obligations across all regulations'. It distinguishes itself from sibling 'get_stats' by specifying 'verification' and 'human review progress' rather than general statistics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context 'Use this to track human review progress' which clarifies the tool's purpose. However, it lacks explicit when-not-to-use guidance or direct comparison to sibling 'get_stats' for alternative statistical needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_documentsARead-onlyInspect
Browse regulatory documents with filters and pagination.
Returns a paginated list of documents with summaries, tags, doc_purpose
(regulation_text, enforcement, reference, irrelevant), and doc_jurisdictions
(e.g. ['eu'], ['fi'], ['de']).
Use this for filtered browsing (e.g. all DORA documents from the last 30 days).
Use search_regulations instead when you have specific keywords to search for.
Args:
source: Filter by data source code: eur_lex, eba, esma, eiopa, finfsa, bafin.
regulation: Filter by regulation family code: dora, mica, aml, mifid2, crd_crr, psd, csrd, sfdr, ai_act, emir, solvency, idd, gdpr.
entity_type: Filter by entity type: credit_institution, payment_institution, e_money, investment_firm, fund_manager, aifm, insurance, pension, crypto_service, crowdfunding, credit_servicer.
urgency_max: Max urgency level (1=critical, 2=high, 3=medium, 4=low, 5=informational). E.g. 2 returns only critical and high urgency items.
days: Only return documents from the last N days (1-365).
page: Page number (default 1).
per_page: Results per page (default 20, max 100).| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| page | No | ||
| source | No | ||
| per_page | No | ||
| regulation | No | ||
| entity_type | No | ||
| urgency_max | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations confirm the read-only nature, the description adds valuable behavioral context by detailing the return structure (paginated list with summaries, tags, doc_purpose types, and jurisdiction formats) and explaining the urgency_max scale (1=critical through 5=informational). This helps the agent understand what data structure to expect and how to interpret the results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with the core purpose upfront, followed by return value details, usage guidelines, and parameter documentation. While the Args section is lengthy due to listing enum values, this is necessary given the schema lacks descriptions and enums, making the overall size appropriate for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description appropriately summarizes the return format without redundancy, while thoroughly covering parameter semantics and sibling differentiation. The documentation adequately supports the 7-parameter filtering interface despite the schema's lack of descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates comprehensively by documenting all seven parameters in the Args section, including valid values for source codes (eur_lex, eba), regulation families (dora, mica), entity types, and constraints like days (1-365) and per_page (max 100).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific action 'Browse regulatory documents' and clearly identifies the tool's scope as filtered browsing with pagination. It effectively distinguishes itself from the sibling tool by explicitly stating 'Use search_regulations instead when you have specific keywords to search for.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance by contrasting it with the alternative tool, stating when to use 'filtered browsing' versus keyword search. It includes a concrete example ('all DORA documents from the last 30 days') that clarifies the intended use case for filtering over searching.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_regulationsARead-onlyInspect
Search the regulatory corpus using keyword / trigram matching.
Uses PostgreSQL trigram similarity on document titles and summaries.
Returns documents ranked by relevance with summaries and classification tags.
Prefer list_documents with filters (regulation, entity_type, source) first.
Only use this for free-text keyword search when structured filters aren't sufficient.
Args:
query: Search terms (e.g. 'strong customer authentication', 'ICT risk', 'AML reporting').
per_page: Number of results (default 20, max 100).| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| per_page | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true (safe read). Description adds valuable behavioral context: 'PostgreSQL trigram similarity' explains the fuzzy matching algorithm, and 'Returns documents ranked by relevance with summaries and classification tags' previews the output structure. Does not mention rate limits or false positive characteristics of trigram matching, preventing a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tightly structured sentences followed by Args block. Every sentence earns its place: purpose statement, technical implementation, return format, and usage guidelines. No redundant or filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has output schema (context signals confirm), so detailed return value documentation isn't required. Description provides sufficient overview of returns ('ranked by relevance with summaries and classification tags'). Covers algorithm, parameters, usage boundaries, and safety (via annotations) completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (parameters have titles but no descriptions). Description fully compensates by documenting both parameters under 'Args:' with clear semantics and constraints: query includes concrete examples ('strong customer authentication', 'ICT risk'), per_page specifies default (20) and max (100).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with specific verb ('Search') + resource ('regulatory corpus') + method ('keyword / trigram matching'). Explicitly distinguishes from sibling 'list_documents' by stating preference for structured filters first, clarifying this tool's specific niche.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Prefer list_documents with filters... first' and 'Only use this for free-text keyword search when structured filters aren't sufficient.' Names the specific alternative tool and defines the boundary condition clearly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!