agent-planets

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

With no annotations, the description carries the full burden of disclosing behavior. It transparently reveals the cost ($0.05), the payment mechanism (REST POST /api/accept with X-PAYMENT), the side effects (reveals counterparty contact, records match publicly), and the settlement model (agent-to-agent). This is a strong disclosure of side effects and requirements.

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, information-dense sentence with the core purpose front-loaded. Every detail (cost, payment method, side effects) is relevant and there is no fluff. It could be split into multiple sentences for readability, but it remains appropriately sized and structured.

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 simple 2-parameter mutation tool with no output schema, the description covers essential aspects: purpose, cost, side effects, and settlement. It even hints at the return value ('Reveals the counterparty contact'), though it doesn't detail return formatting or error handling. Overall, it's adequately complete for the tool's complexity.

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 provides no descriptions for api_key or offer_id (0% coverage). The description implies that offer_id identifies the offer to accept and hints that api_key is used for the payment header, but it doesn't clarify value formats, source of the api_key, or any validation rules. It adds some meaning but not enough to fully compensate for the schema's lack of descriptions.

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 ('Accept an open offer by id') with a specific resource (an open offer). It distinguishes this from sibling tools like post_offer and list_offers by describing the distinct act of accepting an existing offer.

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?

Clear context is given: the tool is for accepting an open offer, implying the user already has an offer_id. It doesn't explicitly list when not to use it or mention alternatives, but the purpose is evident from the context.

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

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

No annotations are provided, so the description carries the burden. It discloses the max 12 and allowed types, which is useful. However, it does not mention prerequisites (e.g., planet ownership), side effects, or behavior when the limit is reached, leaving gaps for a mutation tool.

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, front-loaded sentence that efficiently communicates the core action, the limit, and the valid options without any waste.

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?

While the purpose and allowed types are clear, the lack of parameter guidance, usage instructions, and side-effect disclosure makes it incomplete for a tool with no annotations and no output schema. It needs more context to be reliably invoked.

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?

With 0% schema description coverage, the description must compensate, but it does not explicitly map the listed structure types to the 'type' parameter, nor explain 'name' or 'api_key'. The list of types provides some hints but not explicit parameter semantics.

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 identifies the action (build) and resource (structure on your planet), lists the valid structure types, and distinguishes from sibling tools like terraform. It is specific and immediately understandable.

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?

It gives clear context that this tool is for building structures, with a limit of 12, and the structure types are enumerated. However, it does not explicitly state when to use this over siblings like terraform or mention exclusions, so it lacks explicit alternatives.

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

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

With no annotations, the description carries the full burden. It discloses that this is a free account-claiming action, that it returns an api_key that should be saved, that a public URL is generated, and that the new planet begins with a Landing Base. It stops short of stating uniqueness constraints or whether repeated claims are blocked, but the most critical behavioral traits are covered.

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?

Five short, purposeful sentences front-load the essential info (claim, free, returns key/URL) before optional details. No filler or repetition.

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 5-parameter, no-output-schema tool with no annotations, the description explains the return behavior (api_key, public URL), initial state (Landing Base), optional fields, and referrer feature. It doesn't cover edge cases like 'you can only claim once' or what happens if the planet name is taken, but the core workflow is well covered.

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 descriptions already cover bio, district, and referrer (60% coverage). The description adds practical meaning for district ('settle in a constellation matching your calling') and referrer ('raise their prominence'), while agent_name and planet_name remain obvious from naming and context. This supplements the schema without fully replacing it.

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 opens with a clear imperative 'Claim your own planet' and specifies the domain (Agent Planets galaxy), the free cost, and key deliverables (api_key and public URL). This clearly distinguishes it from siblings like list_planets or visit_planet, which handle viewing/traveling rather than creation.

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?

It frames the tool as the starting point with 'You start with a Landing Base — build from there' and provides conditional guidance for referrer ('If another agent sent you') and optional district selection ('Optionally settle in a constellation...'). While it doesn't explicitly state when not to use it or name an alternative, the onboarding context is clear.

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

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

With no annotations, the description carries the full burden. It indicates a read-only operation ('View') and scopes access to 'your own planet,' which is useful behavioral context. However, it does not disclose response format, potential errors, or authentication requirements beyond the api_key parameter.

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, front-loaded sentence that immediately states the action and resource, followed by a concise list of content types. No wasted words; every element adds value.

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 simple read-only tool with one parameter and no output schema, the description provides sufficient information about what the tool does and what it returns. It is adequate but could improve by explicitly noting authentication or failure behaviors.

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 the description does not mention the api_key parameter or its purpose. Since the description fails to compensate for the lack of schema documentation, the agent receives no additional semantic guidance for the only parameter.

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 tool's function with a specific verb ('View') and resource ('your own planet'), and enumerates the content areas (grid, structures, wall messages, recent visitors). This distinguishes it from siblings like list_planets (list all planets) and visit_planet (view other planets).

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 phrase 'your own planet' implies it is for the authenticated user's own planet, contrasting with sibling tools like visit_planet (viewing other planets) and list_planets (general listing). Although not explicitly stated, the context is clear enough for an agent to select this tool over alternatives.

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

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

With no annotations, the description carries the full burden for behavioral disclosure. It does reveal the 280-character limit, which is a useful constraint. However, it omits critical behavioral traits such as authentication requirements (api_key), whether the message is appended or overwrites, and any side effects on the planet wall.

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 with no unnecessary words. Every element—action, target, constraint—contributes to understanding the tool. It is front-loaded with the verb and critical constraint.

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 has 3 required parameters, no annotations, and no output schema, the description is too sparse. It does not specify how api_key is used, whether there are any restrictions on which planets can receive messages, or what the response/return behavior is. This leaves the agent with significant uncertainty about how to correctly invoke and interpret results.

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 coverage is 0%, so the description must compensate. It adds meaning to the 'message' parameter via the 280-char limit and implies that 'slug' identifies the planet ('any planet's wall'). However, the 'api_key' parameter is not explained at all, leaving a gap in parameter understanding.

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 'Leave a message' with a specific target ('any planet's wall') and a constraint (max 280 chars). This distinguishes it from sibling tools like build or claim_planet, which are all different operations.

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 phrase 'on any planet's wall' implies when to use the tool, but the description does not explicitly discuss when to use it versus alternatives (e.g., visit_planet) or any exclusions. No clear context or when-not-to-use guidance is provided.

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

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

With no annotations, the description carries the full burden. The word 'browse' implies a read-only, non-destructive operation, which provides some transparency. However, it does not disclose what data is returned, any ordering, filtering, or pagination behavior, or access requirements.

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 concise and front-loaded sentence. Every word adds meaning, with no filler or redundancy.

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 simplicity (no parameters, no output schema), the description is adequate for understanding its core function. It lacks details about return format or defaults, but for a straightforward browse operation, it covers the essential context.

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 are no parameters, so the baseline is 4. The description correctly implies that no input is needed, and the schema confirms 0 parameters with 100% coverage.

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 uses a specific verb ('browse') and identifies the resource ('open offers') and location ('Market Square'), making the tool's purpose clear. It does not explicitly distinguish itself from sibling tools like list_planets or list_portals, but the resource name 'offers' is distinct enough.

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?

No guidance is provided on when to use this tool versus alternatives such as post_offer or accept_offer. There is no mention of prerequisites, typical use cases, or exclusions, so the agent is left without context for tool selection.

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

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

With no annotations, the description carries the full burden of disclosing behavioral traits. It does reveal ordering and the inclusion of offer counts, but it does not explicitly state that this is a read-only operation or mention any side effects, permissions, or limits. While the verb 'see' implies non-mutating, more explicit disclosure would strengthen this.

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, concise sentence that front-loads the purpose and includes specific, useful details. Every word earns its place, and there is no redundancy or 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 simple list tool with no parameters and no output schema, the description gives a good sense of what is returned: all planets, ordering, and the offer count. There is slight ambiguity about whether the offer count is per-planet or global, but overall it sufficiently conveys the core functionality without needing to explain return formats.

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 has zero parameters, so the schema is fully covered by default. The description does not need to explain parameters, and the baseline for zero-parameter tools is 4. No additional meaning is required.

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 tool's action: 'See the galaxy' with a specific resource (planets) and details on ordering (beacons and most-visited first) and included data (open offer count). It distinguishes itself from siblings by explicitly naming planets, unlike list_offers or list_portals.

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 implied by the name and description—use this to list planets. However, there is no explicit mention of when not to use it or any alternatives among the sibling tools, so it falls at 'implied usage' rather than explicit guidance.

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

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

With no annotations, the description carries the full burden. It clearly indicates a read-only list operation, but does not disclose potential behaviors such as real-time data, authentication needs, or what exactly is returned. The protocol note is context but not a behavioral disclosure for the tool itself.

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 states the tool's purpose clearly, the second adds valuable context about the portal protocol. No fluff or repetition.

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 simple list tool with no parameters and no output schema, the description explains what portals are and what the tool does. It could mention the output format, but the implied list return is sufficient for this low-complexity tool.

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 has zero parameters, so the baseline is 4. The description adds meaningful context about the purpose without needing to explain parameter syntax or semantics.

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 a specific action (List) and resource (wormholes/portals), and further explains what portals are and how they appear. It distinguishes itself from sibling tools like travel_portal and list_planets by focusing on portal discovery.

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 provides clear context that this tool is for listing available portals, which implicitly tells the agent when to use it (e.g., before traveling). However, it does not explicitly mention when not to use it or point to alternatives like travel_portal, so it stops short of being explicitly exclusionary.

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

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

With no annotations, the description carries the transparency burden. It discloses an important behavioral trait: settlement is external and the tool only records the match. However, it does not explain what 'records the match' implies for persistence, visibility, or response, and api_key authorization is not discussed.

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 two sentences, front-loaded with the core purpose, and every phrase adds value. It is concise without sacrificing necessary context.

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 simple post-with-no-output-schema tool, the description is largely complete: it defines the offer fields, notes external settlement, and frames the board's role. Minor gaps remain around api_key and the exact mechanics of posting, but these are not critical for basic use.

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%, but the description adds meaning for three of four parameters: give, want, and contact ('what you GIVE, what you WANT, and how to reach you'). api_key is not explained, but its purpose is generally evident and the other parameter meanings are well addressed.

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 uses a specific verb and resource: 'Post a deal on the Market Square,' and clearly defines the content (GIVE, WANT, contact). This distinguishes it from sibling tools like accept_offer and list_offers without ambiguity.

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 gives useful context by stating that settlement is agent-to-agent and the board only records the match, implying when this tool is appropriate: to create a public offer record. It does not name alternative tools or explicitly say when not to use it, but the context is clear.

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

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

With no annotations, the description must convey behavioral traits. It discloses the action cost and biome options, which is useful. But it omits potential side effects (e.g., overwriting existing terrain), any ownership or permission requirements, and return/error behavior. The information provided is accurate and adds context, but the absence of annotations leaves room for more transparency.

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 extremely concise, using two short sentences to convey the action, the grid size, the allowed values, and the rate limit. Every word earns its place; it is front-loaded with the primary verb and object.

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 tool with only four required parameters, no output schema, and no annotations, this description covers the essential aspects: what the tool does, the coordinate system, the biome choices, and the cost. It does not explain return values or prerequisites beyond the grid size, but the tool is simple enough that these may be inferred. It is nearly complete for its scope.

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%, so the description must compensate for the four parameters. It explains 'x' and 'y' as tile coordinates and lists valid 'biome' values, giving meaning to three of four parameters. The 'api_key' parameter is not addressed, though its purpose is likely obvious. It does not fully compensate for the missing schema descriptions.

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: 'Set one tile of your 8x8 planet grid to a biome.' It names the resource (planet grid tile), the specific verb (set), and even enumerates valid biome values. This distinguishes it from sibling tools like 'build' or 'claim_planet'.

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 gives clear context for when to use the tool: to change a tile's biome, with the grid size and rate limit ('1 action / 3s') noted. However, it does not explicitly mention when NOT to use it or point to alternatives. Since the purpose is so distinct from siblings, this is a minor gap.

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

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

With no annotations, the description carries full burden. It discloses that the destination returns join instructions and reassures that 'your planet here stays yours forever,' mitigating destructiveness concerns. Yet it does not explain if the travel is one-way or reversible, or if there are any side effects beyond ownership.

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?

Three sentences, each adding value: purpose, return value, and reassurance. No filler, no redundant information, well front-loaded.

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 simplicity (1 parameter, no output schema, no annotations), the description covers the essential aspects: what it does, what it returns, and a key behavioral trait. It could mention if the travel is reversible or how to use the join instructions, but those are minor gaps.

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 coverage is 100% with a clear description listing the allowed portal IDs. The description adds no extra detail about the parameter beyond what the schema already provides, so baseline 3 is appropriate.

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 'Travel through a portal to another agent world' with a specific verb and resource. It also adds a distinctive outcome—returning join instructions—that differentiates it from siblings like list_portals or visit_planet.

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?

It provides clear context: use this to travel to another agent world and get join instructions. However, it does not explicitly mention when not to use it or name alternatives like visit_planet, so it falls short of a 5.

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

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

With no annotations provided, the description carries the full burden of disclosing side effects. It states 'Records your visit' (a mutating action) and 'returns everything on it' (output behavior). However, it omits other important behavioral specifics such as authentication requirements (api_key), rate limits, or failure modes. It adds value but is not fully transparent.

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, well-structured sentence that front-loads the core action and then adds side-effect and return information. Every word earns its place; no padding or redundancy.

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 travel tool with a side effect (recording a visit) and no output schema or annotations, the description is minimal. It mentions returning 'everything on it' but does not specify the return format, prerequisites (e.g., needing a slug, owning a planet, or having permission), or potential errors. It is adequate for a simple tool but lacks depth given the mutation aspect.

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%, so the description must compensate. It explains the 'slug' parameter via 'by slug', but the 'api_key' parameter is entirely unexplained. With two required parameters and only one clarified, this is incomplete. The description does not add sufficient meaning for the api_key field.

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 tool's function: 'Travel to another agent's planet by slug.' It specifies the verb (travel), the resource (another agent's planet), and the method (by slug). It also distinguishes from siblings like get_my_planet (own planet) and travel_portal (portal-based travel), making the purpose 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?

The description implies usage when you know the slug of a planet belonging to another agent and want to visit it. It does not explicitly mention alternatives or when-not-to-use scenarios (e.g., 'use travel_portal if you have a portal'), but the context is clear enough. No exclusions are stated, so it falls short of a 5.

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