Orbit

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is established. The description adds the user-scope detail but says nothing about return values, meaning of 'connected,' or how the optional token affects behavior. This is acceptable for a simple read-only check but does not go beyond the annotations significantly.

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?

A single, front-loaded sentence that states exactly what the tool checks. Every word earns its place, with 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 auth-status check with no output schema, the description plus annotations and the fully documented parameter provide enough context. It could mention the response shape or the role of the connection token, but the tool is small enough that this is a minor gap rather than a critical omission.

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 100%, so the optional connectionToken parameter is already documented. The description does not add any additional parameter meaning, and it does not need to because the schema covers 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 uses a specific verb ('Check') with a clear resource and scope: 'whether Orbit is connected for this user.' This immediately distinguishes it from siblings like connect_orbit and disconnect_orbit, which perform actions rather than read status.

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 makes the tool's context clear: it is a status check for a user's Orbit connection. It does not explicitly mention alternatives or when not to use it, but the purpose is distinct enough that no close sibling appears to overlap.

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?

Annotations already indicate this is not read-only and not destructive. The description adds that the tool validates the key, which implies an external check, and saves it persistently. However, it does not disclose whether reconnecting overwrites an existing key or what failure behavior looks like.

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 one concise sentence that states the action and its object without redundancy. It is front-loaded and contains no filler or vague qualifiers.

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 one-parameter tool with safety annotations, the description is largely complete: it conveys the operation and the app-specific scope. The main gap is the lack of any statement about return values or success/error behavior, especially since there is no output schema, but this is a minor omission for this tool's simplicity.

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 the single apiKey parameter completely, including its type, minimum length, and where to obtain it. The description adds no additional parameter-level detail, so the baseline score 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 uses a specific verb and resource: it validates and saves the user's Orbit API key. It clearly distinguishes this from siblings like disconnect_orbit and auth_status by framing it as the connection/setup action. The app-scoped phrasing adds useful precision.

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 this is used when a user wants to connect their Orbit account, but it gives no explicit guidance about when to choose this over auth_status or disconnect_orbit. No exclusions, prerequisites, or alternative-selection cues are 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?

Annotations already indicate this is a mutation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds that the action revokes the current token, which is useful, but it does not disclose consequences like permanence, effect on active sessions, or authentication requirements. With annotations present, the description is adequate but not 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?

The description is a single seven-word sentence that front-loads the key verb and object. There is no filler, and every word contributes to the meaning.

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 revocation action, the core intent is clear, but the description leaves some ambiguity about whether the connectionToken parameter is required and what happens if omitted. It also does not mention the success or error response, which is relevant given no output schema. Still, the action is straightforward and an agent can likely invoke it correctly with the schema.

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 a full description for the single parameter ('Current connection token'), giving 100% coverage. The tool description only restates that it revokes the Orbit connection token and does not add new details about format, origin, or whether the parameter is required. 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 uses a specific verb ('Revoke') and a distinct resource ('Orbit connection token'), making the tool's action unambiguous. It is clearly differentiated from the sibling connect_orbit, and the title reinforces the intent.

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 action itself implies usage when an Orbit connection token needs to be invalidated, but the description does not explicitly state when to use this tool or name alternatives. There is no guidance on prerequisites or scenarios where this would be inappropriate.

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?

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds useful context that the id must come from search_people, but it does not disclose other behavioral details such as return shape or error behavior. Given the annotations, a 3 is appropriate.

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 with no wasted words. The core function is front-loaded, and the critical usage caveat follows immediately. Every sentence earns its place.

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 single-parameter read-only lookup, the description is nearly complete: it states the resource, the source of the id, and the alternative. The lack of an output schema means it would be slightly better to hint at what 'detailed profile' includes, but this is not necessary 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?

Schema description coverage is 100% and the userId parameter is already described as 'Profile id returned by search_people, not a person name'. The tool description reinforces this but does not add new parameter-level meaning 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 states a specific verb and resource: 'Get a detailed profile for a specific person by an id'. It also explicitly differentiates from search_people by saying it is not for names or natural language, 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?

It gives explicit when-to-use and when-not-to-use guidance: 'Do not use this for names or natural language; call search_people first.' This directly routes the agent to the correct sibling tool and clarifies the prerequisite.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context by noting the operation targets the authenticated user and returns the same data shape as get_profile, but it does not disclose additional behavioral details such as authentication requirements or response specifics beyond what annotations imply.

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, focused sentence that front-loads the operation and resource, then adds the distinguishing comparison to get_profile. There is no redundant or filler content.

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 parameterless, read-only tool, the description is mostly complete: it states what the tool returns and how to distinguish it from get_profile. However, return details are delegated to get_profile rather than enumerated, and there is no output schema, so the description relies on the agent having or finding get_profile's definition for full 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?

The tool has zero parameters, so there is nothing for the description to explain beyond the input schema. Per the rubric, 0 params gives a baseline of 4; the description does not need to add parameter-level detail.

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 ('Get') with a clear resource ('the authenticated user's own Orbit profile') and explicitly distinguishes it from get_profile by scoping to the current user. An agent can immediately tell what this tool does and how it differs from its most similar sibling.

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 clearly positions this tool against get_profile ('same detailed profile data... but for the current user'), which tells the agent when to choose this instead of get_profile. It does not explicitly mention exclusions or other alternatives like whoami or auth_status, but the core usage 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?

Beyond the readOnly and openWorld annotations, the description discloses important behavioral expectations: call the tool directly, avoid assistant narration, and rely on tool status text and widget output. This adds practical insight into how the tool behaves and how the agent should respond after invocation.

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 exceptionally concise: two sentences that front-load the core function, then immediately give actionable invocation behavior. Every sentence earns its place, with no redundant 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 simple tool signature, full schema coverage, and rich annotations, the description covers the main operational needs: what the tool does, when to invoke it, and how to handle the interaction. The only notable gap is the lack of explicit differentiation from search_people_updates, though the sibling name and 'people' focus make the distinction largely inferable.

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 100%, so the parameters query and connectionToken are already documented clearly in the input schema. The tool description does not add additional parameter-level meaning beyond what the schema provides, matching the baseline 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 clearly identifies the verb and resource: 'Search for people by name, description, or natural language query.' It also specifies the acceptable query types, which helps an agent understand scope. However, it does not explicitly distinguish this tool from the sibling search_people_updates, so differentiation must be inferred.

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 explicit invocation guidance: 'Invoke immediately when the user asks to search Orbit' and instructs the agent to avoid preambles. This is clear context for when to use the tool. It does not mention when not to use it or point to alternatives, so it falls short of full routing 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context that updates are incremental and tied to a live session, but it does not disclose behaviors like cursor progression, session expiration, or whether updates are consumed by polling.

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 wasted words. It front-loads the key behavior ('Fetch incremental updates') right after the tool name and avoids repeating schema or annotation 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?

The description is adequate for a read-only fetch tool with fully documented parameters, but it leaves the cursor/polling loop unexplained: an agent may not know whether the response contains a new cursor to feed back in subsequent calls. Since there is no output schema, a bit more guidance about the incremental update cycle would improve 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?

Schema description coverage is 100%, and each parameter already has a meaningful description in the schema. The tool description adds no new parameter-level detail, so the baseline score 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 uses a specific verb ('Fetch') with a precise resource ('incremental updates for an active search_people request'). It clearly distinguishes this follow-up tool from the initial search_people tool, and 'incremental' signals delta or pagination behavior rather than a fresh search.

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 states the prerequisite explicitly: this is for an active search_people request. That makes it clear the tool should be called after search_people rather than as an initial entry point. It does not explicitly name alternatives or non-use cases, but the context is strong enough for an agent to infer the intended flow.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the API-key requirement, which is a meaningful behavioral constraint beyond the annotations, but it does not describe output format or failure behavior. This matches the level of added context in the calibration high example, which received a 3.

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?

A single, front-loaded sentence states the action and then adds one crucial constraint. There is no redundancy or filler, 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?

For a zero-parameter read-only tool, the description covers the purpose and authentication requirement. However, it does not disambiguate from closely related siblings ('me', 'get_profile', 'auth_status'), and without an output schema, return details remain vague. The agent may not know exactly which sibling to select.

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 by the rubric. The description does not need to explain parameter semantics, and adding any would be unnecessary.

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 ('Get') and resource ('information about the currently authenticated user'), making the core purpose clear. However, it does not distinguish itself from sibling tools like 'me' or 'get_profile', which likely serve a similar 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 phrase 'Only available when using an API key' provides a clear availability condition, implying an important usage constraint. Yet the description offers no alternatives or when-not-to-use guidance, leaving the agent to infer when this tool should be preferred over overlapping siblings.

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