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

There are no annotations, so the description carries the full burden. It transparently discloses critical behavioral traits: the call is ASYNCHRONOUS, returns an id immediately, and the connection persists beyond the conversation. This is exactly the kind of non-obvious behavior an agent must know. It could have mentioned failure modes, but the provided details are highly valuable.

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 three sentences, each earning its place: the core action, the asynchronous caveat, and the persistence warning. It is front-loaded with the main purpose and uses efficient formatting (capitalized ASYNCHRONOUS, em-dash) to draw attention to key details without 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?

For a one-parameter tool with an output schema, the description covers all essential operational context: how to initiate, that it returns an id, how to verify success via polling, and the persistence caveat. This is sufficiently complete for an agent to use the tool correctly even in a later session.

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 input schema already fully describes the single parameter 'address' with format examples and default scheme behavior. The tool description adds no additional parameter semantics beyond the schema, so the baseline of 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?

The description opens with a specific verb and resource: 'Open a connection to a Teleport server and return its id.' This clearly states the tool's function and distinguishes it from sibling tools like teleport_list_connections or teleport_connection_status. The mention that the connection outlives the conversation further sharpens its purpose.

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 procedural guidance: 'Poll teleport_connection_status until state is CONNECTED.' This tells the agent exactly how to follow up and confirms the asynchronous nature. It does not explicitly list when not to use or name alternatives, but the sibling context and clear connect action make usage obvious.

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 burden of disclosing behavioral traits. It lists the returned fields and state values, which is useful, but it doesn't explicitly state that the tool is read-only, has no side effects, or what happens if the connection ID is invalid. For a status query, this is implied but not explicit.

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, dense sentence that packs in the purpose, key return fields, state enum, and usage timing without any fluff. Every word adds value, making it highly efficient.

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 presence of an output schema and the simplicity of the tool (one parameter, status query), the description is quite complete. It specifies what is returned, when to call it, and it's clearly scoped to one connection. The only gap is an explicit statement of preconditions or error handling, but this is minor.

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 fully documents the single parameter with 100% coverage, including its source (returned by teleport_connect or teleport_list_connections). The description adds no additional parameter-level detail beyond what the schema already provides, so the baseline of 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?

The description clearly indicates the tool reports the status of a single connection, listing specific fields like state, server, latency, inputs, and mode. It distinguishes itself from teleport_list_connections by stating 'one connection,' and the explicit state enum values add specificity.

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 'Poll this after teleport_connect' gives explicit timing guidance, indicating when this tool is appropriate. It doesn't explicitly rule out alternatives, but the context is clear enough for an agent to select it for checking a single connection's status.

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 adds valuable behavioral context by stating that 'the service and any other connections keep running,' clarifying that this is a non-destructive, scoped operation. This goes beyond a simple 'close' and gives the agent important safety information.

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, front-loaded with the core action, and every word earns its place. No unnecessary elaboration.

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 low complexity (one parameter, no nested objects), the presence of an output schema, and the description's clear explanation of what is and isn't affected, the tool is fully described. The only missing element is explicit usage guidance, which is handled in its own dimension.

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 already provides 100% coverage for the sole parameter, including its type, origin, and constraints. The description adds no further parameter meaning, so a baseline of 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 'Close one connection' uses a specific verb and resource, clearly distinguishing it from siblings like teleport_list_connections or teleport_set_pose. The scope is explicit: it closes exactly one connection, not all connections.

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 when to use the tool (when you want to close a single connection) but does not explicitly state alternatives or when not to use it. The phrase 'one connection' hints at scope but lacks direct guidance on prerequisites or exclusions.

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 burden of disclosing behavior. It explains the differences between summary/nodes/resources and adds an important caveat that uids are decimal strings because they exceed JSON number limits. It implicitly indicates a read-only report operation, though it could be more explicit about being non-mutating.

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 three succinct sentences, front-loaded with the overall purpose, then expanding into parameter-specific details. Every sentence adds value, including the uids type caveat, with no unnecessary 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?

Given the output schema exists, return format details are not necessary. The description covers the main behavioral variants and a key data-type pitfall, making it sufficient for tool selection and invocation. It could mention potential size or pagination, but that is not essential for this tool's core 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?

The description adds meaning to the 'what' parameter beyond the bare enum, explaining what each value returns (counts, tracked nodes, pointer URLs/uids never sent). connectionId is already described in the schema, so the description compensates for the 50% schema coverage gap without duplicating known information.

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 what the tool does: it reports geometry the server has streamed to a connection, with specific sub-modes (summary, nodes, resources). This distinguishes it from sibling tools like teleport_connection_status and teleport_overview by focusing on streamed geometry contents.

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 on when to use this tool (to inspect streamed geometry) and explains the available 'what' options, which guides selection among sub-uses. It does not explicitly mention alternatives or exclusions, but the context is sufficiently clear for an agent to choose it appropriately.

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 disclosure. It reveals the asynchronous nature of sign-in, the need to poll for results, and the external user interaction required. This goes well beyond the schema by explaining the 'how' and 'why' of the behavior.

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: the first states the core purpose, the second explains the most complex usage flow. No filler or redundancy, and it front-loads the key information.

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 output schema is present, return values need not be explained. The description covers the tool's actions, the sign-in flow, and the constraint, making it fully sufficient for an agent to invoke the tool correctly.

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 50% (provider is described, action is not). The description clarifies the action parameter by showing how 'signin' and 'show' are used in the flow, though it doesn't explicitly explain the 'signout' action or the provider parameter. This partial compensation is strong but not complete.

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 explicitly states 'Show, start or clear the service identity,' giving a specific verb+resource and distinguishing this tool from sibling tools focused on connections, inputs, or geometry. The reference to the device-code flow further clarifies the tool's unique purpose.

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 an explicit step-by-step usage for the sign-in flow: start with action=signin, poll action=show, and relay pendingSignIn. It also explains the rationale ('The service has no browser, so relaying that prompt is the only way in'). It doesn't name an alternative tool, but the context makes it clear when to use this identity tool.

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 behavioral disclosure. It states the output content (id, URL, state) but does not explicitly confirm that the operation is non-destructive or read-only. It also omits any mention of authentication requirements, potential errors, or the possibility of stale data, which are important for safe agent decision-making.

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, clear sentence that exactly covers the tool's purpose and output. It is front-loaded with the essential information and contains no filler or redundant phrases. For a tool with no parameters and a straightforward listing function, this level of conciseness is ideal.

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 zero parameters and an output schema exists, the description does not need to elaborate on return structure. The description mentions the key fields (id, URL, state) which complements the output schema. However, it is minimal and does not cover edge cases like empty connection lists or error behavior, but these are less critical given the simple nature of the operation.

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 input schema has zero parameters, so schema coverage is 100% by definition. The baseline for 0 params is 4, and the description does not introduce any parameter-related ambiguity. It adds no parameter information because none exists, which 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 title 'List connections' provides the verb, and the description specifies the resource: 'Every connection the service currently holds, with its id, URL and state.' This clearly conveys a read-only listing operation. It does not explicitly distinguish itself from sibling tools like teleport_connection_status, but the phrase 'every connection' implies a comprehensive listing versus a singular status check.

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 no guidance on when to use this tool versus alternatives. It lacks any mention of expected use cases, prerequisites, or exclusions. There is no reference to sibling tools such as teleport_connection_status or teleport_disconnect, leaving the agent to infer usage from the name alone.

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 burden. It discloses key behavioral traits: the result is initially empty and depends on connection state. It also clarifies the relationship to teleport_send_input, adding useful context.

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, but the wording is somewhat convoluted ('Inputs the server has declared... takes'). It could be more concise and front-loaded, e.g., 'Lists the input definitions for a connection.'

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?

The tool is simple with one parameter and an output schema exists. The description covers the key contextual information (when data is available, relationship to send_input) without needing to explain return values, as output schema handles that.

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% and the connectionId parameter is well-described in the schema. The description adds no additional parameter information, so it meets the baseline of 3 for high schema 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 explains that the tool lists inputs declared by the server, with the IDs used by teleport_send_input. This is a specific verb+resource and distinguishes it from siblings like teleport_send_input, though the phrasing could be more direct.

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 explicitly states that results are empty until the connection reaches CONNECTED and the server sends input definitions, giving clear timing guidance. It does not explicitly mention alternatives but implies this tool is for listing, not sending, inputs.

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 exist, so the description carries full burden. It discloses return content (version, connections, identity) and the ability to answer up/down status, but does not explicitly state whether it is read-only, side-effect-free, or any permission requirements. Read-only is implied but not stated.

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, front-loaded with a clear 'Where am I' anchor. Every word adds value, 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 zero-parameter input, the presence of an output schema, and the clear description, the tool is fully specified for agent use. The existing output schema covers return values, so the description does not need to restate them.

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 zero parameters, so the input schema is trivially fully covered. No parameter descriptions are needed, and the baseline of 4 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?

The description clearly states what the tool does: provides service version, open connections, and current identity in one call. 'Start here' positions it as the entry point, distinguishing it from sibling tools that focus on individual aspects.

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?

'Start here' gives clear usage context—use this first to assess service state. However, it does not explicitly name alternative tools or provide exclusions, so there's a minor gap in when-not-to-use 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 disclosure burden. It reveals that the command is sent 'verbatim' and specifically warns about `shutdown` stopping the service and live streams. This adds some behavioral context, but it does not mention other potential side effects, error behavior, or the lack of validation beyond the verbatim note. The warning is valuable but not comprehensive.

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 only two sentences, front-loading the primary purpose and then adding essential usage context. Every word earns its place, with no repetition of schema or annotations. It is concise yet complete for its role.

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 raw command nature, the description adequately covers its purpose, when to use it relative to siblings, and a critical safety warning. An output schema exists, so return values are documented elsewhere. It could mention error handling or revocation, but for a fallback tool, the context is sufficiently 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?

The input schema already fully describes the `command` parameter with an example ('help' or 'use 1'), and schema coverage is 100%. The description adds no additional parameter semantics beyond what the schema provides, so the baseline of 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?

The description clearly states the tool's function: 'Send one command line to the service verbatim.' It also defines its scope as a fallback for 'anything the tools above do not cover,' distinguishing it from the specific sibling tools. The verb 'send' and the resource 'command line' are explicit and 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 provides clear context for when to use this tool: for anything not covered by other tools, with a pointer to `help` for the full list. It also warns about the dangerous `shutdown` command. However, it does not explicitly state 'do not use this if a dedicated tool exists,' though that is strongly implied by the phrase 'do not cover.'

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 disclosure burden. It explains the event types and their parameters, which helps an agent understand what data to send. However, it does not disclose potential side effects, error conditions, or whether the connection must be active, beyond the implied presence of a connectionId. This is adequate for a straightforward send action but lacks deeper behavioral context.

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 only two sentences and front-loads the core purpose. Every phrase adds value – the first specifies the action, the second clarifies per-kind parameter usage and directs to the companion list tool. 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?

While the description and schema cover most aspects, there is a notable gap: the schema's required fields only include connectionId, kind, and inputId, but the description does not explicitly state that value is required for binary/analogue or that x/y are required for motion. This could lead an agent to omit necessary parameters. The output schema exists, and the description mentions the prerequisite for IDs, but the missing conditional requirements reduce completeness.

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 already covers most parameters (83% schema description coverage), and the description adds meaningful clarification for the kind-dependent fields. It explains that 'binary takes value 0 or 1; analogue takes a single float; motion takes x and y,' which is more explicit than the schema's per-field notes and helps agents understand how to construct the request correctly.

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: 'Send one input event.' It enumerates the three input kinds (binary, analogue, motion) and their respective data formats, making it distinct from sibling tools like teleport_set_pose or teleport_raw_command. The verb 'send' and resource 'input event' are specific and 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 provides clear usage context by explaining how each kind expects its value ('binary takes value 0 or 1; analogue takes a single float; motion takes x and y') and explicitly directs users to 'Use teleport_list_inputs for the ids the server expects.' This gives a concrete prerequisite and a companion tool, though it does not mention when to avoid this tool or 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 provided, the description carries the transparency burden. It discloses the behavioral differences between modes (diagnostic vs. full geometry streaming) and notes the effect on teleport_get_geometry. It doesn't mention side effects of switching modes but is sufficiently transparent for the tool's purpose.

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, every word earns its place. It front-loads the mode explanations and includes actionable guidance without 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 moderate complexity (2 params, one enum) and presence of an output schema, the description adequately covers the modes and intended usage. It references connectionId implicitly via the connection context, and the output schema handles return values. Minor gap: doesn't explicitly state prerequisites like an active connection.

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 50% (connectionId is described in schema). The description adds meaning to the 'mode' parameter by explaining each enum value, while connectionId is already well-documented. This compensates for the coverage gap.

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 title 'Set client mode' clearly states the tool's purpose, and the description elaborates on the two modes. It distinguishes from siblings like teleport_set_pose by focusing on mode selection, though it doesn't explicitly mention alternatives.

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 explicit guidance for when to use the 'simulated' mode ('Use simulated before expecting teleport_get_geometry to report anything') and explains 'minimal' as a diagnostic. It gives context for mode choice but does not discuss when to use this tool vs. alternative tools.

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 behavioral disclosure. It adds useful context like units ('metres') and the quaternion format, and states the prerequisite that at least one of position/orientation is required. However, it does not disclose potential side effects, whether the movement is instantaneous, coordinate system, or any state restrictions. The core behavior (moving/turning the avatar) is clear, but depth is lacking.

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 long and front-loaded with the primary purpose. The second sentence adds essential technical details without unnecessary filler. Every word contributes, making it highly concise and well-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?

Given the tool's moderate complexity (3 parameters, 1 required) and the presence of an output schema, the description covers the essential context: purpose, units, and the minimum-parameter condition. It doesn't fully explain all behavioral nuances (e.g., coordinate system, effects), but the output schema likely covers return values. It is reasonably complete for an experienced agent, though not exhaustive.

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 input schema already covers 100% of parameters with descriptions, so baseline is 3. The description adds meaningful value by clarifying that 'Position is metres' and that orientation is a quaternion (though schema hints at it). More importantly, it states the cross-parameter constraint 'At least one of position or orientation must be given,' which is not captured in the schema's required list. This goes beyond the schema.

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: 'Move and/or turn the client avatar.' This is a specific verb+resource combination that distinguishes it from siblings like teleport_connect or teleport_set_mode. The description also specifies the two possible actions (position and orientation), making its 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 by stating it moves/turns the avatar, but it does not explicitly mention when to use this tool versus alternatives or when not to use it. The added note 'At least one of position or orientation must be given' is a parameter constraint rather than tool-selection guidance. No exclusions or alternative tools are named.

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