Register an ICT asset (application, database, server, etc.) — Art. 8.
| Name | Required | Description | Default |
|---|---|---|---|
| sla | No | ||
| notes | No | ||
| owner | No | ||
| asset_id | No | ||
| location | No | ||
| provider | No | ||
| asset_name | Yes | ||
| asset_type | No | ||
| department | No | ||
| redundancy | No | ||
| criticality | No | ||
| description | No | ||
| backup_exists | No | ||
| data_classification | No |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'Register' and lists asset types, but does not disclose side effects (e.g., creating a record), required permissions, idempotency, or whether duplicate registrations are allowed. This leaves significant behavioral ambiguity.
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, which is concise, but it is under-specified for a tool with 14 parameters and complex enums. It front-loads the purpose but fails to earn its place as the only textual guidance, being too brief to be '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 the tool's complexity (14 params, 4 enums), lack of annotations, and lack of output schema, the description is grossly incomplete. It provides no information about return values, expected input formats, behavioral nuances, or any operational context. This is effectively just a restatement of the tool's name with a few bullet-point examples.
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 14 parameters with 0% description coverage, and the description adds no parameter-level meaning. It only mentions examples of asset types, giving no guidance on fields like 'criticality', 'sla', or 'redundancy'. The agent is left to infer semantics from names and enums alone.
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 action: 'Register an ICT asset', and provides examples of asset types (application, database, server, etc.). This is a specific verb+resource that distinguishes it from sibling tools like 'asset_inventory' or 'register_function'.
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 implicitly indicates this tool is for registering assets, but it does not explicitly state when to use it versus alternatives, any prerequisites, or exclusions. Usage is implied but not clearly delineated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.