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

With no annotations, the description carries the burden well: it discloses the transport (multipart/form-data), the endpoint, the repeated `files` field encoding, and the security-relevant LFI restriction on `path`. It omits auth/permission requirements and whether attaching replaces or appends to existing agent files.

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 front-loaded sentences: purpose, wire format, then the caveat. The `syntx.agents.addFiles` mirror reference is the weakest sentence but still useful for cross-referencing SDK users; nothing else is 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?

For a 2-parameter tool with a fully documented schema and no annotations, the description covers invocation mechanics well. However, with no output schema, it says nothing about what is returned after attaching (file IDs, list of attached files) or what happens to already-attached files, leaving a gap an agent will hit after the call.

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, but the description adds meaning the schema does not: how `files` is serialized (field repeated once per file) and that `path` triggers a server-side read that fails over HTTP. That materially changes how an agent should populate the array.

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?

States a specific verb and resource ('Attach one or more files to an AI agent') and pins down the exact HTTP operation it wraps. It is clearly distinguishable from siblings like upload-files, list-agent-files, and delete-agent-files.

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?

Gives real operational guidance: the LFI caveat from upload-files carries over, and `path` is rejected over the HTTP transport, which steers callers toward `content_base64`. It stops short of explicitly stating when to prefer this over upload-files or delete-agent-files, so no full when/when-not matrix.

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, 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 carries the burden and does well: it discloses the full lifecycle (create, send, wait, return), that the chat UUID is returned for follow-ups, and that streaming defaults are governed by the SYNTX_STREAM_MODE environment variable. It omits failure semantics (timeout behavior, partial failures), keeping it below 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?

Three front-loaded sentences with zero waste; the core behavior comes first, then the stateless-Q&A framing, then the optional streaming note.

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?

No output schema exists, and the description does explain the return value (the assistant reply plus the chat UUID). It is nearly complete for a one-shot tool, with only the undocumented optional parameters leaving a gap.

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% across 8 parameters. The description only touches `mode: "stream"`, and says nothing about scope, ai_name, timeout, model_type, or poll_interval, so it fails to compensate for the documented gaps.

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 compound verb sequence: create a chat, send a prompt, wait for the reply, and return it. This clearly distinguishes it from siblings like create-chat, send-message, and wait-for-response, which each do only one of those steps.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a clear use case: 'Ideal for stateless Q&A', and mentions follow-ups via the returned chat UUID. It stops short of explicitly stating when to prefer the lower-level siblings instead, so it is clear context without exclusions.

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

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

With no annotations, the description has to carry the full behavioral burden, and it does disclose the most important quirk: a 404 is treated as success because the message already finished, which affects how the agent should interpret the result. It says nothing about idempotency on repeat calls, what happens to a partially generated message, or any auth requirements, so significant ground is left uncovered.

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 short sentences: purpose first, then the SDK mirror and endpoint, then the 404 quirk. Every sentence earns its place and nothing is padded.

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 two-parameter mutation with full schema coverage and no output schema, the description covers the essentials, including the non-obvious 404-as-success rule that would otherwise mislead an agent. The only real gap is the absence of any comparison with delete-message.

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 both chat_id and message_id are already documented, including that chat_id can be a UUID or numeric id. The description adds no parameter meaning beyond what the schema provides, which is the expected baseline when the schema does the heavy lifting.

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?

States a specific verb and resource: cancel an in-flight assistant message generation, and pins it to a concrete endpoint. It's clear what the tool does, but it doesn't name the nearby sibling delete-message, so the boundary between canceling a generation and deleting a message is left for the agent to infer.

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 'in-flight assistant message generation' implies when to use it (while a generation is still running), but there is no explicit when-not guidance and no mention of the alternative, delete-message, which appears in the sibling list. Usage is implied rather than 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 well: it discloses the backing endpoint and the exact 404→false / 200→true mapping, which is the key behavioral contract an agent needs. It omits auth requirements and any rate-limit or latency notes, keeping it 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?

Two sentences with zero filler; the purpose and the pre-flight framing are front-loaded before the endpoint detail. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a trivial one-parameter boolean check with no output schema, the description supplies everything needed: purpose, when to call, and how responses map to true/false. Nothing required to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single chat_id parameter is already documented as 'Chat numeric id or uuid.' The description's '(by id or uuid)' merely restates the schema, adding no new format or edge-case guidance, so 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?

States a specific verb (returns whether ... exists) and resource (a chat, by id or uuid), and frames it as a pre-flight check, which distinguishes it from list-chats and get-messages. An agent can tell what it does without opening the schema.

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 it before `send-message` when holding a stale reference, naming the sibling and the triggering condition. It stops short of stating when NOT to use it (e.g., after a fresh create-chat) 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?

With no annotations provided, the description must carry the behavioral burden. It usefully discloses the HTTP method, multipart/form-data encoding, and that enabled_tools/default_models travel as JSON strings, but it does not cover authentication requirements, side effects, or post-creation behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose, followed by implementation details in a logical order. It is mostly efficient, though 'Mirrors syntx.agents.create' and 'the web client enforces the same' are slightly less essential than the rest.

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 create tool with no annotations and no output schema, the description gives the agent enough to construct a correct call: endpoint, required fields, and multipart serialization details. It does not describe return values or auth, but the schema coverage is complete for parameters.

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 parameter meaning is already well documented. The description adds value by reiterating the three required fields and, more importantly, explaining that enabled_tools/default_models are objects serialized as JSON strings inside the multipart body.

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 and resource: 'Create an AI agent' and references the specific API endpoint. It is distinguishable from list/get/update/delete siblings by the verb, though it does not explicitly name an alternative sibling as a contrast.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no explicit guidance on when to use create-agent versus update-agent, list-agents, or other sibling tools. Usage is only implied by the verb 'Create', with no when-not or alternative conditions 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?

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 provided, the description carries the burden and does well: it flags destructive, irreversible behavior and the exact HTTP call, which is the critical safety information. It omits secondary effects (what happens to the agent's files, chats, or whether the call requires elevated permissions), leaving a modest gap.

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 short sentences: what it does, how it maps to the API, and the safety warning. The destructive-risk warning is placed last for emphasis with zero filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter destructive tool with no annotations and no output schema, the description covers identity, endpoint, and irreversibility well. The only missing pieces are post-delete side effects and the response shape, which is minor since no output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the `agent_id` property already documents that it is an agent UUID from `list-agents`. The description only restates that the UUID is placed in the URL path, adding no new format or constraint detail, so 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?

States a specific verb and resource ("Permanently delete an AI agent") and pins the exact backend operation (`syntx.agents.delete`, `DELETE /api/v1/agents/{agent_id}`). This is clearly separable from siblings like `delete-agent-files`, `update-agent`, and `get-agent`.

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?

Gives an explicit operational precondition — "confirm before invoking" — which tells the agent this must not be fired off autonomously. It does not name alternatives (e.g. `update-agent` or `delete-agent-files` for narrower cleanup), so it stops short of full when/when-not routing.

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 does carry useful weight: it explicitly flags the operation as destructive, requires confirmation, and names the underlying SDK method and HTTP verb. But critical behavior is undisclosed — whether this unlinks files from the agent or permanently deletes them from storage, whether it is reversible, and how partial failures across multiple `file_ids` are handled.

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 short sentences with the destructive warning placed last, which is a reasonable emphasis position. The "Mirrors `syntx.agents.deleteFiles`" sentence is marginal value for an agent that cannot call the SDK, but it is one clause and does not bloat the definition.

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 two-parameter destructive tool with no annotations and no output schema, the definition covers identity, endpoint, and the confirmation requirement. It stops short on the two things an agent most needs before a destructive bulk call: the blast radius (unlink vs. permanent delete) and what the response reports back.

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 both parameters are already fully documented in the schema, including where to obtain `agent_id` and `file_ids`. The description only restates the payload shape `{file_ids: [...]}` and the path segment, adding no new meaning about ordering, limits, or atomicity.

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?

"Remove files from an AI agent" gives a specific verb and a scoped resource, and the endpoint path `DELETE /api/v1/agents/files/delete/{agent_id}` pins down exactly which operation this is. It is clearly not `delete-agent` or `delete-file`, but the description never explicitly contrasts with those siblings, so differentiation is inferred rather than stated.

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?

"Destructive — confirm before invoking" is a real usage directive, and the schema's references to `list-agents` and `list-agent-files` imply the prerequisite lookup workflow. However, there is no guidance on when to choose this over `delete-file` (deleting a file outright) or when to use `add-agent-files` to correct a mistake, so the when/when-not is only implied.

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?

Without annotations, it carries the behavioral burden well by stating the action is destructive and irreversible, and it identifies the underlying endpoint. It omits permissions or error behavior, but covers the key risks for a delete operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the core action and immediately followed by the important destructive warning and endpoint detail. No wasted 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 simple one-parameter delete tool with no output schema, the description covers purpose, destructiveness, and the endpoint sufficiently 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 coverage is 100%, so the parameter is already documented. The description adds useful path context by clarifying there is no chat id in the URL, only message_id.

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?

States a specific verb and resource: permanently deleting a single message. It clearly distinguishes this from deleting a chat or file, and the scope is 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?

Makes clear this is for permanent deletion of one message and warns that the action cannot be undone. It does not explicitly compare with siblings like delete-chat or toggle-message-favorite, but the destructive context is clear.

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

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

With no annotations 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 burden; it discloses the HTTP method/path (GET /api/v1/agents/info/{agent_id}) and lists the returned fields, indicating a read operation. It omits error behavior, permissions, and whether missing IDs return null or error, so it is strong but not complete.

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?

Front-loaded with the core action, followed by concise implementation and return-shape details. It is efficient and contains no filler, though the SDK mirror mention is marginally useful.

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?

Since there is no output schema, listing the returned fields is valuable and sufficient for an agent to understand the response shape. No annotations exist, but the GET endpoint and return fields communicate the key read-only behavior; only error/permission details are missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the sole parameter is already documented as an agent UUID from list-agents. The description adds no parameter semantics beyond what the schema provides, so the 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?

States a specific verb and resource ('Fetch one agent's full record') and explicitly scopes it to a single agent, which distinguishes it from sibling list-agents. The endpoint and return fields reinforce exactly 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?

Clear that this is for retrieving one agent when the agent_id is known, and the parameter description ties it to list-agents. It does not explicitly state when to avoid it or compare against alternatives such as list-agents, but the single-record scope makes usage apparent.

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?

With no annotations, the description carries the burden and does well: it discloses server-side gating on the internal `chatwoot_hmac` identifier, that the SDK never holds or forwards the HMAC, and that the response carries no credential-shaped fields. It stops short of stating failure behavior when the gate rejects the call or whether results are cached/per-user scoped.

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 sentences, zero padding, with the purpose and return shape front-loaded before the security model and usage guidance. Every sentence adds 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?

No output schema exists, yet the description supplies the exact return keys and the security/auth model, which is everything an agent needs to call a zero-argument read tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Zero parameters, so there is no schema semantics to explain; baseline 4 applies. Nothing in the description is needed or missing on the parameter side.

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?

States a specific verb and resource ("Read the support-channel unread state for the current user") and immediately names the exact return shape `{contact_found, has_unread}`, making it unmistakable versus siblings like get-balance or chat-exists.

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?

Gives a concrete use case ("Use to surface 'the user has an unread support reply' without pulling the full Chatwoot widget") and implicitly contrasts with heavier alternatives, but does not name a specific sibling or state when not to use it.

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, the description carries the burden and does disclose real behavior: the exact return fields, the 0..100 range of percent_left, and the non-obvious normalization rule that expired/null expires_at becomes percent_left=100 with null timestamps. It omits that the call is read-only and any auth requirements, but the edge-case contract is genuinely valuable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the purpose then the return contract, then the plan field. Every sentence adds information an agent would otherwise have to guess.

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?

There is no output schema and no annotations, so the description must explain the return shape — and it does, covering both window objects and the subscription plan. It is nearly complete for a zero-param getter; only the safety profile (read-only, no side effects) is left unstated.

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 takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter guidance is 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?

The description opens with a specific verb+resource ('Return the current LLM usage limits') and scopes it to 6h and 7d windows, which distinguishes it from generic siblings like get-balance and get-tokens-history. It doesn't explicitly name those siblings, so it stops short of a 5.

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?

There is no statement of when to call this versus get-balance, get-tokens-history, or get-llm-reset-price, all of which sound adjacent. The agent must infer from the resource name alone that this reports quota consumption rather than remaining balance or pricing.

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 and does well: it declares read-only semantics, discloses that price_tokens is null when a window isn't resettable, and lists the per-window fields returned. It omits auth requirements, rate limits, and whether the quote is stable over time.

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 sentences, front-loaded with purpose, then implementation anchor, then return shape, then the read-only caveat. Every sentence carries distinct information with no 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?

No output schema exists, and the description compensates by enumerating the response fields (available, price_tokens, used_percent, reason) including their null semantics. Combined with the read-only caveat, an agent has everything needed to call and interpret 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 tool takes zero parameters, so the baseline is 4. The description correctly adds no parameter detail and instead spends its words on the return shape, which is the right allocation.

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?

States a specific verb and resource ('Quote the cost of resetting the LLM usage windows') and pins it to an exact backend route (GET /api/v1/llm/limits/reset/price), which cleanly separates it from get-llm-limits and other billing siblings like get-balance or list-token-pricing.

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 opening sentence establishes the use case (pricing a reset), and the closing 'Read-only — it does not purchase the reset' rules out confusion with an actual reset action. It never names a sibling alternative explicitly (e.g. get-llm-limits for window status), so it stops short of a full when/when-not routing statement.

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 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?

With no annotations, the description carries the burden and does useful work: it identifies a GET endpoint, describes polling, enumerates `status` values, and names `completed_prompt` as the output on success. It stops short of documenting auth, rate limits, or failed-task error details.

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 and compact, covering polling, status values, and the success field in four sentences. The wrapper function and endpoint details are somewhat implementation-oriented but not disruptive.

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 polling tool with no output schema, the description covers the essential call behavior: poll the task, watch `status`, and read `completed_prompt` on completion. It leaves some response and error details unspecified, but the core operational context is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the only parameter is already documented as the task id from `start-prompt-enhancement`. The description adds no further meaning about the parameter beyond what the schema provides, so 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?

The description uses a specific verb and resource: 'Poll a prompt-enhancement task.' It also distinguishes the operation from the sibling `start-prompt-enhancement` by implying retrieval of an existing task rather than creation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The word 'Poll' clearly signals the intended repeated-call usage, and the schema links `task_id` to `start-prompt-enhancement`. It lacks explicit when-not guidance or mention of alternatives such as `wait-for-response`, but the usage context is still clear.

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

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

With no annotations, the description carries the burden and does disclose that this is a GET read against `/api/v1/prompt-enhancer/cost` and that unenhanceable models yield 422/model_not_enhanceable. It omits auth requirements, rate limits, and whether the underlying getCost call has side effects, but the key failure mode is surfaced.

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 sentences, front-loaded with the purpose and then the mechanics and error case. The SDK/endpoint internals are borderline noise for an agent but they are compact and do not obscure the primary statement.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter tool with no output schema and no annotations, the description covers purpose and the main error, but leaves the return shape ambiguous — 'token cost' could be a scalar or an object with input/output token counts. That ambiguity matters precisely because there is no output schema to fall back on.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single model_type parameter is already documented as required. The description's endpoint example shows model_type as a query parameter but adds no constraints, valid values, or format details 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?

States a specific verb and resource: 'Return the token cost of enhancing a prompt for a given model', which is clearly distinct from start-prompt-enhancement and get-prompt-enhancement-task. It does not explicitly name those siblings, so differentiation is by implication rather than direct routing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied — call this before enhancing to learn the cost — but the description never states when to use this versus start-prompt-enhancement or what the caller should do with the returned cost. The 422/model_not_enhanceable case is documented, which is a useful hint but not full usage 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 at all, the description carries the full burden. It does disclose real behavior — cursor pagination, terminal null cursor, and the underlying endpoint wrapping `syntx.user.getTokensHistory` — but says nothing about auth requirements, rate limits, ordering, or what a history record contains.

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 short sentences, front-loaded with the resource and followed by the pagination rule. The wrapper name and raw endpoint path are marginal value for an agent choosing a tool, but they are cheap and aid error diagnosis.

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?

No output schema exists, so the description should sketch the return shape, yet it only implies a `next_cursor` field and never says what each history entry contains (model, tokens, cost, timestamp) or the sort order. For a history/listing tool this leaves the agent guessing about results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

At 50% schema coverage the description has to compensate, and it does for the key parameter: it reveals that the cursor value comes from the previous response's `next_cursor`, a link the input schema never states (it only says 'Cursor from the previous page'). `page_size` is left entirely to schema constraints, which are adequate.

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?

"Cursor-paginated token-spend history" names a specific resource and its retrieval mechanism, which an agent can distinguish from get-balance (current balance) and list-token-pricing (rates) without opening the schema. It stops short of explicitly contrasting with those siblings, but the resource is 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 explains how to page (pass `next_cursor` while non-null) but never states when to reach for this tool versus get-balance or list-token-pricing, nor any exclusions or prerequisites. Usage is implied by the resource name rather than specified.

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 and does disclose the read-only nature via the GET endpoint, the SDK method it mirrors, and the return shape ('returns the file array'). It omits auth requirements, permission scope, pagination, and whether the array is bounded, which are the remaining behavioral gaps.

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 short sentences, front-loaded with the purpose, followed by a useful mirror reference and the endpoint/return. No filler, nothing redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter read tool with no output schema, the description covers purpose, retrieval target, and return type, which is close to what an agent needs. Auth/permission context and result-size expectations are the only missing pieces.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is a single parameter at 100% schema description coverage, and the schema already explains that agent_id is the UUID returned by list-agents. The description adds nothing about the parameter, so the baseline of 3 applies.

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

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

States a specific verb and resource: 'List the files attached to an AI agent', which is clearly distinct from mutation siblings like add-agent-files and delete-agent-files. It does not explicitly differentiate itself from the similarly named list-generated-files or list-uploaded-files, so an agent must infer the distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied by the name and the resource target; there is no explicit 'use this when' or exclusion of alternatives. The schema's reference to list-agents gives an implicit prerequisite chain (resolve agent_id first), which is the only real guidance present.

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 and largely meets it: it discloses the exact return envelope (agents array, agent_limit, agent_count, can_create_more) and, crucially, that the list mixes the caller's own agents with shared platform agents marked `editable: false` — a non-obvious behavior an agent would otherwise get wrong. It stops short of stating whether the result is paginated or how visibility permissions are determined.

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?

Front-loaded with purpose and scope before moving to the endpoint and return shape, so an agent gets the essential facts in the first clause. The return-shape enumeration is dense but earns its place given the absence of an output schema; the `Mirrors syntx.agents.list` fragment is the only lower-value content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read tool with no annotations and no output schema, the description supplies everything an agent needs: what it enumerates, the exact response fields, and the semantic caveat about mixed ownership. Little is left to guess before invoking 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 tool takes zero parameters and the schema is a closed empty object, so there is nothing for the description to disambiguate. Baseline 4 applies; the description correctly does not invent parameter guidance.

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?

States a specific verb and resource ('List the AI agents') and pins the scope to 'visible to the authenticated account', which is the key discriminator against get-agent and the create/update/delete-agent siblings. The immediate identification of the backing endpoint (`GET /api/v1/agents/list`) removes any ambiguity about what is being enumerated.

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 scoping phrase 'visible to the authenticated account' implies the right context for use, but there is no explicit statement of when to prefer this over get-agent for a single record, or any dependency/prerequisite call. Usage is inferable from the name and scope rather than 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?

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, the description carries the full burden and does well: it discloses the exact return projection ({provider, email, username, linked_at}) and the sanitisation/filtering behavior at the SDK boundary, which is meaningful context an agent could not infer. It omits read-only confirmation and any auth/rate-limit notes, keeping it 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?

Front-loaded with purpose and return shape in the first two sentences; the third sentence adds useful behavioral context but drifts into meta-commentary about the SDK's future-proofing ('a future server-side change can never leak through a tool surface'), which is less relevant to tool selection.

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?

There is no output schema and no annotations, yet the description fully compensates: it names the returned fields, explains the sanitisation behavior, and contrasts with the sibling tool. An agent has everything needed to call this zero-arg tool and interpret its result.

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 takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The description correctly does not invent parameters or imply optional filters.

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?

States a specific verb and resource ('List the external identities linked to the current syntx.ai account') and immediately names the sibling it differs from: the per-provider breakdown that 'get-profile' does not carry. An agent can distinguish it from get-profile and whoami without opening any schema.

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 'the per-provider breakdown that get-profile does not carry' effectively tells the agent when to pick this tool over get-profile. However, it never states an explicit when-not or what get-profile should be used for instead, so the routing is clear but not fully spelled out.

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 full burden, and it does disclose the pagination mechanism and the exact return shape (`{items, total, page, page_size}`), which is genuinely useful. It omits auth requirements, ordering of results, and behavior at the end of the feed, so the safety/behavioral profile is only partly 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?

Three short sentences, front-loaded with what the feed is. The SDK wrapper reference (`syntx.events.list`) is marginally useful and the raw endpoint string partly duplicates it, but nothing is bloated.

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?

There is no output schema, so spelling out the return shape is a real contribution, and pagination is at least mentioned. However, with zero annotation coverage and zero schema description coverage, a reader still lacks ordering, filtering limits, and page_size semantics needed to page through results 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 0%, so the description must compensate for both parameters. It references `page=N` and shows `page_size` in the return payload, but never explains what page_size does, its default of 20, or the 100 cap — the agent gets no semantic guidance beyond the schema's bare types.

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?

"Event feed (promotions, milestones, etc.)" names the resource and gives concrete examples of what an event is, which is more than a restatement of the name. The list verb is implied by the tool name rather than stated, and no sibling is named, so it stops short of a 5.

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?

There is no statement of when to call this versus alternatives, no prerequisites, and no exclusions. An agent must infer from the name alone that this is the tool for browsing the event feed.

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 behavioral burden. It usefully discloses the backing endpoint as `GET /api/v1/files/generated`, implying a read operation, but it does not describe permissions, pagination behavior, ordering, or 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?

The description is front-loaded, compact, and wastes no sentences. The core purpose appears first, followed by the sibling distinction and implementation details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool this is minimally adequate, but there is no output schema and no annotations, so the description should do more to explain return behavior or pagination. Parameter documentation is also incomplete for `page` and `page_size`.

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 low at 33%, and the description only hints at the media-type filter by mentioning image/video/audio. It does not explain `page` or `page_size` semantics beyond what the schema's defaults and bounds show.

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

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

The description states a specific verb and resource: list files this account has generated, with supported media types. It explicitly distinguishes this from `list-uploaded-files`, so an agent can route correctly without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly positions the tool against `list-uploaded-files`, which is the key nearby alternative. However, it does not spell out when-not conditions or other usage boundaries, such as whether generation jobs must be complete before files appear.

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 and does useful work: it discloses the default active_only=true, explains that the two catalogs are partially out of sync, and notes that text-catalog rows carry an additional llm object. It does not discuss permissions or rate limits, but those are not central for a listing 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 front-loaded with the core purpose and then moves directly into filter semantics. It is dense but largely earns its length; a few details, such as repeating the exact-match example, could be tightened, but there is no major waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, but the description explains the important return distinction: value is always the model identifier, and text-catalog rows additionally carry an llm object with context window, capabilities, and subscription gate. For a zero-required-parameter listing tool, this is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so the baseline is 3. The description still adds meaning beyond the schema: it says filters are combined with AND, clarifies that ai_name is exact match, explains the practical difference between 'ai', 'llm', and 'both', and notes that value is always the model identifier.

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

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

The description uses a specific verb and resource: 'List AI models with upload constraints, supported media types, and features.' It is clear what the tool returns, but it does not explicitly distinguish this tool from nearby siblings like list-ai-services or get-llm-limits.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explains that filters are optional and combined with AND, and gives a concrete rule for catalog selection: use source: 'both' to see every model because the catalogs are not in sync. However, it gives no explicit guidance on when to choose this tool over sibling tools that also expose model or service information.

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 supplied, so the description carries the full burden. It does add real context: the exact endpoint (GET implies a read-only lookup), the SDK method it mirrors, and the paginated {folders, pagination} envelope rather than a bare array. It stops short of stating pagination controls, result limits, or auth requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences, each earning its place: identity, SDK equivalence, endpoint, and return shape. The most important fact (what it returns) is stated up front with 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?

For a one-parameter, read-only listing tool with no output schema, the description supplies the critical missing piece — the response envelope shape and pagination presence — plus the underlying endpoint. Only the absence of any pagination/limit behavior detail keeps it from being 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 description coverage is 100% — the single 'scope' parameter is fully documented with its enum and default. The description adds nothing about scope semantics beyond what the schema already says, 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?

States a specific verb and resource ("List projects") and resolves the ambiguous naming by equating projects with folders, which is the main disambiguation an agent needs. It does not, however, distinguish this from the related create-project/update-project/reorder-project siblings beyond the implicit 'list' verb.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the name and the scope parameter — clearly the tool to enumerate projects before adding/removing chats. But there is no explicit when-to-use/when-not guidance and no pointer to an alternative (e.g., when to prefer list-generated-files or list-uploaded-files for other file views).

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 behavioral disclosure burden. It usefully states that the call hits a GET endpoint, indicating a read operation, and that the server returns 422 for invalid period values, which is concrete error behavior. It does not cover auth, rate limits, or return shape, but for a simple list endpoint the disclosed behavior is solid.

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-loads the tool's purpose. The sentence about wrapping the SDK method is less useful to an agent than the endpoint and validation behavior, but overall there is little wasted 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 low-complexity tool with one optional enum parameter and no output schema, the description covers purpose, endpoint, default behavior, and validation failure. It does not describe the returned tariff structure or auth requirements, but the essential calling information is present.

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 already 100%, with the period enum and default fully documented. The description adds value by explaining why the enum is pinned and that invalid values cause a server 422, which goes beyond the schema's basic enumeration.

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

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

The description states a specific verb and resource: "List plan tariffs," and clarifies it is "the actual price list." This distinguishes it from pricing-related siblings such as list-token-pricing and get-llm-limits, which cover different pricing concepts.

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 name and description imply usage for listing plan tariffs, but there is no explicit when-to-use or when-not-to-use guidance. It does not route the agent between this tool and siblings like list-token-pricing or get-llm-limits, leaving alternatives to inference.

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 and does well: the GET endpoint signals a safe read, and it discloses the exact return shape {items: [{id, cost}]}. It stops short of mentioning auth requirements or whether the table is cached/stale, so it earns a 4 rather than 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?

Three short sentences, front-loaded with the purpose, with no filler. The 'Wraps `syntx.tokensPricing.list`' clause is internal implementation detail that adds little for an agent, a minor deduction.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-param read tool with no output schema, the description supplies endpoint, return structure, and resource scope, which is nearly everything needed to call it correctly. Only the sibling-routing guidance is missing.

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 takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; the return-shape hint adds a little value without needing parameter detail.

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

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

The description names a specific resource ('per-model token cost table') and the backing endpoint, so the agent knows exactly what data comes back. It doesn't explicitly contrast with siblings like list-models or get-tokens-history, but the resource is distinct enough to be told apart.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: an agent can infer this is the tool for pricing lookups, but there is no explicit when-to-use statement, no mention of alternatives such as get-tokens-history or list-tariffs, and no prerequisites noted.

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 reasonably well: it discloses the backing wrapper and the GET endpoint, which implies a read-only, side-effect-free operation, and it describes the returned structure. It omits auth/rate-limit considerations and error behavior, which keeps it from 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?

Front-loads the purpose in the first sentence, then layers backend and return details. The wrapper name and the GET path are near-duplicates of the same fact, a small redundancy that keeps it from a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read tool with no output schema, the description supplies exactly what is otherwise missing: the return shape and a warning that the display label is `title`, not the deprecated `name`. An agent has everything needed to call it and read the result.

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?

Zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-param tool applies. The response-shape note is genuinely additive but belongs to return values rather than 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?

States a specific verb and resource ('List top-level feed categories used by the home feed'), which clearly separates it from list-trend-tags and other list-* siblings by naming the resource and scope. It stops short of explicitly pointing at the sibling alternative, so it is clear but not fully differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied via the phrase 'used by the home feed', giving context but not a when-to-use rule, prerequisites, or exclusions. Nothing tells the agent when to prefer this over list-trend-tags.

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

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

With no annotations provided, the description carries the disclosure burden and does so reasonably well: it names the wrapper, endpoint, return shape, and the important caveat that the live response is often empty. It does not mention authentication or rate limits, but for a simple read-only list this is largely sufficient.

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-loads the purpose before implementation details. The wrapper and endpoint references are somewhat implementation-level, but they do not crowd out the useful 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 zero-parameter read tool with no output schema, the description supplies both the return shape and the key real-world caveat that responses are often empty. Nothing essential for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so there is no parameter semantics burden. The schema is empty and fully covered, and the description introduces no misleading parameter references.

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

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

The description states a specific verb and resource ('List free-form tags') and scopes it to the home feed. It clearly distinguishes tags from broader trend concepts, though it does not explicitly name the sibling list-trend-categories as an alternative.

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?

There is no explicit guidance on when to use this tool versus list-trend-categories or other trend-related siblings. The note that the live response is often empty is useful behavioral context but does not help an agent choose between tools.

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

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

With no annotations provided, the description 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.