x402-dividend-payout-ratio
Dividend Payout Ratio: Ratio of dividend payout. 🆓 5 free trial calls per signed wallet
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| earningsPerShare | No | ||
| dividendsPerShare | No |
Dividend Payout Ratio: Ratio of dividend payout. 🆓 5 free trial calls per signed wallet
| Name | Required | Description | Default |
|---|---|---|---|
| earningsPerShare | No | ||
| dividendsPerShare | No |
Changes observed during successful MCP inspections.
Input schema / properties / dividendsPerShare / descriptionRemoved value: -"DividendsPerShare to process"Input schema / properties / earningsPerShare / descriptionRemoved value: -"EarningsPerShare to process"Input schema / properties / dividendsPerShareAdded value: +{
+ "description": "DividendsPerShare to process",
+ "type": "string"
+}Input schema / properties / earningsPerShareAdded value: +{
+ "description": "EarningsPerShare to process",
+ "type": "string"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden of behavioral disclosure. It adds only that the endpoint is metered (5 free trial calls per signed wallet), which hints at a payment/auth prerequisite, but says nothing about output units (decimal vs. percent), rounding, or handling of a zero earningsPerShare.
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?
It is short but not efficient: the first clause duplicates the tool name, and the second is marketing copy about free trial calls rather than capability information. Nothing in the two fragments is front-loaded to explain what the tool computes.
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 annotations, no output schema, zero parameter descriptions, and many overlapping dividend/finance siblings, the description is far too thin for correct selection and invocation. An agent cannot tell which ratio variant to pick or what input format to supply.
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 (earningsPerShare, dividendsPerShare) are bare strings with no format, unit, or currency guidance. The description never mentions either parameter, so it does nothing to compensate for the schema gap on a financial calculation where string formatting and zero-division behavior matter.
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 reads "Dividend Payout Ratio: Ratio of dividend payout," which restates the tool name rather than explaining the operation. It never states the formula (dividends per share divided by earnings per share) or how it differs from near-identical siblings like x402-dividend-payout and x402-dividend-yield.
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?
There is no guidance on when to use this tool, when to prefer a sibling ratio/yield tool, or what inputs are required. The only context given is a promotional note about free trial calls, which does not help an agent choose between the many overlapping finance tools in the sibling list.
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.