ReportingOracle — 16 regulatory reporting tools: BaFin, ESMA, FINREP, COREP, ICAAP, ILAAP.
Scored across 16 tools
Most tools target distinct report types or workflows (annual_report, incident_report, roi_export, tlpt_report), and status trackers cover different entities. However, ping and health_check serve nearly identical connectivity/server-status purposes, and approve_report could apply to multiple report kinds, creating mild ambiguity.
All tool names use snake_case, but the pattern varies: verb_noun (approve_report, get_report, sync_from_ampel) mixed with noun_forms (annual_report, incident_report, report_templates) and noun_tracker (deadline_tracker, incident_status). It remains predictable and readable, with only minor deviations.
16 tools is slightly high, but justified by the broad DORA reporting domain covering multiple report types, validation, status tracking, and obligation mapping. Each tool serves a distinct purpose, and the set does not feel bloated.
The surface covers the major DORA reporting lifecycle: generation of all key report types, validation, approval, deadlines, and submission status. Obvious gaps include no update/reject workflow for reports and no generic list_reports tool, though these can be worked around.
Annual ICT risk management report for board + NCA (Art. 6(5)). Auto-fills from AmpelOracle.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | ||
| entity_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must fully disclose behavioral traits. It states that the report auto-fills from AmpelOracle, which is useful, but it does not explain whether the tool is read-only, whether it creates or updates records, what side effects occur, or what the output is. This is insufficient for a tool that may perform a generation or submission action.
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 brief and easy to scan, but it is under-specified rather than efficiently concise. It conveys only a fragment of necessary information, so the brevity is not an asset; the sentence could earn its place by adding an action verb and parameter context.
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?
With only two simple parameters and no output schema, the tool is not highly complex, but the description fails to explain the tool's core behavior. It is unclear whether this tool creates, retrieves, or submits the report, and the relationship to sibling tools like get_report or report_templates is missing. This leaves the agent without enough context for correct 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?
The schema has two parameters (year, entity_id) with no descriptions, and the schema description coverage is 0%. The description provides no explanation of what these parameters mean, how they should be formatted, or how they relate to the report. The tool description must compensate for the lack of schema documentation, but it does not.
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 identifies the resource as an 'Annual ICT risk management report' for board and NCA, referencing a specific regulatory article, which adds context. However, it lacks an explicit verb (e.g., generate, retrieve, submit), so it does not clearly state what action the tool performs beyond being a report, and it only weakly distinguishes from sibling tools like get_report or report_templates.
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?
No guidance is provided on when to use this tool versus alternatives. The mention of 'Auto-fills from AmpelOracle' hints at a dependency but does not clarify prerequisites, exclusions, or appropriate scenarios. There is no comparison to sibling tools such as sync_from_ampel or get_report.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Approve a draft report (4-eyes). Status: draft → approved.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | Yes | ||
| report_id | Yes | ||
| approved_by | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects and requirements. It mentions the 4-eyes principle and the status change, but lacks details on failure conditions (e.g., if report is not draft), permissions needed, or whether the action is reversible. This is insufficient for a mutation tool.
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 extremely concise—two short sentences that directly convey the core action and state change. There is no redundant or filler text; every word contributes to understanding the tool's function.
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 lack of annotations and output schema, the description should cover prerequisites, return values, and potential errors. It only provides the action and status transition, leaving the agent to guess about permissions, side effects, and what a successful approval returns. This is inadequate for a mutation tool with three required parameters.
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?
The input schema has three required parameters (report_id, entity_id, approved_by) but the description provides zero explanation of their meaning. Schema description coverage is 0%, and the description does not compensate by defining any parameter roles or formats, leaving ambiguous fields like entity_id.
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 the verb 'Approve', the resource 'draft report', and the process '4-eyes'. It also defines the state transition 'draft → approved', making the tool's purpose unambiguous and distinct from sibling tools like get_report or annual_report.
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 state transition 'draft → approved' implies the tool is used when a report is in draft status, but there is no explicit guidance on when not to use it or when to prefer alternatives. No sibling tool is mentioned, so the context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
All DORA reporting deadlines per entity with days-until countdown.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | No | Optional — empty for general deadlines |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions the countdown feature but does not disclose important behavioral traits such as whether past deadlines are included, sorting order, or any side effects. The read-only nature is only implied, not stated.
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 a single concise sentence with no filler. Every word contributes to the meaning, making it appropriately front-loaded and efficient.
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?
For a simple tool with one optional parameter and no output schema, the description covers the core purpose and the countdown aspect. However, it does not explain the behavioral difference between providing an entity_id versus leaving it empty, nor the structure of the returned data beyond the countdown, leaving some gaps.
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?
The schema has 100% coverage with 'Optional — empty for general deadlines', so the baseline is 3. The description adds no additional parameter semantics; it only repeats the 'per entity' concept already present in the schema. This is adequate but not enhanced.
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 identifies the tool's purpose: providing all DORA reporting deadlines with a days-until countdown. It is implicitly distinguished from sibling tools that handle actual report content (e.g., annual_report, get_report), but it lacks an explicit verb like 'list' or 'get'.
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?
No guidance is provided on when to use this tool versus alternatives, nor are any exclusions or alternative recommendations mentioned. The optional entity_id parameter is only documented in the schema, not in the description, so the agent receives no context about when to include it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full report content by report_id.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | Yes | ||
| report_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description alone must disclose behavior. It mentions 'full report content,' implying the return value includes the complete report body, but it does not state that the operation is read-only, what happens if the report doesn't exist, or any required permissions. This lack of disclosure for a bare get operation leaves significant gaps.
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 a single, front-loaded sentence with no filler words. It communicates the core function efficiently, though it omits necessary details. This is appropriately concise for the minimal information it provides.
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?
The tool is a simple get with two parameters, but the description is too sparse to be complete. It lacks return value specification, does not explain entity_id, and offers no guidance on when to use it. Given the absence of an output schema and annotations, the description should provide more context.
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?
The schema requires both report_id and entity_id, but the description only mentions report_id, giving it no explanation. Entity_id is completely undocumented in the description, and schema description coverage is 0%, so the agent must infer its meaning from the name alone. This is a critical gap 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 identifies the tool as retrieving full report content using a report identifier. The verb 'Get' and resource 'full report content' make the primary action unambiguous. However, it does not explicitly differentiate from sibling report tools (e.g., annual_report, incident_report), so it earns a 4 rather than 5.
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 no information on when to use this tool versus the sibling alternatives. It does not specify any exclusions, prerequisites, or usage context beyond the generic 'by report_id,' leaving the agent without guidance for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Server status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. 'Server status.' reveals nothing about side effects, read-only nature, authentication requirements, return format, or error handling. It is completely opaque.
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 extremely terse, but this is under-specification rather than effective conciseness. It does not convey enough information to be useful, so the brevity fails to earn its place.
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?
Without an output schema, the description must explain what the tool returns. 'Server status.' does not describe the response structure, possible status values, or any operational details, making the tool incomplete for an agent to use correctly.
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?
The tool has zero parameters, so the baseline is 4. The description adds no parameter information, but with no parameters to document, no additional semantics are required.
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 'Server status.' is a vague restatement of the tool name, essentially paraphrasing 'health_check' without providing a specific verb or resource. It does not distinguish this tool from siblings like 'ping', which could also check server availability.
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 offers no guidance on when to use this tool versus alternatives. There is no mention of appropriate contexts, exclusions, or complementary tools, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate ITS 2024/1772 incident report for BaFin (initial/intermediate/final). Art. 19-20. Deadlines: 4h/72h/30d.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | ||
| severity | No | major|significant | |
| entity_id | No | ||
| root_cause | No | ||
| containment | No | ||
| description | No | ||
| incident_id | No | ||
| remediation | No | ||
| report_type | No | initial|intermediate|final | |
| detection_date | No | ||
| affected_clients | No | ||
| affected_services | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses regulatory deadlines and legal articles, but omits behavioral traits such as whether the tool submits the report to BaFin, whether it creates a record, prerequisites, or side effects. The word 'Generate' implies creation but is not elaborated.
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 a single, front-loaded sentence with no wasted words. It efficiently conveys the main purpose and key deadlines, though it is terse.
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 complexity (12 parameters, no annotations, no output schema), the description is insufficient. It provides the regulatory context and deadlines but does not cover the full data required for the report or the submission workflow.
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 only 17%, and the description does not explain any parameters except possibly report_type through 'initial/intermediate/final'. The 12 parameters remain largely undocumented, and the description does not compensate for the low coverage.
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 the tool's function: generating an ITS 2024/1772 incident report for BaFin, with specific report types (initial/intermediate/final). It distinguishes from sibling tools like get_report or annual_report by focusing on incident-specific reporting.
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 via deadlines (4h/72h/30d) for initial/intermediate/final reports, but does not explicitly explain when to choose this tool over alternatives like get_report or approve_report. No exclusions or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Track all incident reports per entity with deadlines and overdue status.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It mentions tracking and overdue status, implying a read operation, but does not explicitly state that it is read-only, whether any side effects occur, or what output is returned. It lacks details on permissions or behavior with no entity_id.
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 a single, concise sentence that immediately conveys the core purpose. There is no wasted verbiage, and it is appropriately sized for a simple tool with one parameter.
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 absence of annotations, output schema, and parameter descriptions, the description is not complete enough. It fails to explain return values, behavior for all or specific entity_id, or any exclusions. The tool likely needs more details to be used correctly.
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?
The input schema has one parameter (entity_id) with no description and schema coverage is 0%. The description only says 'per entity' which vaguely implies filtering, but provides no guidance on how to use the parameter, its format, or that it is optional. The description fails to compensate for the lack of schema detail.
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 indicates the tool provides status tracking for incident reports per entity, including deadlines and overdue status. It distinguishes itself from siblings like incident_report and get_report by focusing on tracking all incidents per entity with deadline/overdue information.
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 usage when one needs a list of all incident reports for an entity with deadline/overdue status, but it does not explicitly state when to use this tool versus alternatives like deadline_tracker or nca_submission_status. Context is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate management response letter to findings. 4-eyes principle.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | No | ||
| finding_ids | No | Comma-separated finding IDs (empty=all open) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The phrase '4-eyes principle' hints at a review requirement, but does not explain what this means for the agent (e.g., permissions, side effects, or whether approval is needed). The description lacks disclosure about what the tool does to findings or how the letter is generated.
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 concise (one sentence) and front-loaded with the primary purpose. However, it is under-specified and omits critical usage and parameter context, making it not appropriately sized for the tool's informational needs. It earns a 3 for brevity but not for completeness.
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 lack of annotations, output schema, and minimal parameter descriptions, the description does not provide enough context for an agent to use the tool correctly. It tells what it generates but not when to use it, what entity_id is for, or the expected output. This is a clear gap.
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?
The schema has 50% description coverage (finding_ids is described, entity_id is not). The tool description adds no clarification for either parameter and does not compensate for the missing entity_id explanation. It only mentions 'findings' generically, which does not help the agent understand the parameters.
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 the tool's action ('Generate') and resource ('management response letter to findings'), which is specific and distinguishes it from sibling tools like 'get_report' or 'annual_report'. However, it does not explicitly contrast with alternatives, so it falls short of a 5.
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 no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or context for selecting it over sibling tools like 'approve_report' or 'incident_report'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Track all NCA submissions with deadlines, status, overdue alerts.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses what is tracked (NCA submissions, deadlines, status, overdue alerts) but does not state whether the operation is read-only, any side effects, or authentication needs. It provides some context but lacks behavioral depth.
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 a single concise sentence that front-loads the action and resource, with no unnecessary words.
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?
The tool has no output schema and minimal annotations, and the description does not explain input semantics, output format, or edge cases like overdue alerts. For a status tool that may return lists or alerts, this is insufficient for an agent to invoke it correctly.
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?
The schema contains one optional parameter (entity_id) with no description, and the description does not mention it nor explain how it affects the results. With 0% schema coverage, the description completely fails to compensate for the undocumented 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?
The description clearly states a specific verb ('Track') and resource ('NCA submissions'), and mentions key aspects (deadlines, status, overdue alerts), making it distinguishable from sibling tools like deadline_tracker or get_report.
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?
No explicit guidance on when to use this tool vs alternatives; context is implied by the name and description but there is no mention of when not to use it or which sibling to prefer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reporting obligations DORA-RPT-01 to RPT-08 with deadlines and cross-jurisdiction.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It fails to disclose any behavioral traits such as return format, read-only nature, or side effects. The phrase 'Reporting obligations' implies a factual resource, but nothing about the actual behavior on invocation.
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 a single sentence with no waste. It efficiently names the specific obligation IDs and adds the deadlines/cross-jurisdiction context, but it remains under-specified for an agent trying to select the tool.
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?
With no output schema and no annotations, the description should explain what the tool returns or what 'map' means operationally. It only provides subject matter (DORA obligations, deadlines, jurisdictions) without clarifying the response or behavior, making it incomplete for an agent to use correctly.
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?
The input schema has zero parameters, so there is no need for the description to explain parameter details. The baseline for 0-param tools is 4, and the description does not need to compensate for any schema gaps.
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 names the specific resource (DORA-RPT-01 to RPT-08) and mentions deadlines and cross-jurisdiction, but it lacks a verb indicating what the tool does (e.g., 'get', 'map', 'list'). It is not a tautology, but it is vague and does not clearly distinguish from siblings like deadline_tracker or get_report.
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 no guidance on when to use this tool versus alternatives. With 15 sibling tools, the absence of any usage context or exclusion criteria leaves the agent guessing about appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connectivity test.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. 'Connectivity test.' offers no details on what the tool returns (e.g., success/failure, latency), timeout behavior, or side effects. It adds little beyond the tool name and is essentially a tautology.
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 highly concise and front-loaded, with no wasted words. 'Connectivity test.' efficiently states the purpose. However, its brevity borders on under-specification, but for a zero-parameter tool it is appropriately sized.
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 no output schema and no annotations, the description is the sole information source. It fails to explain expected results, error conditions, or what 'connectivity' refers to in the context of the sibling tools. This is insufficient for an AI agent to fully understand the tool's behavior.
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?
The tool has zero parameters and the schema confirms this, so the baseline score of 4 is appropriate. The description does not need to explain non-existent parameters, and the schema already covers the empty parameter structure.
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 the tool's function as a connectivity test. It uses a specific verb 'test' and resource 'connectivity', distinguishing it from sibling tools focused on drift detection and health checks. However, it could more explicitly contrast with the overlapping 'health_check' tool.
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 no guidance on when to use this tool versus alternatives. There is no mention of scenarios, prerequisites, or why one would choose ping over health_check or drift scans. This is a clear omission.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Available ITS/RTS report templates with mandatory fields count.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It indicates the tool returns template information but does not explicitly state that it is read-only, does not disclose output format, or whether any side effects exist. The short phrase is insufficient for transparency.
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 a single, concise sentence with no filler. It is front-loaded with the core purpose and includes the additional detail of mandatory fields count, making it highly efficient.
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?
For a simple tool with no parameters and no output schema, the description provides basic information but lacks detail about the returned data structure (e.g., list of names, table with counts). It could be more complete by elaborating on the output or use case.
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?
The tool has zero parameters, so parameter semantics are trivially handled by the empty schema. The description need not add parameter details, and the baseline for zero-parameter tools is 4.
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 indicates the tool provides available ITS/RTS report templates with the count of mandatory fields. It distinguishes from sibling tools by focusing on template listing rather than report actions, but lacks an explicit verb like 'list' or 'retrieve'.
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 usage for checking available templates before working with reports, but it does not explicitly state when to use this tool versus alternatives like get_report or annual_report. No exclusions or preferred scenarios are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate Register of Information ITS export (Art. 28(3)). Pulls providers from AmpelOracle, checks ITS mandatory fields.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses two useful behavioral traits: data source (AmpelOracle) and validation steps (checks mandatory fields). However, it does not mention side effects, permissions, output format, or whether the operation is read-only.
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?
Two concise, front-loaded sentences with no wasted words. The first sentence identifies the purpose, and the second adds key behavioral context.
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 no output schema and no annotation, the description should clarify the return value and the meaning of entity_id. It mentions mandatory field checking but is incomplete for a user who needs to know what the export looks like or how entity_id is used.
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?
The only parameter (entity_id) is not described at all in the description, and the schema provides only the type string. With 0% schema description coverage, the description should compensate, but it fails to explain what entity_id refers to or how it affects the export.
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 a specific verb ('Generate') and resource ('Register of Information ITS export'), with a legal reference (Art. 28(3)). It also mentions distinctive behaviors (pulling providers, checking mandatory fields) that separate it from siblings like roi_validate.
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 usage when an ITS export is required, but it does not explicitly state when to use this tool over alternatives like roi_validate. There is no mention of exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate Register of Information against ITS mandatory fields per provider.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It fails to indicate whether validation is read-only, what happens on invalid data, or what the return format is. The verb 'validate' implies a check, but side effects or error behavior are unspecified, leaving significant uncertainty.
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 a single, direct sentence with no fluff, earning high marks for conciseness. However, its brevity borders on under-specification, so it loses a point for being too minimal to be fully useful despite being well-structured.
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 lack of output schema, annotations, and parameter documentation, the description carries a heavy burden that it does not meet. It omits the parameter meaning, output behavior, and operational context. The tool is part of a suite with related tools, but the description provides no contextual links.
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?
The sole parameter 'entity_id' is listed in the schema with no description, and the tool description does not explain its semantics. With 0% coverage from the schema, the agent cannot know what entity_id refers to (e.g., provider, register, submission). This is a critical gap that prevents 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 states a specific action ('Validate') and a target resource ('Register of Information'), clearly indicating the tool's purpose. The phrase 'against ITS mandatory fields per provider' adds specificity, though it does not explicitly contrast with sibling tools like roi_export. The validation focus is distinct, making the purpose understandable.
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?
No guidance is provided about when to use this tool versus alternatives. The description simply states the operation without specifying prerequisites, context, or exclusions. An agent would have to infer usage from the tool name alone, which is insufficient for effective selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pull latest entity data from AmpelOracle for report population.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral aspects. 'Pull' suggests a read operation, but the tool name 'sync_from_ampel' implies potential writes or state changes (e.g., updating a local cache). The description does not mention side effects, permissions, rate limits, or return behavior, leaving significant ambiguity about what happens when invoked.
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 a single, focused sentence that front-loads the main action ('Pull latest entity data') and avoids repetitive or redundant language. It is concise and well-structured, though it could include additional valuable details without becoming overly verbose.
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?
For a simple one-parameter tool with no annotations and no output schema, the description is incomplete. It does not clarify what the function returns, whether entity_id filters the operation, or if the sync modifies local data. The lack of parameter semantics and side-effect disclosure means an agent cannot confidently invoke this tool correctly without further investigation.
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%, and the description does not mention the single parameter 'entity_id' at all. The parameter's purpose, optionality, format, or impact on results is completely undocumented. This is a major gap, especially given the tool's core operation depends on identifying which 'entity' to sync.
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 specifies the verb 'Pull' and the resource ('latest entity data from AmpelOracle'), with an explicit purpose ('for report population'). This distinguishes it from sibling tools like get_report, which likely return report documents, while this syncs external data. However, 'entity data' is somewhat vague, lacking detail on what entities are included.
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 phrase 'for report population' provides clear context that this tool is a precursor to report generation. While it doesn't explicitly name alternatives or exclusions, the context is sufficient to infer when it should be used relative to siblings like get_report. No other tool in the list appears to perform a similar data-sync role, so usage is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate TLPT results summary for NCA submission (Art. 26(8)). Pulls from TestOracle.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It states it 'Pulls from TestOracle' and 'Generates' a summary, but does not clarify whether this is a read-only operation, what side effects occur (if any), authentication requirements, or what the return format looks like. The ambiguous verb 'Generate' could imply creating a submission rather than merely producing a summary, which is a significant transparency gap.
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 a single, concise sentence that front-loads the primary purpose. It includes relevant context (NCA submission, Art. 26(8)) and data source (TestOracle) without any unnecessary words. Every clause earns its place.
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 low complexity (one optional parameter, no output schema), the description is missing essential contextual details. It does not explain what the generated summary contains, how entity_id affects the output, any prerequisites, or whether the tool actually submits something to the NCA. The tool name and description are too sparse to be fully complete for an agent to invoke it confidently.
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%, and the description makes no mention of the entity_id parameter. The input schema only defines 'entity_id' as a string with no explanation, and the description does not clarify the parameter's purpose, format, or whether it is optional despite being not required. The description adds zero value beyond the schema, which is inadequate even for a single-parameter tool.
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 the tool's specific function: generating a TLPT results summary for NCA submission under Art. 26(8). The verb 'Generate' combined with the resource 'TLPT results summary' and the regulatory context distinguishes it from sibling report tools like annual_report or incident_report.
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 clear context for when to use the tool: for NCA submission under Art. 26(8). It implies this is the appropriate tool for generating TLPT summaries, but it does not explicitly mention when not to use it or suggest alternatives. This is clear enough for most users but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
annual_reportapprove_reportdeadline_trackerget_reporthealth_checkincident_reportincident_statusmanagement_letternca_submission_statusobligation_mappingreport_templatesroi_exportroi_validatesync_from_ampeltlpt_reportRiskOracle - 13-tool enterprise risk MCP: heatmaps, KRIs, scenario sims, Basel/ICAAP outputs.
InsuranceOracle - 12 insurance compliance tools: GDV, BaFin VAG, Solvency II, IDD.
IFRS engine: 31 standards, 21 tools. Journal entries, XBRL tags, ECL, CGU impairment, deferred tax.
AmpelOracle — 50-tool compliance traffic-light: Go/Caution/Stop signals for ESG, MiCA, AML.
Add one secure layer between your agents and this server.
