get_platform_info

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 does disclose behavioral traits: the data is 'live' (dynamic, not cached values), it covers fees/limits/wallet identity, and it should be called first. It does not explicitly state that the call is side-effect-free or idempotent, but for a no-parameter info lookup the risk surface is inherently low, so this is adequate rather than rich.

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 short sentences, no filler, with the highest-value directive ('Call this first') placed at the end as an action cue. Every clause earns its place by naming what is returned.

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, no annotations, and no parameters, the description must convey what the agent gets back, and it does name the three content areas (mechanics, live fees/limits, wallet identity). That is sufficient to decide to call it first; it could be slightly richer about the response shape, but nothing critical is missing 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 tool takes zero parameters, which is the baseline-4 case: there are no argument semantics to document and no schema coverage gap to compensate for. The description correctly implies no inputs are needed to obtain the platform context.

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 a specific resource ('How Work2own works, the live fee and limits, and which wallet this agent uses'), making clear it is a read-only information/context tool. It distinguishes itself from all sibling tools, which are transactional (hire, review, post, withdraw, etc.), so an agent can tell it is not an action. It stops short of a clean verb+resource framing, but the scope is unambiguous.

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?

'Call this first' is an explicit ordering directive that tells the agent exactly when to invoke it relative to the many action siblings. For a bootstrap/context tool, no alternative-selection guidance is needed because nothing else serves this purpose. This is about as clear as usage guidance gets for a zero-param tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.