Fractera

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

Annotations declare readOnlyHint=true and destructiveHint=false. The description goes further by detailing behavioral traits: it is a one-time read on demand, the deployment timing (8-14 minutes), and the return content (current step, completed steps, done/failed). This adds valuable context without contradicting annotations.

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 four sentences, front-loaded with purpose and usage. Every sentence provides essential information without redundancy, earning its place. It is both 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 has one parameter, no output schema, and no nested objects, the description is complete. It explains what the tool returns (current step, completed steps, done/failed), which is critical since there is no output schema. No gaps or ambiguities remain.

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 one parameter (session_id) with a description, and coverage is 100%. The description does not add new details about the parameter itself, but it provides context by stating where the session_id comes from (register_and_deploy or retry_deploy). This is marginally helpful, meeting 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 states the tool reads current installation progress on demand, specifies the verb ('Read'), the resource ('current installation progress'), and distinguishes from sibling tools like register_and_deploy and retry_deploy. It explains when to call (user explicitly asks, never on timer or polling), 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 provides explicit usage guidance: call only when the user explicitly asks about deployment status, never on a timer or in a polling loop. It also mentions authoritative status channels (email pipeline + dashboard), helping the agent decide when to use this tool versus 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool is safe. The description adds critical behavioral details: the token economy (call with no args for lightweight list, then with section id for full content), and the lang parameter for Russian users. No contradictions with annotations.

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 well-structured, starting with the purpose, then specific instructions, and a note on language. It is informative but slightly verbose; every sentence is useful, though some redundancy could be trimmed. Still, it remains clear and scannable.

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 absence of an output schema, the description fully explains what the tool returns: a lightweight list of section ids and titles when called with no arguments, or the full content of a specific section when called with a section id. It covers both invocation patterns and the lang parameter, making it complete for an agent to use 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 100% with both parameters described. The description adds meaning beyond the schema: it explains the exact usage pattern (omit section for table of contents, provide section id for content) and clarifies when to use the lang parameter. While the schema descriptions are adequate, the description enriches the context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool is a 'Project reference / help desk about Fractera' for answering any user question about Fractera. It distinguishes from siblings by specifying broad coverage (architecture, components, modes, etc.) while siblings like check_status or get_subdomain are more narrowly focused.

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?

Explicitly says 'use this to answer ANY user question about Fractera' and gives a when-not context: 'especially while a deploy is running and the user wants to learn more'. It provides a clear two-step process (token economy) with specific instructions on how to call the tool effectively.

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 mark it as read-only and non-destructive. The description adds context about the phase-1 address format (HTTP, IP, no domain/HTTPS), which goes beyond annotations.

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?

Description is well-structured with purpose, format, and usage instructions in a few sentences. Slightly verbose but each sentence 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?

Given the simple single parameter and no output schema, the description fully covers what the tool returns and when to use it, including edge cases like phase-1 constraints.

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%; the description does not add meaning beyond the schema's description of the session_id parameter. Baseline score 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 that the tool returns the final entry address of the server after installation, specifying the form in phase-1 and distinguishing it from siblings like check_status and get_project_info.

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?

Explicitly says to call this after check_status reports 'done', providing clear usage context. Does not explicitly mention when not to use, but the instruction is sufficient.

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 agent knows the call is safe. The description adds workflow context (user buys and returns) that goes beyond the annotation's safety signal.

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, no filler. First sentence conveys purpose and condition, second sentence provides actionable next step. Front‑loaded and 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?

Adequate for a simple zero‑parameter tool, but lacks explicit description of the output format (e.g., expected fields like provider name, plan). With no output schema, the description should clarify what 'recommended VPS provider' means structurally.

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 no parameters, so the baseline is 3. Description adds no parameter details, but none are needed.

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?

Clearly states the tool returns a single recommended VPS provider for users without a server. Unambiguous verb and resource, and distinguishes from sibling info tools by its specific subject.

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?

Explicitly states when to call: only when user explicitly says they have no server. Implies when not to use (if user has a server) and provides step‑by‑step expectation of subsequent user action.

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 destructiveHint true, but the description adds rich context: it wipes previous installations, creates multiple resources (User, Subscription, ServerToken), specifies deployment time (8-14 minutes), and explains IP-first behavior without domain/HTTPS. No contradiction with annotations.

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 front-loaded with the core action, then provides step-by-step context, and ends with invocation constraints. Every sentence adds value—no 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?

Despite lacking an output schema, the description fully explains return values (session_id, server_token) and their usage. The deployment flow is complete, including time estimates and follow-up actions.

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 description adds meaning by explaining the workflow behind each parameter (e.g., email_confirmed requires double-entry verification, terms_accepted requires explicit user consent in chat). This goes well beyond the schema's basic field 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 tool registers a Fractera user and deploys a server in one atomic call. It distinguishes itself from siblings like check_status and retry_deploy by specifying this is the initial deploy call.

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?

Explicitly says 'Use this AFTER you have collected the user's email...' and 'Call this AT MOST ONCE per conversation', providing clear when-to-call and when-not-to-call 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 destructiveHint=true, so the description adds value by specifying exactly what is destroyed ('Wipes the previous broken install'). This goes beyond the annotation's generic destructiveness flag. However, it does not mention authentication/authorization requirements for the server_token beyond stating it 'acts as authorisation', which is slightly vague.

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 concise sentences with no wasted words. The description front-loads the core action, then provides context on input sources and expected output. Every sentence serves a purpose.

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 there is no output schema, the description adequately notes the return value ('Returns a new session_id') and directs the agent to poll with check_status. For a 4-parameter tool with 100% schema coverage, the description covers all necessary context including when each optional parameter should be used.

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 each parameter description already explains usage well. The description adds value by clarifying that ip and password should only be passed if the user discovered errors (typo/wrong password), while login defaults to root. This provides practical guidance beyond schema definitions.

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 it retries a failed deployment using a server_token, wipes the previous broken install, runs a fresh deploy on the same server, and returns a new session_id. This differentiates it from sibling tools like register_and_deploy and check_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 explicitly says when to use this tool (when user reports a failed deploy or pastes a server_token) and how to get the token from specific sources (failure email, deploy-progress UI, or dashboard). It also suggests polling with check_status for the result, distinguishing usage from check_status itself.

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