x402-density
Density: Calculate density: mass divided by volume. Provide mass and volume values. 🆓 5 free trial calls per signed wallet
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| mass | No | ||
| volume | No |
Density: Calculate density: mass divided by volume. Provide mass and volume values. 🆓 5 free trial calls per signed wallet
| Name | Required | Description | Default |
|---|---|---|---|
| mass | No | ||
| volume | No |
Changes observed during successful MCP inspections.
Input schema / properties / mass / descriptionRemoved value: -"Mass to process"Input schema / properties / volume / descriptionRemoved value: -"Volume to process"Input schema / properties / massAdded value: +{
+ "description": "Mass to process",
+ "type": "string"
+}Input schema / properties / volumeAdded value: +{
+ "description": "Volume to process",
+ "type": "string"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It does disclose the monetization/auth model ('5 free trial calls per signed wallet'), which is real behavioral context an agent needs before calling. However it says nothing about output format, precision, or what happens for zero/invalid volume.
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?
Very short and front-loaded with the operation and its formula. The leading 'Density:' label duplicates the tool name and slightly wastes a clause, but there is no padding beyond that.
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 two-input pure calculator with no output schema, the formula is enough to infer the return value, but the missing unit semantics and validation behavior leave the definition adequate rather than 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?
Schema description coverage is 0%, and both parameters are typed only as strings. The description names 'mass' and 'volume' but adds no unit conventions, numeric format, or whether unit-bearing strings are accepted, leaving a real ambiguity for a physical calculation.
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 a specific verb and resource and even supplies the formula (mass divided by volume), so the agent knows exactly what computation happens. It does not differentiate from nearby siblings such as x402-sphere-density or x402-volume-to-mass, which compute related quantities, so it stops 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?
'Provide mass and volume values' is invocation guidance, not usage guidance. There is no statement of when to pick this over x402-weight, x402-volume, or the density variants, and no exclusions or preconditions.
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.