Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations at all, the description carries the full burden and does deliver real behavioral context: contact fields (email, phone) are conditionally redacted for unauthenticated callers, and the caller must sign in or supply an API key. It does not cover failure behavior for unknown ids or any rate/consistency characteristics.

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 sentences, each earning its place: the first defines the operation and its returned payload, the second flags the auth-dependent field visibility. Front-loaded with the core purpose and free of filler.

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 single-parameter read tool with no output schema, the description adequately previews the response shape (place, coordinates, app links, contact fields) and the auth caveat. The only meaningful gap is what happens when the id is not found or the entity is inaccessible.

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?

There is a single required parameter with 100% schema description coverage (UUID format and pattern already documented in the schema). The description only reinforces that lookup is by id, adding nothing new about format or source of the value — baseline 3 applies.

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 verb and resource ('Fetch a single asset-map entity by id') and enumerates the payload (place/coordinates, Food Web app links), which is far more than a restatement of the title. The singular, id-based scope implicitly separates it from the sibling search_entities, but no sibling is named outright.

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?

Usage is only implied: the 'by id' framing suggests it is the lookup path once a UUID is known, versus search_entities for discovery. There is no explicit when-to-use/when-not statement and no prerequisite guidance beyond the auth note about contact fields.

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