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

With no annotations, the description carries the full burden, but it only provides the request format (bare JSON array to POST) without detailing side effects, idempotency, permission requirements, or what happens to existing project-chat associations. The 'Mirrors` reference is opaque without SDK knowledge.

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 short and front-loaded with the primary purpose. The 'Mirrors` line adds an implementation reference that is not essential but does not significantly bloat the text.

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 mutation tool with no annotations and no output schema, the description should at least hint at return values, error behavior, or idempotency. It only provides the request detail, leaving the agent uncertain about the operation's effects and outcome.

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 documents both parameters with descriptions and constraints (100% coverage), so the description adds no additional parameter-level meaning. 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 a specific action (add) with the resource (chats to a project) and qualifies both as existing, distinguishing it from creation tools. The explicit HTTP endpoint reinforces the operation's scope.

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 the tool ('Add existing chats to an existing project'), and there are no competing sibling tools for this specific action. However, it does not explicitly mention when not to use it or name 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 bears full responsibility for disclosing behavior. It explains the tool creates a chat (side effect), sends a prompt, waits for the response, and returns it including the chat UUID for follow-ups. It also explains streaming behavior and the influence of SYNTX_STREAM_MODE, adding context beyond a simple invocation. Missing details like authentication or rate limits, but the core flow is 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 four sentences long, each contributing needed information: what the tool does, when to use it, what the response includes, and a key parameter note. It is front-loaded with the core function and avoids unnecessary detail, though slightly longer than strictly necessary.

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 has 8 parameters and no output schema or annotations. The description covers the overall workflow and one parameter's mode, but does not elaborate on the meanings of several parameters (e.g., `timeout`, `poll_interval`, `model_type`, `ai_name`). It also omits error handling or return structure beyond mentioning the chat UUID. This is adequate for a simple mental model but incomplete for full parameter-level understanding.

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 only 38%, so the description must compensate. It adds context for the `mode` parameter ('stream' opts into real-time delivery) and implies the `prompt` parameter, but leaves parameters like `timeout`, `poll_interval`, `ai_name`, `model_type`, and `scope` without any explanatory semantics. The description does not fill the gaps left by 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: 'One-shot helper: create a chat, send a prompt, wait for the completed assistant reply, and return it.' This distinguishes it from sibling tools like create-chat, send-message, and wait-for-response by combining these steps into a single call. The 'one-shot helper' label reinforces its unified 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 'Ideal for stateless Q&A' provides clear contextual guidance on when to use the tool. It also mentions the ability to opt into streaming via `mode: "stream"`, offering a specific alternative within the same tool. However, it does not explicitly mention when not to use it or compare it to the step-by-step sibling tools, slightly limiting exclusion 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?

No annotations are provided, so the description must carry the full burden of behavioral transparency. It states the creation action and return value, but does not disclose authentication requirements, idempotency, or any side effects beyond creating a chat. This is a minimal disclosure 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 sentence that immediately states the core action and return value, with no redundant words. It is front-loaded and concise.

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 creation tool with three parameters and no output schema, the description covers the essential action and return value. However, it lacks context about authentication prerequisites or how this chat session will be used, which could be important for an agent to correctly invoke it.

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%, so the schema already documents all parameters. The description adds one semantic detail: 'A title is required by the API', which reinforces the required flag but provides no additional meaning for model or scope.

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 verb 'create' and the resource 'syntx.ai chat session', and specifies that it returns the UUID. This distinguishes it from sibling tools like delete-chat or list-chats, which have different purposes.

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 a usage constraint ('A title is required') but does not explicitly state when to use this tool versus alternatives. There are no mentions of exclusions or related tools, so guidance is implied rather than explicit.

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 discloses that the tool returns the created project as JSON (uuid, title, scope, color, chats), which informs the agent about the output. It also mentions the optional seeding behavior with existing chats, a key side effect. It lacks details on error cases or permissions but covers the core behavior well.

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 main purpose and then providing return format and a useful implementation hint. Every sentence adds value with no filler, and the structure is easy to scan.

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 provides the return format (JSON with specific fields), which substitutes for a missing output schema. The input schema fully documents all parameters. The tool's simplicity and clear sibling context (create vs. list/add/delete) make this sufficiently complete for an agent to correctly invoke it.

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 description coverage is 100%, with all four parameters already described in the schema. The description adds the phrase 'optionally seed it with existing chats,' which reinforces the meaning of chat_uuids but does not significantly extend beyond schema details. Therefore, 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 clearly states the action: 'Create a syntx.ai project (a.k.a. folder) and optionally seed it with existing chats.' It identifies the resource (project) and the specific capability (seeding with chats), which distinguishes it from sibling tools like list-projects or add-chats-to-project.

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 this tool: when a new project (folder) is needed, especially with optional initial chats. It also mentions the API mirror `syntx.folders.create`, providing context. However, it does not explicitly state exclusions or alternatives, 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, the description fully discloses the key behavioral trait: the action is destructive and cannot be undone. It also states 'Permanently delete' and provides the HTTP method, giving the agent a complete understanding of the operation's impact.

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 concise sentences, each serving a distinct purpose: stating the action, referencing the API mirror, and warning about destructiveness. It is front-loaded with the main purpose and contains no unnecessary words.

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 tool with one parameter and no output schema, the description covers the essential behavioral context (permanent deletion, reversibility) and the HTTP endpoint. It does not mention permissions or the response format, but the tool's simplicity makes this acceptable.

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 100% coverage with a clear description of chat_id ('Chat UUID or numeric id (required)'). The description's mention of the endpoint path reinforces this parameter but does not add additional semantic value beyond the schema. 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 tool permanently deletes a chat, with the verb 'delete' and resource 'chat'. It distinguishes itself from sibling tools like list-chats and create-chat by specifying the HTTP DELETE endpoint. This is a precise and unambiguous 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 clear context for use by emphasizing the destructive and irreversible nature of the action, which implies it should be used only when permanent deletion is intended. However, it does not explicitly mention alternatives or when not to use it, 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, the description carries the full burden of behavioral disclosure. It explicitly states 'permanently delete', which conveys destructive and irreversible behavior. It also clarifies the dual-input mechanism and the exactly-one constraint. It doesn't cover error cases or permissions, but the core behavior is well disclosed.

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 action and resource, and every clause adds information. 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?

For a simple delete tool with no output schema and full parameter coverage, the description is quite complete. It covers purpose, parameters, and the constraint. It could mention return values or error handling, but those are not essential for a delete operation and the tool's minimal 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 already provides descriptions for both parameters (100% coverage), but the description adds value by explaining that file_id is the 'historical behaviour' and url is the 'uploaded R2 URL, mirroring the SPA's file-storage.remove'. It also reiterates the mutual exclusivity constraint, which is present in the schema as anyOf but made explicit in prose.

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 the specific verb 'delete' with the resource 'uploaded file', and 'permanently' signals irreversibility. It clearly distinguishes from sibling delete tools like delete-chat and delete-project by specifying the resource type.

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 states the two accepted input modes (file_id or url) and the constraint that exactly one must be provided. It also gives context about the URL mirroring the SPA's file-storage.remove, but it doesn't explicitly exclude alternatives or provide when-to-use versus other delete tools. Still, the resource-specific nature makes the intended use 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 provided, the description takes on the full burden of behavioral disclosure. It explicitly warns 'This action is destructive and cannot be undone,' which is a critical behavioral trait for a deletion tool. It also states the HTTP method (DELETE) and 'Permanently delete' to reinforce irreversibility. However, it does not mention potential side effects, such as whether associated chats or files within the project are also deleted, which would be 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 compact and front-loaded with the action, followed by the API mapping and a clear irreversibility warning. Every sentence contributes substantive information without redundancy or fluff.

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 no output schema, the description is largely complete: it explains what is deleted, the endpoint, the destructive nature, and the parameter's role. It could optionally mention the response format, but given the structured schema and low complexity, the omission is acceptable.

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 with a description for the only parameter, folder_uuid, as 'Project UUID to delete (required).' The description adds minor semantic value by clarifying that a project is also called a folder and embedding the parameter in the API endpoint, but it doesn't extend meaning 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 specific action ('Permanently delete') and the resource ('a syntx.ai project (a.k.a. folder)'), which distinguishes it from sibling tools like delete-chat and delete-file. It also provides the exact API endpoint, leaving no ambiguity about what the tool does.

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 identifying the resource as a project/folder, but it does not explicitly state when to use this tool versus alternatives, nor does it offer exclusions or alternative tool guidance. The phrase 'Mirrors `syntx.folders.delete`' hints at an equivalent API but doesn't clarify when that API should be chosen instead.

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 and does so well. It discloses the HTTP endpoint, the prerequisite of a chat UUID, and the asynchronous nature of the result (generation metadata returned; audio URL available later via polling). This goes beyond what the schema alone conveys.

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 efficient and front-loaded with the core purpose, then adds contextual details about the endpoint, prerequisites, and follow-up. Every sentence contributes useful information, though the 'Mirrors...' sentence could be seen as minor redundancy for some users.

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 complexity (10 parameters, nested objects) and lack of an output schema, the description covers the essential workflow: create chat, generate audio, then poll for the URL. It explains the result shape at a high level (metadata and URL) and clarifies dependencies (chat_uuid). This is appropriate, though it does not cover all edge cases or error handling.

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 100% parameter coverage with detailed descriptions, so per the baseline the description need not compensate. While the description mentions the endpoint uses ai_name and that chat_uuid is required, it adds little beyond the schema's existing field explanations.

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 and resource: 'Generate audio (TTS, voice change, music) via syntx.ai.' It also distinguishes from sibling tools like generate-image and generate-video by focusing on audio and listing audio-specific use cases.

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 concrete usage context: it requires a chat UUID created with create-chat first, and notes that follow-up with wait-for-response or get-messages is needed to retrieve the completed audio URL. It does not explicitly exclude alternatives, but the audio-specific purpose and prerequisite make its role 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 provided, the description carries the full burden of disclosing behavior. It does mention the chat UUID requirement and the return of metadata, but it omits important traits such as side effects on the chat, cost implications, asynchronicity, or whether any preconditions like authentication are needed. This is a significant gap for a generation 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 two short sentences, front-loaded with the core action in the first sentence. Every word adds value, with 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?

Despite the tool's complexity (9 parameters, nested objects, no output schema), the description is minimal and lacks operational context. It does not explain prerequisites (e.g., authentication, balance), whether generation is synchronous, how the feature interacts with chat workflows, or what the returned metadata looks like. The schema covers parameter details, but the description is not complete enough for an agent to fully understand the tool's role.

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 (n, ai_name, quality, model_settings, etc.) is already well described in the schema. The description adds little beyond what the schema provides, so it meets the baseline expectation without needing to compensate.

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 generates one or more images on syntx.ai using a design service (e.g., sora-images, flux), which is a specific verb+resource. It distinguishes from sibling tools like generate-audio or generate-video, and mentions the key requirement of a chat UUID.

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 for image generation and provides context about requiring a chat UUID and returning generation metadata. It does not explicitly state when not to use this tool or name alternatives, but the context is clear enough for an agent to select 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. It discloses that generation is long-running and that users must poll to retrieve the video URL. This is valuable behavioral context beyond what annotations would provide. However, it does not mention potential side effects (e.g., creating chat messages), costs, or failure modes, so it stops short of a 5.

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 and every sentence earns its place: it states the action, notes the required precondition, and explains the async polling pattern. It is information-dense without being bloated, and front-loads the primary 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 the tool's complexity (13 parameters, nested objects, no output schema), the description provides essential flow context: it explains the endpoint, the required chat_id, the long-running nature, and how to obtain the result. The schema covers parameter details, and the description fills the behavioral gaps, making it complete for an agent to use effectively.

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%, so the baseline is 3. The description itself does not add parameter-level meaning; the schema's parameter descriptions are thorough and self-sufficient. The description's mention of the polling flow relates to output behavior rather than 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 opens with a specific verb+resource: 'Generate a video via syntx.ai.' It distinguishes itself from sibling tools by explicitly focusing on video generation and referencing the SPA flow. The purpose is unmistakable.

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 states prerequisites ('Requires a target chat UUID (use `create-chat` first)'), and follow-up actions ('poll the resulting chat with `wait-for-response` or `get-messages`'). It also directs users to `list-models` for valid `ai_name` values, providing clear context for when and how to use the 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?

No annotations are provided, so the description carries the full burden. It implies a read-only operation via 'Return' and specifies authentication scope, but it does not disclose potential rate limits, failure behavior, or return format. This is acceptable for a simple getter but lacks explicit safety disclosure.

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 that directly states the function, with no redundant words or filler. It is appropriately sized for the tool's simplicity.

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 has no parameters, no output schema, and no annotations. The description fully conveys the action and scope, but it does not specify the return type (e.g., number, object, unit). For a simple balance query, this is nearly 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 tool has zero parameters, so the schema fully covers parameter semantics. The description adds no parameter details, but none are needed; a baseline of 4 applies for zero-parameter tools.

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 the specific verb 'Return' and identifies the exact resource ('current token balance') and scope ('authenticated user'), making the tool's purpose unmistakable and distinct from sibling tools like get-profile or whoami.

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 explicit alternatives or exclusions are provided, but the description implies the tool is used to check the authenticated user's balance. Given the simple nature and absence of sibling balance tools, usage context is implied rather than explicitly stated.

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?

The description discloses some behavioral context by listing the underlying API endpoint ('GET /api/v1/chats/favorite/{chat_id}/messages') and referencing a mirrored function, which implies a read-only GET operation. However, with no annotations, it does not fully describe response format, ordering, pagination behavior, or any permissions needed, so it leaves key behavioral traits undisclosed.

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 with a distinct purpose: primary function, API mapping, and usage guidance. It is front-loaded with the main verb/resource, contains no redundant wording, and uses special formatting for code/endpoints to enhance readability.

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 covers purpose, endpoint, and usage distinction, but omits details about pagination behavior (despite page_size/direction parameters), output structure (no output schema provided), and potential ordering semantics. Given that the tool has three parameters and no output schema, the description provides a serviceable but incomplete picture.

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 only 33% (only chat_id has a description), and the tool description adds no parameter-level meaning beyond that. The 'direction' and 'page_size' parameters have no explanation in either the description or schema (beyond enum values and numeric bounds), and the description does not compensate for this 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 description clearly states the tool's function: 'Return the favorite (bookmarked) messages for a chat.' It uses a specific verb ('return') and resource ('favorite messages'), and explicitly distinguishes from sibling tools by noting that 'get-messages does not include them' and that this is 'the only way to read starred messages through MCP.'

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 guidance on when to use this tool versus the alternative: 'This is the only way to read starred messages through MCP — get-messages does not include them.' It names the sibling tool directly and clarifies the exact scope difference, providing clear when/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 provided, the description carries the full behavioral burden. It explains the return semantics (empty array meaning, entry fields), the endpoint hit, and the mirrored library method. It does not cover auth, errors, or rate limits, but for a simple GET this is strong disclosure.

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 3 sentences, front-loaded with the core action, and each sentence earns its place: purpose, endpoint/mirror, return semantics, and usage context. No fluff 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 single-parameter GET tool with no output schema, the description covers purpose, behavior, return format, and usage context. It also gives enough detail to distinguish it from related tools. The description is fully complete for an agent to select and invoke it 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% for chat_id with description 'Chat UUID or numeric id (required)'. The tool description mentions chat_id only in the endpoint URL and does not add additional semantic details beyond the schema, so the baseline 3 applies.

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

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

Description clearly states 'Return the in-progress generations for a chat' with a specific verb and resource. It also distinguishes itself from siblings by focusing on in-progress generations and explicitly mentioning its role as a gate for wait-for-response.

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?

Provides clear context: used to check if anything is currently generating, with empty array meaning nothing in progress. It mentions it is used internally by wait-for-response, giving practical when-to-use guidance, though it does not explicitly state when not to use it or list 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 full responsibility for behavioral disclosure. It states the core read operation but omits key behaviors such as pagination semantics (direction, page_size), whether messages are returned in chronological order, or any side effects. This lack of detail is a significant gap for a tool with multiple retrieval options.

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 of 11 words, front-loading the primary action and resource. No filler or redundant information, making it maximally concise and easy to parse.

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 has pagination parameters (direction, page_size) and no output schema, but the description explains none of this mechanics. The agent would not know how to use direction or page_size correctly, or what the response structure looks like, leaving the description insufficient for effective 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 coverage is only 33% (only chat_id has a description), and the description adds no value beyond restating that chat_id accepts UUID or numeric id. Direction and page_size remain semantically unexplained, and the description does not compensate for the low 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's function: returning message history for a specific chat, with the identification method (UUID or numeric id) explicitly mentioned. This distinguishes it from siblings like send-message or list-chats, 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?

No guidance is given about when to use this tool versus alternatives. It does not mention sibling tools, exclusions, or prerequisites, leaving the agent to infer usage context 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 full burden. It discloses that the return includes pricing/cost params and limits, but it does not cover side-effect-free behavior, error cases, auth requirements, or rate limits. Minimal transparency beyond the literal return content.

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, no filler, every word earns its place. The key information (what it returns and for what resource) is at the beginning.

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 too thin for a tool with 7 parameters and no output schema. It hints at return content but does not explain return structure, possible error states, or how the extra parameters (mode, quality, batch_size, chars_count, video_duration) affect the result. The high parameter count and low schema coverage make the description inadequate.

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 provides zero parameter-level meaning. Schema description coverage is only 29% (2 of 7 params described), and the description does not compensate by explaining how to specify the model or what 'mode', 'quality', etc., affect the result. The required parameters are only implied by the phrase 'specific AI model'.

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 specific verb ('Return detailed information') and resource ('specific AI model'), and the parenthetical '(pricing/cost params, limits)' adds scope. This distinguishes it from siblings like list-models or list-ai-services.

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 'specific AI model' implies when to use (when you need details of one model rather than listing all), but no explicit alternatives or exclusions are mentioned. The usage context is implied rather than directly stated.

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 full behavioral transparency. It discloses that internal identifiers are stripped, that the tool requires authentication, and that it raises an error when no token is set. These are useful behavioral details beyond the raw 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?

The description is three sentences, front-loaded with the primary purpose, and each sentence adds value: purpose, sanitization behavior, and alternative. 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?

Despite having no output schema and no annotations, the description is complete for a simple zero-parameter tool. It lists the returned fields, explains sanitization, mentions authentication/error behavior, and gives a clear alternative for a different use case.

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, and the schema is empty, so there are no parameter semantics to explain. Per the rubric, a zero-parameter tool gets a baseline of 4. The description does not need to add parameter details.

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 'Return the current user profile' with a specific verb and resource, and lists the sanitised public fields. It distinguishes itself from the sibling tool 'whoami' by contrasting error behavior and return shape.

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 'For a non-erroring identity check, use `whoami` which returns { authenticated, user }', providing clear guidance on when to use an alternative. It also notes the authentication requirement, helping the agent decide if this tool is appropriate.

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 full transparency burden. It discloses that the tool returns 'scope and status' for each service, but it does not explicitly state whether the operation is read-only or has side effects. For a list operation, the verb implies non-destructive behavior, but additional context like authentication or rate limits is absent.

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 immediately states the action and object, followed by examples and return attributes. It contains no filler words and is 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?

The description provides essential information: what is listed (AI services), examples, and the included attributes (scope and status). Since there is no output schema, this is adequate for a simple list operation, though it could mention the exact output format or whether pagination applies.

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 no parameter semantics, which is appropriate since there are no parameters to document.

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 'List' and identifies a distinct resource ('all syntx.ai AI services') with concrete examples (ChatGPT, Midjourney, Sora). This clearly differentiates it from sibling tools like 'list-models' or 'list-chats', 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 clearly scopes when to use the tool (when an inventory of AI services is needed) but does not explicitly contrast it with alternative list tools. The clear scope provides enough context for an agent to select it, but lacks explicit exclusions or alternative recommendations.

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 does not mention read-only behavior, pagination, default ordering, authentication, or any side effects. The optional filters are mentioned, but the direction and page_size parameters are not explained beyond the schema, leaving significant behavioral traits undisclosed.

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 with no redundant words. It quickly conveys the core purpose. However, it is so brief that it leaves out important context, but conciseness itself is well-handled.

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 4 parameters, no output schema, and no annotations, the description is too minimal. It does not cover pagination behavior, default values, or when to use this tool among many sibling list tools. The description lacks the richness needed for an agent to fully understand the tool's behavior and 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 description coverage is 50%, covering scope and search, but direction and page_size lack descriptions. The description merely repeats the existence of scope and search filtering without adding meaning for the other parameters or clarifying their semantics. It fails to compensate for the uncovered parameters.

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 lists user chats and mentions optional filtering by scope or search query. This is specific and distinct from siblings like get-messages or list-models, though it does not explicitly differentiate by naming alternatives. The verb 'list' and resource 'user chats' are clear.

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 list-ai-services or get-messages. The description only states what the tool does, not the context in which it should be selected, nor any exclusions or prerequisites.

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 behavioral disclosure. It does add useful context: filters are combined with AND, active_only defaults to true, and search is case-insensitive. However, it does not mention pagination, result limits, or the exact shape of the response, which are relevant for a list endpoint.

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 compact, with the main purpose front-loaded in the first sentence and filter details structured in the second. The second sentence is dense but organized with backticks and examples. Overall, every sentence provides useful information without padding.

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 no output schema, the description should give some indication of return structure. It mentions returned fields ('upload constraints, supported media types, and features') but does not describe pagination, ordering, or how to handle empty results. For a list tool with multiple filter options, this is adequate but not fully 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?

Schema coverage is 100%, so a baseline of 3 applies. The description adds value beyond the schema by explicitly stating that all filters are optional and combined with AND, and by summarizing the scope buckets and search semantics. This helps the agent assemble correct queries without reading deep into each schema property.

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 ('List') and resource ('AI models') and elaborates on the returned details ('upload constraints, supported media types, and features'). It is clear but does not explicitly distinguish from sibling tools like list-ai-services or get-model-info, leaving some 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 intended use is implied: to list AI models with optional filters. However, there is no explicit guidance on when to choose this tool over alternatives (e.g., list-ai-services for services, get-model-info for a single model). The context is clear but exclusions or alternative conditions are not stated.

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 explicitly discloses that the tool uses a GET request (Hits `GET /api/v1/folders/{scope}/list`) and returns an array of Folder items, which implies read-only behavior and gives a clear expectation of the response shape.

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 concise sentences, front-loaded with the purpose, followed by implementation details (SDK mirror, endpoint, return type). No filler or redundant 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?

For a simple tool with a single optional parameter and no output schema, the description is complete: it gives the endpoint, the return type, and the parameter default. It sufficiently covers all necessary context for an agent to invoke it 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 description coverage is 100%, and the schema already explains the 'scope' parameter and its default. The description adds a synonym (folders) and mentions mirroring specific SDK functions, but these don't deepen understanding of the parameter itself.

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 clear verb (List) and resource (projects/folders) with a scope qualifier, and even names the underlying SDK functions and API endpoint. This distinguishes it from sibling tools like list-chats or list-models, which target different resources.

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 indicates the context (listing folders by scope) and mentions the default scope via schema. It does not explicitly exclude when not to use it, but the name and clear resource targeting make the 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 provided, the description must carry the full burden of behavioral disclosure. It only states that the tool lists files, without indicating whether it is read-only, how pagination behaves, what file metadata is returned, or any authentication requirements. This is notably sparse.

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 that is front-loaded and free of unnecessary words. However, it could be slightly improved by adding a second sentence with usage context, but as-is it is acceptably concise.

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 has no output schema and no annotations, so the description is the primary source of context. It lacks critical details such as pagination (page/page_size), filtering by scope, and what the returned list contains. This incompleteness could lead to incorrect assumptions about the tool's behavior.

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 only 33% (scope has a description, but page and page_size do not). The tool description does not mention any parameters or compensate for the missing parameter information, leaving the agent without guidance on pagination behavior or default values 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 uses the specific verb 'list' and clearly identifies the resource as 'files previously uploaded to the syntx.ai account'. This distinguishes it from sibling tools like upload-files and delete-file, 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 for retrieving previously uploaded files but provides no explicit when-to-use guidance or alternatives. It does not mention that this is the read-only counterpart to upload-files or that it should be used instead of list-chats or other list 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, the description carries the burden of behavioral disclosure. It transparently states that the tool returns immediately and the response is generated asynchronously, plus directs to how to retrieve the result. However, it does not disclose what the immediate return value contains (e.g., message ID), which is a minor gap given no output schema.

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 immediately clarifies async behavior and alternatives. No filler or redundant information; every clause 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 5-parameter tool with no output schema and no annotations, the description provides a clear usage flow: send async, then poll or use blocking alternatives. It mentions existing chat and optional attachments, covering key prerequisites. However, it omits specifics about the immediate return value and potential error conditions, leaving slight ambiguity.

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 baseline is 3. The description reinforces that attachments are optional and that chat_id refers to an existing chat, but it does not add meaningful semantic detail beyond what the schema already provides (e.g., attachment structure, ai_name vs model_type).

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 sends a message (prompt) with optional file attachments to an existing chat and returns immediately. It distinguishes itself from siblings by explicitly noting the asynchronous nature and naming alternatives (wait-for-response, ask, stream-message), making it easy to select.

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 on when to use this tool versus alternatives: use this for async non-blocking send, poll with wait-for-response, or use ask/stream-message for a single blocking call. This directly addresses selection criteria and excludes other 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?

No annotations are provided, but the description fully compensates by disclosing key behavioral traits: the token is held in memory only, not persisted to disk, and lost on process restart. It also explains that the tool is rejected over HTTP transport for security reasons (preventing remote hijacking), which is significant 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 three sentences, each carrying distinct information: purpose, usage condition, in-memory persistence, and transport restriction. It is front-loaded with the main action and adds essential caveats 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?

Considering the tool's simplicity (one parameter, no output schema), the description is remarkably complete. It covers when to use it, how it behaves (in-memory, lost on restart), and a critical security constraint (stdio-only), leaving no obvious gaps 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% for the single 'token' parameter, so the schema already documents its meaning. The tool description adds no further parameter-level semantics beyond what the schema states, but it also doesn't need to given the simple, self-explanatory 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: setting or replacing the syntx.ai bearer token used by the server at runtime. It names the specific resource (syntx.ai bearer token) and action (set or replace), and the scope (used by server at runtime) distinguishes it from any sibling tool.

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 when-to-use guidance: 'Call this before any authenticated operation if SYNTX_TOKEN was not configured.' It also provides a clear alternative for HTTP transport (configure via the SYNTX_TOKEN env variable) and states the tool is stdio-only, preventing misuse over HTTP.

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 to rely on, the description fully carries the burden and provides substantial behavioral detail: it opens a WSS connection, streams replies, reports progress via notifications/progress when a progressToken is supplied, returns the complete text in the final result, and falls back to REST polling on transport failure unless mode is explicitly set to 'stream'. This level of disclosure exceeds typical tool descriptions.

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 well-structured sentences, immediately stating the core function and then layering important operational details. Every sentence carries meaningful information, with no redundancy or fluff.

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 streaming tool with no output schema and no annotations, the description covers the core behavior, fallback mechanism, and progress reporting, which is commendable. However, it could be more explicit about the exact shape of the final tool result or potential error conditions, leaving moderate room for improvement.

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 57%, with mode, model, prompt, and timeout already described. The description adds some nuance for mode's effect on fallback, but it does not clarify the purpose of scope, ai_name, or model_type, which lack schema descriptions. Since the description doesn't compensate for these unannotated parameters, it provides only marginal value 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 opens with 'One-shot streaming chat' and specifies WSS connection, prompt sending, and real-time streaming, which clearly differentiates it from sibling tools like send-message or wait-for-response. It also details the fallback to REST polling, further clarifying the tool's unique scope.

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 (streaming chat) and explains the auto/stream/poll modes, including fallback behavior. However, it does not explicitly contrast with alternative chat tools or state when not to use it, leaving some inference to the agent.

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 security-related behavior (path rejection over HTTP), constraints (50 MB limit, accepted formats), and the return shape ({ text }). It doesn't cover auth or rate limits, but the key behaviors are well explained.

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 paragraph. It front-loads the purpose, then covers transport, limits, and return. There is no fluff, though it could be more structured with bullets, but it's concise and informative.

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 4 parameters with no required fields, no output schema, and no annotations, the description is quite complete. It explains the main operation, parameter selection, constraints, and return format, leaving few unanswered questions.

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%, so the baseline is 3. The description adds value by emphasizing the transport-specific behavior of `path` and `content_base64`, and clarifies `filename` is required with `content_base64`, complementing the 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 tool's function: 'Transcribe an audio file to text via syntx.ai (POST /api/v1/audio/transcribe).' It uses a specific verb and resource, and clearly distinguishes from siblings like generate-audio.

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: it directs using `path` for stdio and `content_base64` for HTTP, warns that `path` is rejected over HTTP, and specifies size and format limits. This effectively tells when and how to use the 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 and discloses important behavioral constraints: max 10 files per call, 100 MB per file, required filename for base64, MIME auto-detection, and the exact return shape. It does not mention side effects like storage consumption or duplicate handling, but the core behavior is well 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?

The description is compact and front-loaded: the first sentence states the purpose, and the following sentences efficiently cover constraints, parameter nuances, and return value. Every sentence carries useful information 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?

Despite lacking an output schema, the description explicitly provides the return format, limits, and input modes, making the tool fully usable. The minor absence of duplicate-handling details is mitigated by the schema's default value description, so the overall context is 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?

Although the schema already describes all parameters (100% coverage), the description adds practical meaning beyond the schema: it explains the optional data: prefix, clarifies mutual exclusivity of path and content_base64, and emphasizes that filename is required for base64 entries. This adds real value over the raw 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 opens with a clear, specific verb and resource: 'Upload one or more files to the syntx.ai account.' It also distinguishes itself from siblings like list-uploaded-files and delete-file by focusing on the creation/upload action.

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 explains two mutually exclusive input modes (path vs content_base64) and their requirements, which guides correct usage. It does not explicitly compare to sibling tools, but the upload action is distinct and unambiguous, so no alternative guidance is necessary.

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 full behavioral disclosure and does so thoroughly: it blocks until completion, resolves when every message_object[i].completed === true, handles media-only replies, and respects the server poll interval/timeout. This is far beyond a minimal description.

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?

Four short, front-loaded sentences each earn their place: core behavior, exact resolution condition, media handling, and usage hint. No wasted words and no redundancy with the schema.

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?

Even without an output schema or annotations, the description explains the return (text and media URLs), the blocking condition, the media-only case, and the timeout behavior. It doesn't specify edge cases like what happens on timeout expired or if there is no in-progress message, but it is still sufficiently complete for the intended use case.

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 67%, and the description adds little parameter-specific meaning. Timeout and poll_interval are already described in the schema as overrides, and chat_id is only implied via 'in a chat'. The description doesn't explicitly map these parameters beyond what the schema provides, so a mid-range score fits.

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 ('Block until') and clearly identifies the resource ('latest assistant message in a chat') and the action (waits for generation, then returns text/media URLs). This distinguishes it from siblings like get-messages or stream-message and explicitly ties it to send-message.

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 context with 'Use after `send-message`', clearly indicating when this tool is appropriate. It doesn't mention alternatives or when not to use it, so it falls short of a 5, but the usage context is unambiguous.

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, but the description thoroughly discloses behavior: never errors on missing/invalid tokens, returns { authenticated: false }, strips internal identifiers, and distinguishes auth failures from network errors. This fully covers the safety and error profile.

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 structured logically: output type, user object contents, stripped fields, error behavior, and usage. Each sentence provides essential information 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 there are no parameters and no output schema, the description fully compensates by detailing the return object, field composition, and error semantics. It leaves no ambiguity.

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 description cannot add parameter-level meaning. The baseline of 4 applies, and the description adds value by explaining the output shape and fields.

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 returns an identity check for the current syntx.ai user, with a specific output structure. It distinguishes itself from sibling tools like get-profile by focusing on authentication status verification.

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 it to verify authentication status' and explains when real errors occur, helping the agent decide when to call it. Does not mention alternatives or exclusions, but the 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.