Write trading strategies in JavaScript, describe them to an LLM or send TradingView alerts. Sigrex runs them 24/7, reacts to live data and executes every signal on your exchange, DEX and prediction-market accounts.
Glama couldn't complete the latest health check. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 195 tools
Most tools map to distinct REST endpoints with HTTP-verb prefixes, but with 195 near-duplicate variants (e.g. delete_strategy_reaction_code_id vs delete_strategy_reaction_code_id_store, folder vs id, cex vs dex vs prediction) an agent faces real misselection risk. The four documentation tools (askQuestion, searchDocumentation, getPage) are clearly differentiated by their descriptions, but the API surface has many subtle boundaries.
The dominant pattern is a consistent snake_case {http_verb}_{resource}_{params} convention derived from the API paths, which is highly predictable. The main deviations are the four camelCase documentation tools (askQuestion, getPage, searchDocumentation, sendFeedback), which are minor outliers within an otherwise uniform scheme.
195 tools is an extreme mismatch for an MCP server, far beyond the 50-tool threshold. It appears to be an unfiltered mirror of the entire REST API, which will overwhelm an agent's context and tool-selection ability.
The surface covers full lifecycle operations (create/get/update/delete/duplicate/list) for bots, strategies, reactions, webhooks, logs, API keys, exchanges, plus folder and sharing management and documentation tools. Coverage is very broad with only minor gaps such as read-only handling of account/friend data and no explicit update/delete for friends.
Ask a natural-language question about Sigrex Documentation and get a synthesized answer, with links to the source pages. Prefer this over searchDocumentation when you want a direct answer to a question rather than a list of matching pages; use searchDocumentation/getPage when you need to browse or read full pages yourself.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | No | The broader end goal you are ultimately trying to accomplish (as/on behalf of the user). Used to tailor the answer to be most useful for your goal. Optional. | |
| question | Yes | The natural-language question to answer about Sigrex Documentation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=false, and destructiveHint=false, so the safety profile is covered. The description adds that the result is a synthesized answer with links to source pages, which is useful output context, but it does not explain the non-idempotent behavior (why repeated identical questions may yield different answers) or any latency/rate behavior for an open-world query.
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, zero waste, front-loaded with the capability and then the routing rule. Every clause earns its place by either describing the tool or steering the agent to the right sibling.
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 covers the essential return shape (synthesized answer plus source-page links), and annotations cover safety. What is missing is any note on answer reliability, citation-only queries, or behavior when documentation has no answer, which a Q&A tool could usefully state.
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 both parameters (question, goal) are already documented in the schema, including the goal's purpose of tailoring the answer. The description adds no syntax, formatting, or example guidance 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?
States a specific verb (ask a natural-language question), a specific resource (Sigrex Documentation), and the output form (synthesized answer with source links). It names its siblings searchDocumentation and getPage and distinguishes itself from them, so an agent can route without opening schemas.
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 gives the when: 'Prefer this over searchDocumentation when you want a direct answer to a question rather than a list of matching pages.' It also gives the inverse condition: use searchDocumentation/getPage 'when you need to browse or read full pages yourself.' Both alternatives and their selecting conditions are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an exchange API key. DELETE /api/v2/api/exchange/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the irreversibility signal is carried by structured data. The description adds only the REST endpoint path; it does not state whether the key is soft-deleted, whether it invalidates running bots/signals, or what permissions are required. Useful context, but thin beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short clauses, action front-loaded, zero filler. It is arguably terse to the point of under-specification, but nothing is wasted.
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 output schema, the annotations cover the safety profile and the description covers the action. It stops short of warning about irreversible consequences or downstream effects on bots using the key, which would complete the 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 0% for the single 'id' parameter, so the schema gives no meaning for it. The description implies the id is an exchange API key identifier via the URL template, which helps slightly, but does not clarify format or source of the id. Adequate but not compensating for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Delete an exchange API key') and appends the exact HTTP route, so the agent knows precisely what it does. However, it does not distinguish itself from the many parallel delete_* siblings (e.g. delete_api_llm_id, delete_api_prediction_id), leaving sibling routing to the name alone.
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 when-to-use guidance, no mention of alternatives, and no note about prerequisites such as first disabling the key. The agent gets no help deciding between this and get_api_exchange or put_api_exchange_id_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an LLM API key. DELETE /api/v2/api/llm/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the destructive nature is fully covered structurally. The description merely repeats 'delete' and adds an endpoint path; it says nothing about irreversibility, dependent resources, or whether the key must first be unused, so it adds no behavioral value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two terse statements with the purpose front-loaded and no filler. The endpoint path is marginal value but not wasteful.
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 single-argument delete with no output schema and safety covered by annotations, this is minimally adequate. However, it omits practical caveats such as irreversibility or dependencies that would matter for a destructive action, leaving a modest 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?
The single 'id' parameter has 0% schema description coverage, so the description must carry the meaning, but it only echoes '{id}' in the URL template. It does not clarify what the id identifies (which LLM key, its source, or format) beyond what is trivially inferable.
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 ('Delete an LLM API key'), which is enough to distinguish it from sibling deletes like delete_api_exchange_id and delete_api_prediction_id by resource type. It is clear but does not explicitly call out those siblings or the scope of what an 'LLM API key' covers.
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 when-to-use guidance, no mention of alternatives, and no conditions or prerequisites. The only content beyond the name is a raw HTTP route, which does not help an agent decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete prediction API key. DELETE /api/v2/api/prediction/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=false, so the safety profile is covered. The description adds the raw HTTP endpoint, which hints at a REST delete semantics, but it says nothing about permanence, cascade effects, or whether the key must be inactive before deletion.
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 terse sentences, front-loaded with the action and resource, with no filler. The endpoint string is somewhat redundant given the tool name but is cheap and adds routing context.
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 delete with no output schema and annotations covering safety, the description is minimally adequate. It omits any return/response semantics, error conditions, or authorization requirements, which leaves gaps for a mutation tool.
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 0% and there is one parameter, 'id'. The description embeds {id} in the path template, which clarifies that the parameter is a path identifier for the prediction API key, adding slight meaning beyond the bare string schema. It does not state the id format or where to obtain it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Delete) and resource (prediction API key), which is more precise than the bare tool name and distinguishes it from the many sibling delete_* tools operating on exchanges, LLMs, webhooks, etc. It does not explicitly name a sibling alternative, so it falls 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 guidance on when to use this tool versus alternatives, no prerequisites, and no warning about irreversibility or required ownership of the key. The only implicit cue is the verb 'Delete'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete CEX signal bot folder. DELETE /api/v2/bot/signal/cex/folder/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Folder ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the destructive nature is covered structurally. The description adds nothing beyond the raw HTTP endpoint: it does not say whether the folder's contents are also deleted, whether the action is reversible, or what authorization is required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short fragments, purpose first, no padding. The REST endpoint line is low-value for an agent but is a compact convention rather than bloat.
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 an irreversible, destructive folder deletion with no output schema and no annotations explaining scope, the description should address cascade behavior and failure modes. Neither is present, leaving a meaningful gap for a high-consequence operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% ('Folder ID'), so the single parameter is fully documented in the schema. The description only restates it as a path segment ({id}), adding no format, source, or validation detail. Baseline 3 applies when the schema does the work.
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 (Delete) and a specific resource (CEX signal bot folder), which implicitly separates it from the dex/prediction folder-deletion siblings. It does not name those siblings explicitly or describe what a folder contains, so it falls 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?
No when-to-use guidance, no prerequisites (e.g., whether the folder must be empty first), and no reference to alternative tools like put_bot_signal_cex_folder_id for renaming. The agent must infer usage purely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete CEX signal bot. DELETE /api/v2/bot/signal/cex/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds no behavioral context beyond the annotations — no cascade effects on folders, no confirmation semantics, no error behavior for a missing ID — and the raw HTTP verb/path restates what the annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the intent and no filler. The trailing 'DELETE /api/v2/bot/signal/cex/{id}' endpoint line is largely redundant with the name and annotations, which is the only waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive single-resource delete with no output schema, the description should say what is removed and whether it can be undone. It offers none of that, leaving the agent with only the annotations' destructive flag.
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% for the single required 'id' parameter. The '{id}' path placeholder only repeats the schema shape and adds no meaning about what the ID identifies, its format, or where the agent obtains it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Delete CEX signal bot') and the CEX qualifier cleanly separates it from siblings like delete_bot_signal_dex_id and delete_bot_signal_prediction_id. An agent can pick the right sibling from the name plus this sentence alone.
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 when-to-use guidance, no mention of alternatives, no prerequisites (e.g. whether the bot must be stopped first), and no note that the action is irreversible. The agent gets no routing or precondition information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete DEX signal bot folder. DELETE /api/v2/bot/signal/dex/folder/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Folder ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the destructive nature is covered by structured data. The description adds nothing beyond a restatement of the action and the REST path; it does not say whether nested signals/folders are removed, whether deletion is reversible, or what auth is required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single terse sentence with the action front-loaded, followed by the endpoint path. No padding, though the raw REST path is largely redundant to an agent that already has the tool name.
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 delete with destructive annotations and no output schema, the minimum needed to invoke correctly is present. However, nothing addresses cascading effects or irreversible loss, which is the main thing an agent would want to know before calling a delete.
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?
Only one parameter (id) and schema description coverage is 100% ('Folder ID'), so the schema carries the semantics. The description adds no format, scope, or sourcing guidance for the ID, making the baseline 3 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 (Delete) and resource (DEX signal bot folder), and the 'DEX' qualifier implicitly separates it from the CEX and prediction folder siblings. It is clear what the tool does, though it never explicitly contrasts itself with those siblings.
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 indication of when to use this versus alternatives (e.g., moving to the folder's PUT sibling, or which folder/ID to supply). Nothing is said about preconditions or what happens afterwards.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete DEX signal bot. DELETE /api/v2/bot/signal/dex/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only the HTTP verb/path, which merely restates the destructive semantics rather than disclosing consequences such as what is removed, whether child folders or dependent webhooks are affected, or whether the action is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short fragments, action and endpoint, front-loaded with zero filler. It is efficient, though the extreme brevity means little is actually communicated.
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 destructive single-parameter tool with no output schema, the description omits the practical context an agent needs: cascade effects on folders/related webhooks, irreversibility, and any required confirmation. Annotations cover only the generic destructive flag, leaving behavior under-described.
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% for the single required 'id' parameter. The path template '/{id}' hints that the parameter is a path identifier, but the description gives no detail on its format, source, or which bot's ID is expected, so it adds only marginal meaning.
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 ('Delete') and resource ('DEX signal bot'), which an agent can differentiate from sibling deletes such as delete_bot_signal_cex_id and delete_bot_signal_prediction_id without opening any schema. The REST path reinforces the exact resource being acted on.
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 when-to-use guidance, no prerequisites, and no mention of alternatives or related lifecycle operations (e.g., disabling via put_bot_signal_dex_id_status instead of deleting). The agent must infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete prediction signal bot folder. DELETE /api/v2/bot/signal/prediction/folder/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Folder ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only the HTTP method/path, which confirms the delete semantics but says nothing about what is destroyed (e.g., whether the folder's contents are cascaded) or whether the operation is recoverable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the action front-loaded and no wasted prose. The endpoint path is arguably redundant given the annotations, but it does not bloat the description.
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 destructive single-parameter delete with full annotation coverage and no output schema, the definition is minimally adequate. It omits the one behaviorally relevant fact for a folder delete — whether child items are removed with it — which an agent would want before invoking a destructive 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?
There is a single parameter with 100% schema description coverage ('Folder ID'), so the schema does the heavy lifting. The description adds no syntax, format, or ID-source detail beyond the {id} placeholder, making the baseline 3 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 ('Delete') and resource ('prediction signal bot folder'), which is enough for an agent to identify the operation. However, it does not explicitly differentiate itself from the many near-identical siblings such as delete_bot_signal_cex_folder_id and delete_bot_signal_dex_folder_id; the distinction rests entirely on the resource noun in the name.
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 no when-to-use, when-not-to-use, prerequisites, or alternatives. The trailing 'DELETE /api/v2/bot/signal/prediction/folder/{id}' is an endpoint reference, not usage guidance, so an agent gets no help choosing this tool over its folder-delete siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete prediction signal bot. DELETE /api/v2/bot/signal/prediction/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds only the raw REST path and nothing about cascading effects, whether child signals are removed, irreversibility, or auth requirements — so it contributes essentially no behavioral context beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short fragments, front-loaded with the action and resource, with no padding. It is efficient, though the bare endpoint string is of limited use to an agent selecting a tool.
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-id destructive call with annotations covering safety and no output schema, the minimum viable information is present. Still missing are any confirmation/irreversibility note and any hint of what the id refers to or how to obtain 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?
One parameter with 0% schema description coverage. The description's path template 'DELETE /api/v2/bot/signal/prediction/{id}' implies the id identifies a prediction signal bot, which adds a little meaning, but it does not specify format or where the id comes from (e.g. get_bot_signal_prediction_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 ('Delete prediction signal bot'), so an agent knows this is a destructive operation on a prediction-signal bot. However, it offers no differentiation from near-identical siblings such as delete_bot_signal_prediction_folder_id or delete_api_prediction_id, so the agent must infer scope from the name alone.
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 when-to-use or when-not-to-use guidance, no mention of prerequisites or alternatives. In a family of ~20 delete_* tools, the absence of any routing hint (e.g. deleting a bot vs. its folder) is a real gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete code strategy folder. DELETE /api/v2/strategy/code/folder/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Folder ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds only the HTTP verb and path template, which restates the tool name; it does not disclose whether the delete cascades to contained strategies, is reversible, or requires the folder to be empty.
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 terse fragments, front-loaded with the action and resource, with no padding. Nothing is wasted, though the endpoint path is arguably redundant given the tool name.
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 destructive delete with no output schema and full annotation coverage, the definition is minimally viable. The key omission is consequence information — cascade behavior and irreversibility — which matters most for a delete-folder operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single required 'id' parameter with 100% schema description coverage, so the schema carries the semantics. The description's '{id}' path placeholder adds no meaning beyond what the schema already says; 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: 'Delete code strategy folder'. This distinguishes it from the closely named siblings delete_strategy_code_id (deletes a code item, not a folder) and delete_strategy_reaction_code_folder_id (reaction code folder), but the description never explicitly names those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no prerequisites, no warning about what happens to the strategies contained in the folder, and no pointer to alternatives such as moving contents first. The agent must infer everything from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete code strategy. DELETE /api/v2/strategy/code/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered structurally. The description adds nothing beyond that: it does not say whether deletion is permanent, whether related entities (stores, reactions, sessions) are affected, or what authorization is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short fragments with no filler and the action is front-loaded. It is efficient but so terse that it borders on under-specification rather than tight communication.
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 destructive, irreversible mutation with no output schema, the description should explain consequences and confirm scope (e.g., that this affects only the strategy code and not its folder/stores). With no annotations beyond the hints and no parameter documentation, an agent lacks what it needs to call this safely.
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 one required parameter (id) with 0% schema description coverage, so the schema does not explain what the id identifies or its format. The description never mentions the parameter, leaving the agent to infer that it is the code-strategy identifier from the tool name alone.
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 ("Delete code strategy") and the HTTP route confirms the target. It does not, however, distinguish this from close siblings like delete_strategy_code_folder_id or delete_strategy_code_id_store, so an agent must infer the difference from the name alone.
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 on when to use this versus the folder / store variants, no prerequisites, and no mention of irreversibility or required permissions. The HTTP line restates the operation rather than advising usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete code strategy storage. DELETE /api/v2/strategy/code/{id}/store
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only the endpoint string and nothing about what data is destroyed, whether the deletion is reversible, or what permissions/ownership are required – a meaningful gap for a destructive-store 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?
Two short fragments, action front-loaded, zero filler. It is terse to the point of being under-specified, but nothing is wasted and structure is clear.
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 destructive mutation with no output schema, the description should at least say what 'storage' contains and how it relates to delete_strategy_code_id. As written, an agent cannot confidently distinguish this from the sibling delete tools or reason about consequences.
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% for the single required 'id' parameter. The path template '/api/v2/strategy/code/{id}/store' does loosely indicate that 'id' is the parent strategy code identifier, which is some value beyond the bare schema, but the description gives no format, ownership, or lookup guidance for obtaining it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a verb ('Delete') and a resource ('code strategy storage') plus the exact HTTP route, so the action is identifiable. However, 'storage' is never defined – it is unclear whether this removes compiled artifacts, cached code, or a saved snapshot – and the near-identical sibling delete_strategy_code_id (which deletes the strategy code itself) is not contrasted, leaving the agent to guess between them.
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 this tool should be used versus delete_strategy_code_id or delete_strategy_reaction_code_id_store. No prerequisites, no exclusions, no ordering guidance (e.g. whether storage must be cleared before deleting the strategy).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete LLM session folder. DELETE /api/v2/strategy/llm-session/folder/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Folder ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=false, so the safety profile is covered by structured data. The description adds only the HTTP endpoint, not the behavioral facts that matter for a folder delete: whether nested sessions are cascaded or orphaned, whether auth/ownership is required, or whether the call is idempotent.
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 tight sentences with the purpose front-loaded and no filler. The endpoint restatement is marginally useful metadata rather than wasted space.
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 delete with no output schema, the definition is minimally viable given the annotations carry the safety signal. It still omits the consequence of the deletion (what happens to contained LLM sessions) and failure modes such as a missing or non-empty folder.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single 'id' parameter is already documented as 'Folder ID' in the schema. The description adds nothing beyond that, 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 (delete LLM session folder) and the backing endpoint DELETE /api/v2/strategy/llm-session/folder/{id}. It is distinguishable from the sibling delete_strategy_llm_session_id by the 'folder' resource, but that distinction is carried only by the name, not by any explicit contrast in the text.
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 guidance on when to use this versus put_strategy_llm_session_folder_id or get_strategy_llm_session_folder_id, and no prerequisites such as whether the folder must be empty before deletion. The agent must infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete LLM session. DELETE /api/v2/strategy/llm-session/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=true and openWorldHint=false, so the safety profile is covered by structured data. The description adds nothing beyond that — it does not say whether deletion is permanent, what happens to dependent reactions/sessions, or whether ownership/auth is required. For a destructive tool this is a missed opportunity, though not a contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short fragments with no wasted words and the action front-loaded, which is good. However brevity here comes from omission rather than discipline — the second sentence is purely a route path that adds no decision-relevant 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 destructive, state-mutating endpoint with no output schema and an undocumented id parameter, the description supplies no side-effect, irreversibility, or dependency context. The annotations carry safety hints, but the description leaves too much for the agent to infer before calling.
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 one required parameter ('id') with 0% schema description coverage, and the description only echoes the '{id}' placeholder from the route template. It never explains that the id identifies an LLM session (as opposed to a folder or reaction session), so it fails to compensate for the schema 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 states a specific verb plus resource ('Delete LLM session'), which is more informative than the bare tool name and lets an agent distinguish it from the get_/put_/post_ session siblings. It does not explicitly distinguish itself from delete_strategy_llm_session_folder_id, but the session-vs-folder noun difference is legible from the name.
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 when-to-use guidance, no prerequisites, no mention of the folder-deletion alternative or of the get/put session siblings. The agent gets only the operation and the REST path, leaving selection entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete code reaction folder. DELETE /api/v2/strategy/reaction/code/folder/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Folder ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered structurally. The description adds nothing beyond restating 'delete' and the HTTP path; it does not disclose whether deletion is recursive, what happens to contained reactions/codes, or whether it is recoverable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action. The second sentence largely restates the endpoint already encoded in the name, which is mild redundancy rather than bloat.
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 delete whose annotations already declare destructiveness, the definition is minimally viable. The notable gap is cascade behavior: an agent cannot tell whether deleting the folder also removes its child reaction codes, which matters for a destructive folder operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single 'id' param is documented as 'Folder ID' in the schema. The description only echoes the path template '{id}', adding no format or sourcing detail, 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 ('Delete code reaction folder'), and the word 'folder' distinguishes it from the sibling delete_strategy_reaction_code_id which targets the reaction code itself. It stops short of explicitly naming that alternative, so differentiation is inferable 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?
No when-to-use, when-not-to-use, or alternative routing is given. The agent gets no guidance that this deletes a folder versus its contents, nor any pointer to the reaction-code-level delete sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete code reaction. DELETE /api/v2/strategy/reaction/code/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the destructive nature is known from structured data. The description adds nothing beyond that — no permanence, no cascade behavior for referencing data, no confirmation or permission requirements — so it repeats what the name and annotations already convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with the verb first and the endpoint second; nothing is padded. The endpoint is somewhat redundant with the tool name but still compact.
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 delete whose destructive nature is already declared by annotations, this is minimally adequate. It leaves out what exactly is removed, whether anything referencing the reaction is affected, and no output information exists, so it stops at the minimum viable level.
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% for the single 'id' parameter, and the description only mirrors the path template ({id}) without explaining which identifier is expected or its format. For a 0%-coverage parameter, more compensation was 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?
States a specific verb and resource ('Delete code reaction') and pins it to the endpoint DELETE /api/v2/strategy/reaction/code/{id}. This is enough to separate it from the llm-reaction and folder siblings, though it does not explicitly distinguish it from delete_strategy_reaction_code_id_store.
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 guidance on when to delete a code reaction versus using the sibling tools (id_store, folder_id, llm variants) or on prerequisites such as ownership. The agent is left to infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete code reaction storage. DELETE /api/v2/strategy/reaction/code/{id}/store
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered structurally. The description adds nothing beyond that — it never says what data is destroyed, whether the deletion is reversible, or what happens to related resources.
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?
Very short and front-loaded, which is good, but the second sentence is a raw HTTP endpoint that duplicates the path already implied by the tool name and adds no semantic value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A destructive tool with no output schema, no parameter documentation, and a crowded delete-family sibling set needs more than a two-fragment description. An agent cannot confidently tell this apart from delete_strategy_reaction_code_id or know what the 'store' resource contains.
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?
One parameter with 0% schema description coverage, so the description must compensate. It does not: the path fragment '{id}' only weakly implies that 'id' is the strategy reaction code identifier, with no clarification of its format 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?
States a specific verb and resource ('Delete code reaction storage'), so the basic operation is identifiable. However, it does not distinguish this tool from the near-identical sibling delete_strategy_reaction_code_id, nor explain what 'store' means as opposed to the reaction code itself, leaving the boundary ambiguous.
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 on when to use this versus delete_strategy_reaction_code_id or delete_strategy_reaction_code_folder_id. The description offers no conditions, prerequisites, or alternatives beyond the raw endpoint path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete LLM reaction folder. DELETE /api/v2/strategy/reaction/llm/folder/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Folder ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered structurally. The description adds nothing beyond restating the HTTP method and path — it does not say whether deletion cascades to contained reactions, whether it is reversible, or what happens if the folder is non-empty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short clauses with the operation front-loaded, so nothing is buried. The trailing REST endpoint is mildly redundant but not wasteful, and there is 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 destructive delete whose annotations already flag the risk, the definition is minimally adequate. It is missing the cascade/irreversibility context an agent would want before invoking a folder deletion, but with no output schema and full param coverage there is no other obvious omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single documented "id" (Folder ID) parameter, so the schema carries the parameter semantics. The description adds no format, source, or lookup detail beyond it, which is the expected baseline of 3.
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 gives a clear verb+resource ("Delete LLM reaction folder"), which distinguishes it from the sibling delete_strategy_reaction_llm_id (deletes a reaction, not a folder) and delete_strategy_reaction_code_folder_id (code vs LLM). It does not explicitly name those alternatives, so it falls 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 when-to-use guidance, no prerequisite or authorization note, and no mention of alternatives such as deleting the reaction itself versus its containing folder. The agent is left to infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete LLM reaction. DELETE /api/v2/strategy/reaction/llm/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so safety is covered. The description adds only the raw HTTP route, saying nothing about irreversibility, cascade effects on dependent sessions/webhooks, 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?
Two short sentences with no padding; the action is front-loaded. The HTTP verb/path is of limited value to an agent but is a compact convention, not bloat.
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 destructive mutation with no output schema and an entirely undocumented parameter, the description should explain what is deleted and with what consequence. It does neither, leaving the agent to guess at scope and reversibility.
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 0% for the single required parameter 'id', and the description does not compensate. The route template hints that id sits in the path, but the description never says whether it is a reaction id, session id, or something else, or what format it takes.
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: 'Delete LLM reaction'. This clearly distinguishes it from the get_/put_/post_strategy_reaction_llm_id siblings. It stops short of any scoping detail, but the core purpose 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?
No when-to-use guidance, no prerequisites, no exclusions, and no mention of related tools such as put_strategy_reaction_llm_id_reset or the folder variant delete_strategy_reaction_llm_folder_id. The agent must infer everything.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete bot webhook. DELETE /api/v2/webhook/bot/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=false, so the safety profile is covered. The description adds only the REST route, disclosing nothing about irreversibility, whether associated shares/configuration are also removed, or failure behavior for an unknown id.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short fragments with zero filler and the purpose front-loaded before the route. It is terse rather than bloated, though the second fragment is largely redundant with the tool name.
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 destructive, no-output-schema operation this is thin: it omits irreversibility, any cascade effects on shared webhook bots, and error semantics for missing ids. The presence of destructive annotations covers part of the burden, but the description leaves real gaps.
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% and the single 'id' property is an untyped string with no description. The path template '/webhook/bot/{id}' is the only hint that this identifies a bot webhook, but the description never states the format, source, or validity conditions of that 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?
The description names a specific verb and resource ('Delete bot webhook'), which is clear and unambiguous. It does not, however, distinguish this tool from the closely named sibling delete_webhook_bot_share_id, which targets a different sub-resource, so sibling differentiation is left to the tool name alone.
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 this tool should be used versus alternatives, no prerequisites (e.g. ownership or auth scope), and no exclusions. An agent must infer all routing logic from the tool name and the crowded delete_* sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete data webhook. DELETE /api/v2/webhook/data/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds only the raw REST endpoint, which restates the operation without disclosing what gets destroyed, whether it is reversible, or any auth/rate-limit 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?
Two short, front-loaded sentences with no filler. The endpoint string is mildly redundant against the annotations but 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?
Acceptable for a simple one-parameter delete tool whose destructive nature is already flagged by annotations and which has no output schema to explain. It still lacks any usage context or id-format guidance, leaving it at minimum viable.
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% for the single required "id" parameter, so the description technically carries the burden. The DELETE path template with {id} implies id is a path identifier for the webhook-data resource, which adds marginal meaning, but nothing about format or where the id originates is stated.
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 ("Delete data webhook"), which cleanly separates it from delete_webhook_bot_id and delete_webhook_data_share_id. It is clear but does not itself articulate the distinction; the differentiation rides on the tool name rather than the description text.
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 when-to-use, prerequisites, or alternative guidance is given. The agent is told what the tool does but not when to prefer it over delete_webhook_bot_id or delete_webhook_data_share_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all friendships by status. GET /api/v2/account/friend/all/{status}
| Name | Required | Description | Default |
|---|---|---|---|
| status | Yes | Friendship status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered by structured data. The description only adds the underlying HTTP route (GET /api/v2/account/friend/all/{status}); it says nothing about result shape, ordering, size limits, or whether an empty status returns an empty list.
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 very short sentences, front-loaded with the purpose and followed by the route. Nothing is padded, though the route string is largely redundant with the tool name and the parameter placeholder.
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-enum-parameter, read-only tool with annotations covering safety and no output schema to explain, the definition is essentially complete. The only real gap is disambiguation from the near-duplicate rejected-friendship sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter has an explicit enum (pending, accepted, rejected), so the schema carries the parameter meaning. The phrase 'by status' merely restates the parameter and adds no format, default, or semantic detail beyond the enum.
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 (get), resource (all friendships) and the filter dimension (by status), so the agent knows exactly what the call returns. It does not, however, differentiate itself from adjacent siblings such as get_account_friend_rejected, which is effectively the status=rejected case of this same resource.
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 it should be called to list friendships for one status, but nothing states when this is preferable to get_account_friend_rejected or get_account_friend_status_side. No exclusions, prerequisites, or pagination caveats are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get paginated rejected friend requests. GET /api/v2/account/friend/rejected
| Name | Required | Description | Default |
|---|---|---|---|
| page | Yes | ||
| limit | Yes | Page size, max 100 (larger values are capped to 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the pagination behavior and echoes the GET endpoint, but says nothing about auth requirements, ordering of results, or what a page 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?
Two short, front-loaded sentences with no filler; the endpoint path is arguably redundant with the tool name but takes only a few tokens.
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 read-only paginated list with no output schema, the description covers the essentials but leaves the undocumented 'page' parameter and the shape of returned rejected-request records unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (limit is documented as max 100 in the schema, page is undocumented). The description only says 'paginated', which hints at page/limit semantics but adds no bounds, defaults, or format detail beyond what the schema already provides.
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 (Get) and resource (rejected friend requests) plus the pagination trait, which cleanly separates it from siblings like get_account_friend_all_status and get_account_friend_status_side. It does not explicitly name those siblings as alternatives, 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?
The scope (rejected requests only) implicitly tells the agent when this tool applies, but there is no explicit when-to-use, when-not-to-use, or alternative routing guidance despite two closely related friend-status siblings existing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get paginated friendships by status and side. GET /api/v2/account/friend/{status}/{side}
| Name | Required | Description | Default |
|---|---|---|---|
| page | Yes | ||
| side | Yes | Requests sent by the user, received by the user, or both | |
| limit | Yes | Page size, max 100 (larger values are capped to 100) | |
| status | Yes | Friendship status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, destructiveHint=false, so safety is covered. The description adds that results are paginated and exposes the underlying REST path, which is mild extra context, but it says nothing about authentication requirements or what a page 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?
Two short sentences, front-loaded with the action and scope. The trailing GET path is largely redundant with the tool name and parameters but is compact enough not to be wasteful.
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 read-only paginated list with no output schema, the definition covers the essentials (resource, filters, pagination). It omits what a page returns, default page/limit behavior, and how it relates to the other account-friend endpoints, leaving modest gaps.
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 75% (side, status, and limit are documented; page is not). The description's 'by status and side' merely restates schema enum semantics and adds no syntax, defaults, or format detail beyond what is already there, 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 ('Get') and resource ('friendships') plus the two filter dimensions (status, side) and that results are paginated. It is reasonably distinct from the account-friend siblings, though it never names them (e.g. get_account_friend_all_status, get_account_friend_rejected) to make the boundary explicit.
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 when-to-use guidance, no exclusions, and no pointer to the sibling tools that fetch all statuses or only rejected friendships. The agent must infer selection from the parameter names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the authenticated user's account. GET /api/v2/account/me
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured fields. The description adds only the REST endpoint path and the implicit 'authenticated user' scoping; it discloses no return shape, pagination, or auth/permission requirements beyond what annotations give.
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 very short sentences with the core purpose front-loaded. The trailing 'GET /api/v2/account/me' is redundant REST trivia but costs little.
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 no-parameter read of the current account, the definition is sufficient: annotations cover the safety profile and no output schema exists to explain. The only gap is that it does not characterize what account fields come back, which is minor for such a straightforward 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?
The tool takes zero parameters, so per the baseline the description carries no parameter burden and a 4 applies. Nothing in the description is needed to clarify arguments because there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Get the authenticated user's account'), which is unambiguous and clearly distinct from the many friend/signal/webhook siblings. It does not, however, name or contrast against any alternative, so differentiation relies on the name alone.
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 authenticated user's account' – there is no parameter to select a different account, so the intent is inferable. There is no explicit when-to-use or when-not guidance and no mention of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all exchange API keys for user. GET /api/v2/api/exchange
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only the per-user scoping; it says nothing about whether secrets are returned or how many keys come back. The endpoint path is API documentation rather than agent-useful 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?
Two short sentences with the purpose front-loaded. The trailing HTTP endpoint ('GET /api/v2/api/exchange') is redundant for an agent but costs little.
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 list tool with no output schema, the definition is adequate but thin: it does not indicate what fields an exchange API key record exposes or whether secrets are masked, which matters for a credentials-listing endpoint. Annotations cover the safety dimension, keeping this at a minimum-viable level.
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 to document and no parameter-semantics burden; baseline 4 applies. The description adds no param detail, but none 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?
States a specific verb (Get) and resource (exchange API keys) scoped to the user, which naturally separates it from get_api_llm and get_api_prediction. It does not explicitly name or contrast a sibling, so it falls just short of the top tier.
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 use this versus get_exchange, get_api_exchange_bot_signal_id, or the post/delete API-key siblings. The agent must infer usage entirely from the name and resource.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get signal bots that use an API key. GET /api/v2/api/exchange/bot/signal/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| page | Yes | ||
| limit | Yes | Page size, max 100 (larger values are capped to 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile needs no restating. Beyond that, the description contributes only the endpoint path and adds nothing about what the id identifies, pagination behavior, or permissions required for an API-key-scoped read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded fragments with no filler. The endpoint path is marginal value but costs little, 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?
No output schema exists, but the description still omits the meaning of the required 'id' and the pagination semantics implied by page/limit, leaving key invocation details undocumented for a fully-required 3-parameter tool.
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% (just the 'limit' cap) and the description explains no parameter at all — it never says whether 'id' is an exchange API-key id, a bot id, or a signal id. With low coverage the description was required to compensate and does not.
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 verb and resource ("Get signal bots that use an API key") and exposes the endpoint path, so the general intent is recoverable. However it is ambiguous about the returned entity: the path takes a single {id} yet the schema demands page/limit, suggesting a paginated list, and it does not distinguish this from siblings like get_api_exchange or get_api_prediction_bot_signal_id.
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 guidance on when to use this tool versus the many sibling get_* endpoints, and no prerequisites or exclusions are stated. The agent must infer selection purely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all LLM API keys for user. GET /api/v2/api/llm
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only the user-scoping ('for user') and the REST endpoint path, but says nothing about pagination, result size, or whether keys are masked.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the purpose front-loaded; every clause is brief. The trailing 'GET /api/v2/api/llm' is largely redundant implementation detail but adds negligible bloat.
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 plus annotations cover what an agent needs to invoke it. The only gap is return behavior (pagination/shape), which is minor for a simple list endpoint.
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 schema is trivially complete and the description introduces no parameter ambiguity.
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 (Get) and resource (all LLM API keys for the user), which is distinguishable from siblings like get_api_llm_services and get_api_llm_models_serviceId. It is clear but does not explicitly contrast itself with 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?
No statement of when to use this tool versus get_api_llm_services, get_api_llm_models_serviceId, or post_api_llm. The read-only listing purpose is inferable from the verb, but there is no explicit context or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get models for a specific service. GET /api/v2/api/llm/models/{serviceId}
| Name | Required | Description | Default |
|---|---|---|---|
| serviceId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds nothing behavioral beyond restating the HTTP endpoint — no return shape, no ordering, no empty-result 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?
Two short sentences, front-loaded with the purpose before the endpoint detail. Nothing is redundant, though the endpoint string contributes little beyond the name itself.
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 read-only endpoint with no output schema the description is barely adequate. It hints that a service must already exist, but omits where serviceId originates and what a returned 'model' contains, leaving the agent to guess at the input's provenance.
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 carries the full burden for the single required serviceId parameter. It only mirrors the path template '{serviceId}' and never explains whether the value is an ID, slug, or name, or how to obtain one.
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: 'Get models for a specific service,' which is unambiguous and distinguishable from get_api_llm_services (lists services) and get_api_llm. However, it never names or contrasts those siblings explicitly, so the differentiation is left to inference from the naming pattern.
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 guidance on when to use this tool versus get_api_llm or get_api_llm_services, nor any prerequisite such as where a valid serviceId comes from. The only usage signal is implicit in the verb/resource pair.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all enabled LLM services. GET /api/v2/api/llm/services
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds only the underlying HTTP route, which is marginally useful context; it says nothing about return shape, ordering, or whether disabled services are excluded vs. error.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, purpose front-loaded with zero filler. The trailing raw endpoint is developer-oriented rather than agent-oriented, which keeps it just short of ideal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter read tool this covers the essentials, but with no output schema the description does not indicate what a 'service' record contains or how many are returned. An agent knows what to call but not what it will get 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?
The tool takes zero parameters, so there is nothing for the description to disambiguate — baseline 4 per the rubric. The 'enabled' qualifier clarifies the implicit filter applied with no arguments.
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 (Get) and resource (LLM services) with a scoping qualifier ('enabled'), so an agent can tell it apart from the broader get_api_llm and the parameterized get_api_llm_models_serviceId. It doesn't explicitly name those siblings, but the resource/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?
No when-to-use guidance and no routing to alternatives, despite a dense sibling set (get_api_llm, get_api_llm_models_serviceId, post_api_llm, put_api_llm_id_model). The 'enabled' filter is a hint but not framed as usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all prediction API keys. GET /api/v2/api/prediction
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds only the raw HTTP path (GET /api/v2/api/prediction) and no context about authentication needs, whether the returned keys are masked or full secrets, or result size/pagination — so it contributes little beyond structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no padding. The trailing REST path is mildly redundant given the tool name, but it is compact and harmless.
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?
With no parameters, no output schema, and annotations covering safety, the definition is close to adequate. However, it leaves open whether the response is a paginated list and, more importantly, whether the returned API keys are exposed in full — a security-relevant detail an agent may need before surfacing them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate. The baseline of 4 applies for a parameterless tool.
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 ('Get all prediction API keys'), which clearly distinguishes it from the sibling list endpoints get_api_exchange and get_api_llm by domain. It does not explicitly name those siblings, but the 'prediction' qualifier makes the scope 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?
There is no guidance on when to use this versus get_api_prediction_bot_signal_id, post_api_prediction, or put_api_prediction_id_status. An agent must infer usage entirely from the name and the surrounding tool list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get prediction signal bots by API ID. GET /api/v2/api/prediction/bot/signal/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| page | Yes | ||
| limit | Yes | Page size, max 100 (larger values are capped to 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered elsewhere. The description adds only the raw HTTP path, which carries no behavioral value (pagination behavior, capping, or result shape are 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?
Two short sentences with the purpose front-loaded and no padding. The trailing HTTP path is low-value but costs a single clause, so the entry is still tight.
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 three-required-parameter paginated read with no output schema and incomplete param docs, the description omits pagination semantics, id format, and return content. The agent has too little to invoke it correctly versus its many siblings.
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% — 'id' and 'page' are undocumented in both schema and description, and 'page' has even stranger bounds (negative minimum) that the description ignores. The description adds no meaning beyond what 'limit' already declares in 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 verb and resource ('Get prediction signal bots by API ID'), but the resource phrasing is ambiguous and overlaps heavily with siblings like get_bot_signal_prediction_id and get_api_prediction. It never clarifies whether it returns signal bots attached to a prediction API credential or something else, so an agent cannot confidently distinguish it from neighbors.
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 when-to-use guidance, no prerequisites, and no mention of alternatives despite a dense sibling set (get_bot_signal_prediction, get_bot_signal_prediction_id, get_api_prediction). The agent must infer usage purely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all CEX signal bots. GET /api/v2/bot/signal/cex
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds nothing on top — no pagination behavior, no result-volume caveat, no ordering or filtering semantics — so it contributes no behavioral value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no padding. The trailing "GET /api/v2/bot/signal/cex" is redundant implementation detail that an agent does not need, a minor non-earning sentence, but the overall size is appropriate.
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?
This is a low-complexity, zero-parameter read, so the description is nearly adequate. However, with no output schema, the description carries the burden of conveying the return shape and whether the listing is paginated or bounded; "get all" hints at an unpaginated collection but leaves result size and empty-result behavior 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, which is the baseline-4 case; there is no parameter semantics to clarify and the schema is empty by design (schema coverage reported at 100%). Nothing in the description is needed to invoke it correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
"Get all CEX signal bots" gives a clear verb (get) plus resource (CEX signal bots) and implies collection scope via "all". It does not, however, distinguish itself from close siblings such as get_bot_signal_cex_id (single bot), get_bot_signal_cex_total (counts), or get_bot_signal_dex / get_bot_signal_prediction — the agent must infer the boundary from naming conventions alone.
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 when-to-use context, no exclusions, and no alternatives are named. With five sibling list/get tools in the bot_signal family, the description offers no routing guidance about when this collection read is preferable to the _id, _total, or _dex/_prediction variants.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all CEX signal bot folders. GET /api/v2/bot/signal/cex/folder
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds nothing beyond that: no pagination behavior, no ordering, no note on whether it returns the full tree or just top-level folders.
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 very short sentences, front-loaded with the purpose. The trailing 'GET /api/v2/bot/signal/cex/folder' restates the endpoint and adds little for an agent that cannot call HTTP directly, but it is not costly.
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 no-param, read-only list tool this is adequate, but with no output schema the description could say more about what a 'folder' record contains or whether the result is flat or nested. It leaves the return shape entirely unspecified.
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; the baseline for a 0-param tool is 4. The description correctly implies a parameterless list operation.
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 ('Get all CEX signal bot folders'), and the word 'all' implicitly distinguishes it from the sibling get_bot_signal_cex_folder_id (single folder) and get_bot_signal_cex_folder_root (root only). It does not name those siblings explicitly, so the 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?
There is no explicit when-to-use guidance, no mention of alternatives, and no prerequisites. The agent must infer from 'all' that this is the listing tool and from the sibling names that _id/_root fetch narrower scopes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get CEX signal bot folder by ID. GET /api/v2/bot/signal/cex/folder/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Folder ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only the raw HTTP route, which provides no behavioral context beyond what annotations and schema already give (no auth, error, or return 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?
Two short sentences, front-loaded with the purpose. The trailing HTTP endpoint is largely redundant with the tool name but is compact enough not to hurt 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?
For a simple read-only single-parameter lookup with full schema coverage and annotations carrying the safety profile, the description is adequate but minimal. It omits what the folder object contains and any error semantics for an invalid ID, though no output schema exists to cover returns.
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% with a single required 'id' parameter already documented as 'Folder ID'. The description adds nothing beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Get) and resource (CEX signal bot folder by ID), which is clearly distinct from the list variant get_bot_signal_cex_folder and the root variant get_bot_signal_cex_folder_root. It does not explicitly call out those siblings, so it falls 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 when-to-use guidance, no prerequisites, and no mention of the alternative retrieval tools (get_bot_signal_cex_folder, get_bot_signal_cex_folder_root). The agent must infer 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.
Get CEX signal bots from root folder. GET /api/v2/bot/signal/cex/folder/root
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds nothing behavioral beyond repeating the HTTP route: no indication of what is returned, whether results are paginated or complete, or whether auth/ownership scoping applies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the purpose front-loaded and no padding. The trailing raw endpoint path is mildly redundant with the name but does not obscure anything.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only call with no output schema, the description leaves the most important unknown unresolved: what the response contains (a list of bots vs. the root folder record) and whether it is exhaustive. Annotations cover safety, but the return semantics gap is material in a family of near-identical sibling tools.
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 schema is complete by definition and there is nothing for the description to clarify. Baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb and resource ('Get CEX signal bots') and scopes it to the root folder, which separates it from the generic get_bot_signal_cex. However, it never contrasts itself with the very similar siblings get_bot_signal_cex_folder and get_bot_signal_cex_folder_id, and it is ambiguous whether the call returns bots or the root folder object (the tool name says folder_root, the description says 'bots').
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 when-to-use guidance, no statement of prerequisites, and no mention of alternatives. An agent must infer from the name alone whether to call this, get_bot_signal_cex_folder, or get_bot_signal_cex_folder_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get CEX signal bot by ID. GET /api/v2/bot/signal/cex/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds nothing further — no auth requirements, no pagination or error behavior, no indication of what is or is not returned — which is acceptable given the annotation coverage but not additive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action, with no filler. The raw HTTP endpoint restatement is somewhat redundant but compact and potentially useful for routing.
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 point-getter with no output schema, the definition covers the core action but leaves the response shape, error cases (e.g., not-found), and any auth expectations unexplained. Adequate but with clear gaps.
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 one parameter with 0% schema description coverage; the description's 'by ID' only conveys that the id identifies a bot, and the endpoint template '{id}' confirms placement but adds no format, type, or source guidance. Baseline for a single obvious id param with no schema docs is a middle 3.
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 ('Get CEX signal bot by ID'), which distinguishes it from the list variant get_bot_signal_cex and from the DEX/prediction siblings by resource type. It does not explicitly name the sibling it is not, 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?
The phrase 'by ID' implies this is the single-item retrieval path versus the list endpoint, but there is no explicit when-to-use, no prerequisites, and no named alternative such as get_bot_signal_cex. Usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the total number of CEX signal bots. GET /api/v2/bot/signal/cex/total
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safe read-only nature is covered. The description adds only the underlying REST endpoint, disclosing nothing extra about return format, auth, or edge cases; with a count tool this is minor, but the description contributes little beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the purpose. The trailing REST path is marginally useful reference but adds little for an agent; still, 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?
For a zero-parameter count tool with no output schema and full annotation coverage, the description is adequate: it says what is counted and that the result is a total. It could note whether the total is workspace-scoped or global, but the core is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so the baseline is 4. There is no parameter semantics to clarify and the description correctly implies a global unfiltered total.
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+resource ('Get the total number of CEX signal bots'), which is clear and unambiguous. It does not explicitly differentiate itself from sibling aggregators like get_bot_signal_dex_total or get_bot_signal_prediction_total, but the 'CEX' scope is self-evident from the name and description.
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 it to obtain a count of CEX signal bots, distinct from get_bot_signal_cex which lists them. There is no explicit when-to-use/when-not statement or named alternative, so guidance is inferable but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all DEX signal bots. GET /api/v2/bot/signal/dex
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only the raw endpoint path, revealing nothing about return shape, pagination, or volume, which is a modest gain over the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short clauses, purpose front-loaded, no filler. The trailing API path is slightly redundant but harmless.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read-only list tool with no output schema, the description plus annotations give an agent enough to select and call it. Return format and pagination behavior are the only unaddressed items, and they are minor at this 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 tool takes zero parameters, so the baseline is 4; there is no parameter meaning for the description to supply. It neither misleads nor adds anything here.
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 ('Get all DEX signal bots'), and the 'all' plus 'DEX' distinguishes it from get_bot_signal_dex_id and get_bot_signal_dex_total among the DEX siblings. It does not explicitly name those alternatives, so it stops short of full sibling differentiation.
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 when-to-use, prerequisites, or alternatives are stated. An agent must infer that this is the enumeration call versus the folder/CEX/prediction variants 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.
Get DEX signal bot by chain and address. GET /api/v2/bot/signal/dex/{chainId}/{address}
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | ||
| chainId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds nothing behavioral beyond restating the HTTP route: no mention of what is returned, what happens when no bot matches the pair, or whether the signal bot must be owned/accessible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the purpose, with no filler. The appended raw endpoint path adds little value for an agent and is the only wasted token.
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 read tool with two required, undescribed parameters and no output schema, the description should say what a successful response contains and how failures (unknown chain/address) surface. Neither is addressed, leaving the agent unable to predict 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 0% and both parameters are required and undocumented, so the description carries the full burden. It only echoes the parameter names conceptually ('chain and address') and gives no format guidance, e.g. whether chainId is a numeric string, a slug, or that address must be the bot's on-chain address.
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 ('Get') and resource ('DEX signal bot') along with the lookup key ('by chain and address'), which sets it apart from the ID-based sibling get_bot_signal_dex_id. However, it never explicitly names that sibling or the folder/total variants, so differentiation is only implicit.
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 when-to-use or when-not-to-use guidance, and no alternatives are named despite a dense cluster of near-identical get_bot_signal_dex* tools. The 'by chain and address' phrasing hints at the selector but leaves the agent to infer when this tool beats get_bot_signal_dex_id or get_bot_signal_dex_factory_chainId_exchangeId.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get bot factory by chain and exchange. GET /api/v2/bot/signal/dex/factory/{chainId}/{exchangeId}
| Name | Required | Description | Default |
|---|---|---|---|
| chainId | Yes | ||
| exchangeId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false. The description adds the HTTP endpoint path, which is useful context, but does not cover authentication, rate limits, or response behavior beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero waste. The purpose is front-loaded and the endpoint follows immediately, making the definition 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?
For a two-parameter getter with no output schema and no parameter descriptions, the definition is too thin. It names the inputs but does not explain what a 'bot factory' is, how to obtain valid chainId/exchangeId values, or how the result differs from sibling endpoints.
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. It only restates the parameter names as 'chain and exchange' without formats, examples, allowed values, or any explanation of what chainId and exchangeId represent.
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 ('Get bot factory') with scoping by chain and exchange. It does not explicitly differentiate itself from sibling tools such as get_bot_signal_dex_chainId_address, so it falls 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?
No when-to-use guidance or alternatives are provided. The description implies retrieving a bot factory for a given chain/exchange, but there are no exclusions, prerequisites, or routing hints among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all DEX signal bot folders. GET /api/v2/bot/signal/dex/folder
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds essentially nothing beyond 'all' – no indication of whether nested folders are included, whether results are paginated, or what the response shape is for what could be an unbounded list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no padding; the purpose comes first and the endpoint path trails it. The raw HTTP path is mildly redundant but arguably useful for disambiguation.
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 no-argument list tool with annotations covering the safety profile and no output schema, this is minimally viable. It still leaves open how 'all' behaves (root vs. full tree, pagination, ordering), which matters for a collection endpoint.
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 for the description to supply and the baseline of 4 applies. The description does not need to compensate for anything here.
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 gives a specific verb and resource (get all DEX signal bot folders), which clearly distinguishes the collection endpoint from mutation siblings like delete_bot_signal_dex_folder_id or put_bot_signal_dex_folder_id. It does not, however, differentiate itself from the near-identical get_bot_signal_dex_folder_id and get_bot_signal_dex_folder_root, which an agent could easily confuse with it.
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 when-to-use guidance at all. Nothing tells the agent to pick this over get_bot_signal_dex_folder_root (root-level only) or get_bot_signal_dex_folder_id (single folder), even though those are the exact alternatives that matter here.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get DEX signal bot folder by ID. GET /api/v2/bot/signal/dex/folder/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Folder ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that and the raw route string, providing no new behavioral context such as error behavior or what a folder object 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?
Two short, front-loaded sentences with no padding. The trailing HTTP route is redundant implementation detail rather than useful agent-facing content, which is the only minor inefficiency.
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, non-destructive getter with a fully documented single parameter and no output schema, the description is minimally adequate. It omits any mention of what the folder record contains or failure modes, leaving some gaps for an agent.
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% ('Folder ID'), so the single required parameter is fully documented in the schema. The description's 'by ID' adds no syntax, format, or sourcing detail beyond what the schema already states.
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 gives a specific verb and resource ('Get DEX signal bot folder by ID'), which is enough to separate it from sibling get_bot_signal_dex_folder (list) and get_bot_signal_dex_folder_root. It does not explicitly name those siblings, but the 'by ID' qualifier makes the distinction inferable.
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 on when to use this versus get_bot_signal_dex_folder, get_bot_signal_dex_folder_root, or the CEX/prediction folder variants. The agent must infer usage purely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get DEX signal bots from root folder. GET /api/v2/bot/signal/dex/folder/root
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds nothing behavioral beyond restating the endpoint path; no pagination, sorting, or return-shape context is given.
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?
One short, front-loaded sentence states the action. The trailing 'GET /api/v2/bot/signal/dex/folder/root' is redundant with the tool name and adds little, keeping it just short of 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 with no output schema, the description conveys enough to call it correctly: it returns DEX signal bots from the root folder. It does not mention ordering or pagination, but nothing critical 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 per the rubric the baseline is 4. There is nothing for the description to clarify about inputs.
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 (Get) and resource (DEX signal bots from the root folder), which distinguishes it from siblings like get_bot_signal_dex_folder_id that presumably target a specific folder. It does not explicitly name those siblings, so it falls 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?
Usage is only implied by the name/description: use this to list bots at the root of the DEX signal folder tree. There is no explicit 'when to use this vs get_bot_signal_dex_folder / get_bot_signal_dex_folder_id' guidance or mention of prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get DEX signal bot by ID. GET /api/v2/bot/signal/dex/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the REST endpoint path (GET /api/v2/bot/signal/dex/{id}), which is mildly useful context, but says nothing about error behavior or what a missing ID returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no padding. The endpoint path is slightly redundant but harmless.
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 getter with no output schema, the description does not indicate what a returned bot object contains or which identifiers are valid. Annotations cover safety, but the description leaves the retrieval semantics thin.
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 one parameter with 0% schema description coverage, so the schema does not explain what 'id' refers to. The description's 'by ID' implies the identifier is the bot ID, which is only a small addition over the bare 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 (Get) and resource (DEX signal bot) qualified by 'by ID', which distinguishes it from the sibling get_bot_signal_dex list endpoint. It does not, however, explicitly name the alternatives it differs from.
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 when-to-use guidance, no prerequisites, and no mention of sibling tools such as get_bot_signal_dex or get_bot_signal_dex_chainId_address. The 'by ID' phrasing only hints that an ID is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the total number of DEX signal bots. GET /api/v2/bot/signal/dex/total
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds only the raw endpoint path; it says nothing about the scope of the count (all bots vs. the caller's bots), whether it is filtered, or the response shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the purpose front-loaded and no filler. The trailing endpoint path is mildly redundant but harmless and aids traceability.
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?
A zero-parameter, read-only count endpoint with full annotation coverage is essentially complete as described; 'total' implies a numeric return. Only the count's scope is unstated, a minor gap for such a simple tool.
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-level gaps exist.
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: 'Get the total number of DEX signal bots.' It is clear what the tool returns, but it does not explicitly distinguish itself from its near-twin get_bot_signal_dex (list) or the parallel get_bot_signal_cex_total / get_bot_signal_prediction_total, so the agent must infer the distinction from naming.
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 when-to-use guidance, no mention of alternatives such as get_bot_signal_dex or the sibling total endpoints, and no conditions or prerequisites. Usage is only inferable from the word 'total'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all prediction signal bots. GET /api/v2/bot/signal/prediction
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered by structured data. The description only adds the underlying endpoint (GET /api/v2/bot/signal/prediction), and says nothing about pagination, result size, ordering, or how complete the 'all' result is — which is meaningful for a list endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short clauses, front-loaded with the purpose and then the endpoint. No filler, though the second clause is closer to an implementation detail than agent-facing guidance.
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?
With no output schema, the description carries the burden of indicating what comes back, but it says only 'all'. There are no params or annotations gaps to compensate for, so it is minimally adequate, but an agent still cannot tell whether the list is paginated, ordered, or filtered.
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 schema description coverage is 100%, so there is nothing for the description to clarify. Baseline 4 applies for a parameterless tool.
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+resource ('Get all prediction signal bots'), which implies a list of prediction signal bots and distinguishes it from the singular get_bot_signal_prediction_id. It does not explicitly name sibling alternatives such as get_bot_signal_prediction_folder or _total, but the 'all' scope makes the intent readable.
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 when-to-use guidance: it does not say how this differs from get_bot_signal_prediction_id, get_bot_signal_prediction_folder, _folder_root, _market_exchange_slug, or _total beyond the implied 'all'. No prerequisites, no exclusions, no routing advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all prediction signal bot folders. GET /api/v2/bot/signal/prediction/folder
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds only the raw endpoint path, no behavioral context such as pagination, ordering, or folder hierarchy shape. With annotations carrying the safety profile, this is adequate but thin.
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?
One short sentence plus the endpoint. Zero waste, fully front-loaded, nothing an agent must scan past.
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 and safety annotations, the purpose is covered. However, without an output schema the description gives no hint of the return shape (folder list vs tree) or how it relates to the _root and _id variants, leaving real gaps for an agent choosing between four similar folder endpoints.
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 to disambiguate and the baseline is 4. The description adds no parameter confusion and schema coverage is 100%.
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 (Get) and resource (all prediction signal bot folders), and the embedded endpoint path confirms the resource scope. It is distinguishable from siblings like get_bot_signal_prediction_folder_root and get_bot_signal_prediction_folder_id, though 'all' does the distinguishing rather than explicit differentiation.
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 on when to use this versus the closely related get_bot_signal_prediction_folder_root, get_bot_signal_prediction_folder_id, or the per-type cex/dex folder siblings. The agent must infer that this returns the full folder collection and others return roots or single folders.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get prediction signal bot folder by ID. GET /api/v2/bot/signal/prediction/folder/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Folder ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description only adds the raw REST path, which is minor context, and says nothing about the returned folder shape or error 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?
Two short sentences, front-loaded with the purpose; the endpoint path is arguably redundant but compact and harmless. 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?
For a simple read-by-ID tool with annotations covering safety and a fully documented schema, the description is sufficient to invoke correctly. With no output schema, it could say what the folder object contains, but this is a minor 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?
Single required 'id' parameter with 100% schema description coverage, so the schema already carries the semantics. The description adds nothing beyond confirming the lookup is by ID, which is the baseline for a fully documented 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 ('Get') and resource ('prediction signal bot folder'), and the 'by ID' qualifier distinguishes it from the sibling list-style tools get_bot_signal_prediction_folder and get_bot_signal_prediction_folder_root. It does not explicitly name those siblings, but 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?
No when-to-use guidance or alternatives are given. The 'by ID' phrasing implies a known folder ID is required, but it never states when to choose this over get_bot_signal_prediction_folder or how to obtain the ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get prediction signal bots from root folder. GET /api/v2/bot/signal/prediction/folder/root
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds only the REST endpoint string, which conveys no behavioral traits beyond what the annotations say.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the purpose. The endpoint line restates what the name already conveys and is borderline filler, 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 the description should ideally indicate what a root-folder listing returns (e.g. a list of bot objects). With zero params and read-only annotations the tool is simple, but the return shape remains opaque.
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; schema and description are consistent.
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 ('Get') and resource ('prediction signal bots') plus scope ('from root folder'), which distinguishes it from get_bot_signal_prediction_folder_id (a specific folder). However, it does not differentiate clearly from get_bot_signal_prediction_folder, which sounds like the same non-root listing.
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 when-to-use guidance, prerequisites, or exclusions. The only implicit signal is 'root folder', leaving the agent to infer that this is for top-level listings rather than a named folder.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get prediction signal bot by ID. GET /api/v2/bot/signal/prediction/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only the raw HTTP path, which does not disclose auth requirements, behavior on a missing/invalid ID, or what is returned — leaving the behavioral burden largely unmet.
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 compact fragments with the resource and the ID scoping front-loaded and no filler. It is well-sized for the task, though the trailing raw endpoint path adds little for an agent.
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 get-by-id tool whose annotations cover the safety profile, the description is minimally adequate, but it leaves the id parameter undefined and provides no output context (no output schema exists) — so an agent knows what it fetches but not the ID contract or return shape.
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 single id parameter has 0% schema description coverage, and the description only restates 'by ID' without defining format, type semantics, or where the ID comes from. With the schema silent and a required parameter present, the description should compensate but does not.
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 (Get) and resource (prediction signal bot) plus the scoping modifier 'by ID', which distinguishes it from the list-style sibling get_bot_signal_prediction. It does not, however, explicitly name any sibling or contrast the folder/market variants, so differentiation is implied 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?
There is no when-to-use, when-not-to-use, or alternative guidance. The 'by ID' phrasing weakly implies you need a known ID, but the description never says to use this vs get_bot_signal_prediction or get_webhook_bot_bot_signal_id_prediction, nor what preconditions exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get prediction market by slug. GET /api/v2/bot/signal/prediction/market/{exchange}/{slug}
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| exchange | Yes | Prediction market exchange |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is fully covered. The description adds only the REST endpoint template, which conveys the path shape but nothing about slug formatting, case sensitivity, error behavior, or response shape. With the annotation bar already met, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the purpose before the endpoint. The path template is somewhat redundant with the tool name but still compact, with no wasted prose.
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?
With no output schema, the description carries the burden of describing the returned prediction market object, but it says nothing about the response. It also omits the slug format despite 'slug' having no schema description, leaving an agent under-informed for a two-required-param lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: 'exchange' is documented in the schema as 'Prediction market exchange', while 'slug' has no description anywhere. The endpoint template shows both values sit in the path, but neither the description nor the schema clarifies slug format or valid exchange values, so the gap is not compensated.
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 ('Get prediction market') plus the lookup key ('by slug'), which is enough to distinguish it from get_bot_signal_prediction_id (by id). It does not explicitly name the id-based sibling as an alternative, 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 when-to-use guidance and no statement of when to prefer the slug route over get_bot_signal_prediction_id or get_bot_signal_prediction. The selection logic is only implied by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the total number of Prediction signal bots. GET /api/v2/bot/signal/prediction/total
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description adds only the REST endpoint path, which is redundant routing metadata rather than behavioral context; nothing about scope (e.g. per-user or per-workspace counting) is 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?
Two short, front-loaded sentences with the purpose first. The appended 'GET /api/v2/bot/signal/prediction/total' is low-value boilerplate but not 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?
For a no-parameter counting tool with no output schema, the description conveys enough to call it correctly; the return type (a number) is evident from the wording. It stops short of full completeness only because scoping of the count is unspecified.
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 accepts zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. Schema coverage is reported at 100% anyway.
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 (Get), resource (Prediction signal bots) and the exact quantity returned (total number). It is distinguishable from siblings like get_bot_signal_prediction (which lists) and get_bot_signal_prediction_id (which fetches one), though it never explicitly names those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: an agent can infer this returns a count instead of a list, so it fits when only an aggregate figure is needed. No explicit when-to-use, when-not-to-use, or named alternative is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all exchanges with optional filtering. GET /api/v2/exchange
| Name | Required | Description | Default |
|---|---|---|---|
| chainId | No | Filter by blockchain chain ID | |
| enabled | No | Filter by enabled status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds essentially nothing behavioral beyond restating that it reads all records and echoing the raw endpoint path — no pagination, result size, or return-shape 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?
A single front-loaded sentence with no filler; the endpoint fragment is arguably redundant but costs little. Efficient, though it is terse to the point of under-specification.
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-optional-parameter list tool with no output schema, the description is minimally adequate. It does not clarify what entity types 'exchange' covers (CEX/DEX/prediction) or how results are returned, which matters given the dense family of similar exchange tools.
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% with only two optional filter parameters (chainId, enabled), each documented in the schema. The description adds no format or semantic detail beyond what the schema already provides, 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 clear verb and resource ('Get all exchanges') plus the scope modifier 'with optional filtering'. However, it gives no differentiation from the several closely named siblings (get_exchange_cex, get_exchange_dex_chain, get_exchange_prediction, get_exchange_with_exchange_rate, get_api_exchange), so an agent cannot tell which exchange listing is intended from the description alone.
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 says 'optional filtering' but never states when this tool is the right choice versus the other exchange-listing siblings, nor any prerequisites or exclusions. There is no routing guidance at all.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all CEX exchanges. GET /api/v2/exchange/cex
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is fully covered elsewhere. The description adds only the raw endpoint path, which conveys no behavioral context beyond what the annotations provide (no mention of result size, pagination, or ordering).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences that are front-loaded with the purpose. The trailing endpoint path is largely redundant metadata but costs little.
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 no-arg list tool with safety annotations, this is minimally adequate. With no output schema, the description could still note the shape of the returned list (identifiers, names, count), which an agent would need to know before using 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?
The tool takes zero parameters, so the schema is trivially complete and the description has nothing to compensate for. This meets the baseline for a no-parameter tool.
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 ('Get all CEX exchanges'), and the 'CEX' qualifier implicitly distinguishes it from the DEX, prediction, and generic exchange siblings. However, it never names those alternatives, so the 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?
The scope ('all CEX exchanges') implies when the tool applies, but there is no explicit when-to-use, no exclusion, and no pointer to get_exchange, get_exchange_dex_chain, or get_exchange_with_exchange_rate. Usage is left to inference from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all DEX exchanges by chain ID. GET /api/v2/exchange/dex/{chain}
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | Blockchain chain ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, covering the safety profile. The description adds nothing behavioral beyond restating the endpoint path (which duplicates the schema's chain param) – no mention of pagination, result size, or whether 'all' is unbounded. With annotations carrying the safety burden, this is a thin contribution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the purpose, with no padding. The trailing 'GET /api/v2/exchange/dex/{chain}' is largely redundant with the schema and annotations, slightly diluting the value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a trivial, single-parameter read-only lookup, the definition says enough to call it correctly, and annotations cover the safety profile. Return shape is unstated and there is no output schema, but 'all DEX exchanges' reasonably implies a list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single param 'chain' is documented as 'Blockchain chain ID'. The description only echoes this ('by chain ID') without adding format, allowed values, or naming conventions, 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?
The description gives a specific verb and resource ('Get all DEX exchanges') plus the scoping dimension ('by chain ID'), which implicitly distinguishes it from the CEX/prediction siblings. It does not, however, name those alternatives explicitly, so differentiation requires the agent to infer it from the 'dex' token.
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 'by chain ID' and the DEX scope, but there is no explicit when-to-use versus get_exchange_cex or get_exchange statement, and no preconditions are given. The agent must infer the selection logic from names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all Prediction exchanges. GET /api/v2/exchange/prediction
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without the description. The description adds nothing beyond that: it doesn't say whether results are cached, unpaginated, sorted, or scoped to the caller's account.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short fragments, front-loaded with the purpose; nothing is padded. The trailing endpoint path is mildly redundant with the tool name, but it is a legitimate disambiguator rather than 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 trivial no-parameter list endpoint with full annotation coverage and no output schema, the description is minimally sufficient to call the tool. It is incomplete on the one thing that matters for a 'get all' call — result size/pagination behavior — but nothing an agent needs to invoke it correctly is strictly absent.
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 schema has nothing to explain and the description cannot add parameter meaning. Baseline 4 applies for a no-argument tool.
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 ('Get all Prediction exchanges') and even gives the underlying endpoint, so the agent knows this is a read of the prediction-market exchange catalog. It does not explicitly contrast itself with near-name siblings like get_exchange, get_exchange_cex or get_exchange_dex_chain, so the differentiation is left to the word 'Prediction'.
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 statement of when to choose this over get_exchange, get_exchange_cex, get_exchange_dex_chain, get_exchange_with_exchange_rate or get_api_prediction. The scope is implied only by the adjective 'Prediction'; there are no prerequisites, exclusions, or alternative-routing hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all exchanges with exchange rates. GET /api/v2/exchange/with-exchange-rate
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds nothing behavioral beyond that – no note on return shape, volume, or whether the exchange-rate data is live vs. cached.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the purpose. The appended raw endpoint path is mildly redundant for an agent but is not costly; nothing else is wasted.
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 zero-parameter read tool this is nearly adequate, but with no output schema the description gives no hint of what an 'exchange with exchange rate' record contains or how large the result set is. That omission is tolerable but leaves a real 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?
The tool takes zero parameters, so there are no parameter semantics to document; baseline of 4 applies. The description correctly implies a no-argument retrieval by not claiming any filtering input.
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 verb and resource ('Get all exchanges with exchange rates'), but it essentially restates the tool name and adds only the REST endpoint path. With close siblings like get_exchange, get_exchange_cex, get_exchange_dex_chain, and get_exchange_prediction, nothing here tells an agent how this differs from those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites, and no mention of the sibling exchange tools. The agent is left to infer selection from the name alone, which is ambiguous given the crowded 'get_exchange*' family.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get paginated data logs of a data hook. GET /api/v2/log/data/hook/{hookId}/paginated
| Name | Required | Description | Default |
|---|---|---|---|
| page | Yes | ||
| limit | Yes | Page size, max 100 (larger values are capped to 100) | |
| hookId | Yes | Data hook id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered without the description. The description adds only the 'paginated' trait and the underlying GET path, which is modest value; it says nothing about ordering, total counts, or how paging behaves at the boundary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the purpose, with no padding. The raw endpoint path is largely redundant with the tool name, which is the only minor waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a paginated read tool with no output schema, the description should say something about what paging returns or how to iterate; instead it only repeats 'paginated'. Annotations cover safety and the schema covers two of three params, so it is minimally viable but leaves the agent guessing about page semantics and response shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%: hookId and limit are documented in the schema (including the max-100 cap), but the required 'page' parameter is undocumented anywhere. The description does not compensate, adding no semantics for page indexing or default behavior, so the baseline 3 for partial schema coverage 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+resource ('Get paginated data logs of a data hook'), which is more precise than the bare name and distinguishes it from the sibling get_log_data_paginated by scoping to a single hook. However, it never explicitly contrasts itself with the hook-less or signal-hook log siblings, so differentiation is implied by the name 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?
There is no when-to-use guidance, no prerequisites (e.g., that hookId must reference an existing data hook), and no pointer to alternatives such as get_log_data_paginated for all data logs or get_log_signal_hook_hookId_paginated for signal logs. The agent must infer the routing decision entirely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get paginated data logs. GET /api/v2/log/data/paginated
| Name | Required | Description | Default |
|---|---|---|---|
| page | Yes | ||
| limit | Yes | Page size, max 100 (larger values are capped to 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond restating 'paginated' (already in the name) and the URL path; it does not disclose ordering, whether pagination is offset-based, or what happens past the last page.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no filler. However, the second sentence merely restates the HTTP path, which is low-value for an MCP tool invocation and slightly redundant given the name.
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 paginated read tool with no output schema, the description should at minimum indicate what the returned log records are or the pagination envelope, and should distinguish this log stream from the sibling log endpoints. None of that is present, leaving the agent under-informed despite the simple two-parameter schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%: 'limit' is documented in the schema (max 100, capped), but 'page' has no description anywhere. The description adds zero parameter meaning, so it fails to compensate for the undocumented 'page' parameter and its interaction with the cap on 'limit'.
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?
It names a verb and resource ('Get paginated data logs'), which is more than a bare tautology, but 'data logs' is not distinguished from the numerous sibling log endpoints (get_log_error_paginated, get_log_signal_paginated, get_log_transaction, etc.). An agent cannot tell from the description alone which log stream this returns or how it differs from get_log_error_paginated.
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 when-to-use guidance, no prerequisites, and no mention of alternatives among the many log-listing siblings. The only added sentence is the raw REST path, which does not help an agent choose this tool over get_log_signal_paginated or get_log_error_paginated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an error log by id. GET /api/v2/log/error/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Error log id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds only the raw REST route, which carries no behavioral value: it doesn't say what happens when the id is unknown, whether auth is required, or how errors surface.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the purpose front-loaded and no padding. The trailing endpoint string is mildly redundant but compact enough not to harm usability.
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?
With no output schema, the description should hint at what an error log record contains or how a missing id is reported; it does neither. For a trivial one-parameter getter this is minimally adequate rather than complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single required 'id' parameter already described as 'Error log id'. The description's 'by id' restates the schema without adding format, source, or expected-value 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 ('Get an error log by id'), which clearly separates it from siblings like get_log_error_source_id. It does not explicitly name the closest alternative, get_log_error_paginated, but the 'by id' framing makes the distinction inferable.
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 when-to-use guidance, no prerequisites, and no mention of alternatives. The sibling get_log_error_paginated is the obvious alternative for browsing logs and is never referenced, so the agent must infer selection from names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get paginated error logs. GET /api/v2/log/error/paginated
| Name | Required | Description | Default |
|---|---|---|---|
| page | Yes | ||
| limit | Yes | Page size, max 100 (larger values are capped to 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds nothing beyond restating the REST path; it discloses no pagination behavior, ordering, or return shape for a tool whose whole purpose is paging.
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?
It is short and front-loaded, but the second sentence ('GET /api/v2/log/error/paginated') merely restates the HTTP endpoint and adds no selection value. Minimal but not wasteful enough to penalize heavily.
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 pagination tool with required page/limit params, no output schema, and no annotations about returns, the description should explain paging behavior or what a page contains. It offers none of that, leaving the agent under-informed.
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 50%: 'limit' is documented (max 100) but 'page' has no description in either the schema or the description. The description does not compensate for this gap or explain paging semantics at all.
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 ('Get paginated error logs'), which is clearer than a bare name. However, it does not distinguish itself from close siblings like get_log_error_id or get_log_error_source_id, so an agent must infer the difference from the name alone.
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 guidance on when to use this versus get_log_error_id (single error) or the other paginated log endpoints. The only hint is the word 'paginated', which is not framed as an alternative-selection rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get paginated error logs by source and source id. GET /api/v2/log/error/{source}/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Id of the error source | |
| page | Yes | ||
| limit | Yes | Page size, max 100 (larger values are capped to 100) | |
| source | Yes | Error source |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only that results are paginated and the underlying endpoint path; it says nothing about auth needs, rate limits, or ordering. That is a modest but real addition over the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no filler; the paginated-filter scope comes first. The trailing endpoint path is mildly redundant but compact and useful for disambiguation.
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 4-required-parameter read tool with no output schema and solid annotations, the description is adequate but thin: it does not explain the pagination parameters' behavior or what an error log entry contains. Annotations cover safety, so the gap is not severe.
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 75%: source (with a 7-value enum), id, and limit are all described in the schema, and limit's 100 cap is stated there. The description adds no format or semantics beyond 'source and source id', 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?
The description states a specific verb and resource ('Get paginated error logs') and narrows the scope with 'by source and source id', which distinguishes it from the unfiltered get_log_error_paginated and the single-record get_log_error_id. It is clear, though it does not explicitly name those siblings.
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 when-to-use or when-not-to-use guidance, and no alternative tool is named. The scope phrase 'by source and source id' implies the filter, but the agent gets no direction on choosing this over get_log_error_paginated or get_log_error_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get paginated signal logs of a bot hook. GET /api/v2/log/signal/hook/{hookId}/paginated
| Name | Required | Description | Default |
|---|---|---|---|
| page | Yes | ||
| limit | Yes | Page size, max 100 (larger values are capped to 100) | |
| hookId | Yes | Bot hook id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only that results are paginated and restates the HTTP route; it does not disclose pagination defaults, sort order, auth needs, or result shape, so it adds modest value beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the operation and scope. The trailing route string is somewhat redundant with the tool name but does not bloat the description.
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 read-only paginated log endpoint with no output schema, the description covers the bare minimum: what it fetches and that it is paginated. It omits what a signal log entry contains, pagination limits, and ordering, so an agent has enough to call it but not to interpret or page through results confidently.
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 67% (hookId and limit are documented; page is not), so the schema carries most of the load. The description adds no parameter detail at all – no default page size, no page indexing convention – which is acceptable at this coverage but leaves the undocumented 'page' param to inference.
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 (Get) and resource (paginated signal logs of a bot hook), which is precise enough to separate it from the data-log variant (get_log_data_hook_hookId_paginated). However it does not explicitly name or differentiate itself from the other signal-log siblings (get_log_signal_paginated, get_log_signal_source_paginated), leaving the agent to infer the distinction from the resource noun alone.
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 when-to-use guidance, no prerequisites, and no exclusions are given. With several near-identical signal/data log tools in the sibling set, the absence of any routing hint is a real gap, though the resource name implies logging retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get paginated signal logs. GET /api/v2/log/signal/paginated
| Name | Required | Description | Default |
|---|---|---|---|
| page | Yes | ||
| limit | Yes | Page size, max 100 (larger values are capped to 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds no behavioral context beyond that, such as ordering of results, what a page contains, or response shape. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is short and front-loaded, but the second sentence is a bare REST path that conveys little beyond what the tool name already implies. Minimal waste, but also minimal 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 paginated list tool with no output schema and one undocumented parameter, the description should at least clarify what a signal log is and how this endpoint differs from the source/hook variants. Neither is addressed, leaving the agent without enough context to select confidently.
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 50%: the 'limit' parameter is documented (max 100, capped), but 'page' has no description at all. The description text adds nothing about either parameter, so it fails to compensate for the undocumented half.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Get paginated signal logs'), which is clear enough on its own. However, it does not distinguish this tool from several close siblings such as get_log_signal_source_paginated, get_log_signal_source_id_paginated, and get_log_signal_hook_hookId_paginated, leaving the agent to guess which scope of signal logs this returns.
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 when-to-use guidance, no mention of prerequisites, and no mention of alternatives among the signal-log siblings. Usage must be inferred entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get paginated signal logs by source and source id. GET /api/v2/log/signal/{source}/{id}/paginated
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Id of the signal source | |
| page | Yes | ||
| limit | Yes | Page size, max 100 (larger values are capped to 100) | |
| source | Yes | Signal source |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that results are paginated and includes the endpoint, but it does not explain pagination behavior beyond the name or any rate limits, auth requirements, or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero waste. The core purpose is front-loaded, and the endpoint is appended as compact supplemental context.
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 four required parameters, no output schema, and many similar sibling log tools, the definition is adequate but incomplete. It lacks pagination semantics, a description for the page parameter, and any routing guidance among related signal-log endpoints.
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 75%, with limit and source documented reasonably well, while page has no description. The endpoint template clarifies that source and id are path parameters, but the description adds no meaning for page or limit beyond what the schema already provides.
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 gives a specific verb (Get) and resource (paginated signal logs) with a clear scope: by source and source id. It implicitly distinguishes itself from source-only or unfiltered siblings, though it does not name those alternatives explicitly.
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 guidance on when to use this tool versus alternatives such as get_log_signal_paginated or get_log_signal_source_paginated. The description only states what it does, leaving the agent to infer selection criteria from the name and endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get paginated signal logs by source. GET /api/v2/log/signal/{source}/paginated
| Name | Required | Description | Default |
|---|---|---|---|
| page | Yes | ||
| limit | Yes | Page size, max 100 (larger values are capped to 100) | |
| source | Yes | Signal source |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds only the endpoint path and the word 'paginated', with no ordering, auth, rate-limit, or page-indexing behavior 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?
Two short clauses, front-loaded with the purpose and then the endpoint. Nothing redundant or padded; every token serves the reader.
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 paginated listing endpoint, critical invocation details are absent: whether 'page' is 0- or 1-based, default behavior, and what the pagination envelope looks like. Only the enum source and the limit cap are resolvable, and the absence of an output schema means the description could have done more.
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 67%: 'limit' is documented in the schema (max 100, capped) and 'source' has an enum plus label, but 'page' has no description anywhere. The description adds nothing about parameter meaning beyond the implied source filter, so it does not compensate for the 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?
States a specific verb and resource ('Get paginated signal logs') and narrows scope with 'by source', plus the raw endpoint. It is interpretable and roughly distinguishes it from get_log_signal_paginated (all sources), but it never names that sibling or get_log_signal_source_id_paginated, so the differentiation is inferential rather than explicit.
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 when-to-use guidance, no prerequisites, and no mention of the closely related alternatives (get_log_signal_paginated, get_log_signal_source_id_paginated). The agent must infer from the name alone which of the several paginated log endpoints to pick.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get paginated transaction logs. GET /api/v2/log/transaction
| Name | Required | Description | Default |
|---|---|---|---|
| page | Yes | ||
| limit | Yes | Page size, max 100 (larger values are capped to 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds only 'paginated', which tells the agent results come in pages, but omits pagination mechanics, auth requirements, and what a transaction log record represents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the core purpose front-loaded and no padding. The raw endpoint path ('GET /api/v2/log/transaction') is arguably redundant for an agent that only needs the tool name and schema, but the definition remains tight and readable.
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?
With two required parameters, no output schema, and no filtering options documented, the description should explain pagination behavior, expected record content, and any filtering scope. It supplies none of that, so an agent cannot confidently call or interpret this tool beyond knowing it lists paginated transaction logs.
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 50%: 'limit' is documented in the schema (max 100, capped) but 'page' has no description anywhere. The description says nothing about parameters, so it fails to compensate for the undocumented page parameter (e.g. whether paging is 0- or 1-based) or to add 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?
States a specific verb and resource ('Get paginated transaction logs'), which is clear enough for an agent to know this retrieves transaction log entries rather than errors, signals or data logs. However, it does not differentiate from close siblings such as get_log_transaction_id or get_log_transaction_bot_signal_type_service_id, leaving the agent to guess which log family applies.
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 when-to-use guidance, no exclusions, and no mention of the alternative transaction-log tools that return a single record or filter by bot/signal/service. The agent is given no condition that selects this tool over its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get paginated transaction logs of a signal bot. GET /api/v2/log/transaction/bot/signal/{type}/{service}/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Signal bot id | |
| page | Yes | ||
| type | Yes | Exchange type | |
| limit | Yes | Page size, max 100 (larger values are capped to 100) | |
| service | Yes | Exchange service |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered by structured data. The description adds 'paginated', which is useful context, but says nothing about pagination behavior beyond the schema's limit note or about ordering/return 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?
Two short sentences, front-loaded with the purpose. The raw endpoint string is somewhat redundant with the tool name, but it is compact and the whole description is only one line.
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 read-only paginated log fetch with well-described parameters and no output schema, the definition is minimally adequate. It lacks any note on pagination shape (total counts, page indexing) that would help an agent iterate pages 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 80% and enums for type/service are self-documenting, so the baseline is 3. The description only restates that results are paginated; it adds no meaning about the type/service/id path segments beyond what the schema's descriptions already provide.
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 ('Get') and resource ('paginated transaction logs of a signal bot'), and the URL template conveys the scoping by exchange type/service/id. It is distinguishable from the plain get_log_transaction, though it does not explicitly acknowledge that sibling or its counterpart get_log_transaction_id.
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 on when to choose this tool over get_log_transaction, get_log_transaction_id, or the various get_log_signal_* variants. The agent must infer selection from the endpoint path alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a transaction log by id. GET /api/v2/log/transaction/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Transaction log id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered structurally. The description adds only the HTTP route (GET /api/v2/log/transaction/{id}), which is redundant REST metadata rather than behavioral context such as not-found handling 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?
Two short sentences, front-loaded with the purpose and with no filler. The trailing HTTP route is information the agent cannot act on, which is the only waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with full schema coverage and annotations carrying the safety profile, this is minimally adequate. With no output schema, a brief note on what the returned transaction log contains would have closed the remaining 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 100% and the single 'id' parameter is already documented as 'Transaction log id' in the schema. The description restates the same fact ('by id') without adding format, source, or lookup guidance, 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: 'Get a transaction log by id', which is distinct from the sibling list endpoint get_log_transaction and from get_log_transaction_bot_signal_type_service_id. It does not explicitly name those alternatives, so sibling differentiation is left implicit.
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 only usage cue is 'by id', which just restates the single required parameter. There is no guidance on when to use this versus the paginated get_log_transaction listing or the filtered get_log_transaction_bot_signal_type_service_id variant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the full markdown content of a specific documentation page from Sigrex Documentation. Use this when you have a page URL and want to read its content. Accepts full URLs (e.g. https://docs.sigrex.io//getting-started). Since searchDocumentation returns partial content, use getPage to retrieve the complete page when you need more details. The content includes links you can follow to navigate to related pages.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL of the page to fetch |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered for free. The description earns extra credit beyond that by disclosing the return shape (full markdown, in contrast to search results' partial content) and that the content contains followable links for navigation.
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?
Purpose is front-loaded and every sentence carries information (usage, URL format, sibling differentiation, return content). One sentence ('Use this when you have a page URL and want to read its content') mildly restates the opening, which keeps it out of the top band.
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?
With a single required parameter and no output schema, the description covers what an agent needs: what it returns, how it differs from searchDocumentation, and the URL form to supply. Nothing essential is missing; only error/edge behavior (e.g. bad URL) is unaddressed, which is minor here.
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?
Only one parameter and schema description coverage is 100%, so the schema already documents `url`. The description adds marginal value by noting full URLs are accepted and supplying a concrete example format, but this is close to restating 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?
States a specific verb and resource ('Fetch the full markdown content of a specific documentation page') and immediately scopes it to 'Sigrex Documentation'. It is clearly separable from the many get_* CRUD siblings, none of which touch documentation pages.
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 trigger ('when you have a page URL and want to read its content') and an explicit alternative plus the condition that selects it: use searchDocumentation for discovery, getPage when its partial content is insufficient. That is real routing, not implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get public code reaction
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered by structured data. The description adds nothing beyond that — no note on whether a missing id errors or returns empty, no auth or visibility constraints on 'public' content.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single short sentence with no padding, but it is under-specified rather than concise — the sentence carries no load-bearing information beyond the tool name, so brevity here reflects missing content, not efficiency.
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?
With no output schema and an undocumented required parameter, the description would need to explain the id's meaning and the return shape. It does neither, and it omits the by-id versus list distinction that the sibling set makes necessary.
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 single parameter 'id' is required but has no schema description (0% coverage), and the description does not compensate by stating that the id identifies a specific public code reaction. The agent is left to guess whether this is a reaction id, code id, or strategy 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?
The description restates the tool name almost verbatim ('Get public code reaction' for get_public_code_reaction) with no additional specificity about what a 'code reaction' is or what is returned. It does not distinguish this by-id lookup from the sibling list_all_public_code_reaction or from get_public_llm_reaction.
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 when-to-use guidance is given, no prerequisites, and no mention of alternatives. The presence of list_all_public_code_reaction and get_public_code_strategy makes the omission notable — an agent cannot tell from the text why it would pick this tool over the list variant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get public code strategy
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that: it does not disclose return format, id semantics, rate limits, or any behavioral nuance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, but it is under-specified rather than concise. It is front-loaded but does not earn its place by providing actionable information beyond the name.
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 getter with one parameter, no output schema, and read-only annotations, the description is still inadequate. It omits what entity is being retrieved, the meaning of the id, and any relationship to the list_all_public_code_strategy sibling.
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 0% and the single required parameter 'id' has no description. The description does not mention the parameter at all, failing to compensate for the missing schema documentation and leaving the agent unsure what the id refers to.
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 is a verbatim restatement of the tool name, merely reformatting 'get_public_code_strategy' into sentence case. It does not clarify what a 'public code strategy' is or how it differs from siblings like get_strategy_code_id or list_all_public_code_strategy. This is a tautology with no added specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No indication of when to use this tool versus alternatives such as get_strategy_code_id or list_all_public_code_strategy. No prerequisites, no context, and no routing guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get public llm reaction
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered structurally. The description adds nothing beyond that – no return shape, no scope, no side behaviors – so it contributes no behavioral value over the structured fields.
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 text is very short, but this is under-specification rather than genuine conciseness. It is a bare phrase with no front-loaded scope, qualifier, or actionable 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?
With no output schema, no annotation detail, and an undocumented parameter, the definition leaves the agent without what it needs to call the tool correctly. Given the dense, similarly-named sibling set, the description is far too thin to be 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?
There is one required parameter 'id' with 0% schema description coverage, and the description says nothing about it. It is unclear whether this id refers to a reaction, a session, a strategy, or a user, so the description fails to compensate for the schema 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 'Get public llm reaction' is essentially a restatement of the tool name, adding no specific verb nuance or scope. It does not distinguish this from the many siblings such as list_all_public_llm_reaction, get_public_code_reaction, or get_public_llm_session, leaving the agent unable to tell what 'reaction' means here.
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 when-to-use guidance, no prerequisites, and no mention of any alternative tool. An agent cannot infer whether this fetches a single reaction, a reaction set, or when to prefer list_all_public_llm_reaction instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get public llm sessions
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that – no note on whether the session must be public, whether it returns 404 for private sessions, or any auth requirement.
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 words with no filler and no buried information, so nothing is wasted. However, the brevity borders on under-specification for a retrieval tool with an undocumented required parameter rather than being efficiently minimal.
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?
With no output schema and an undocumented parameter, the description should explain what a returned session contains or how the id is obtained. It provides none of that, leaving the agent unable to call the tool correctly beyond guessing that `id` is a session identifier.
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 0% for the single required `id` parameter, so the description carries the full burden. It merely implies the id refers to a session but never states the id type, source, or what qualifies a session as "public", leaving the parameter effectively undocumented.
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 "Get public llm sessions" essentially restates the tool name without adding scope or verb specificity. It also conflicts subtly with the schema, which requires a single numeric `id`, while the description uses the plural "sessions". An agent cannot tell from this text how it differs from the sibling `list_all_public_llm_session`.
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 when-to-use guidance and no mention of alternatives, despite several closely related siblings (`list_all_public_llm_session`, `get_strategy_llm_session_id`). The agent is left to infer that this retrieves a single session by id purely from the required parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all code strategies. GET /api/v2/strategy/code
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile needs no restating. Beyond that the description adds only the raw endpoint path and nothing behavioral – no result count, pagination, or ordering information that would help an agent anticipate the response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no filler. The endpoint path is arguably redundant for invocation, but it costs almost nothing and aids doc cross-referencing.
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?
With no output schema and no parameters, the description carries the full burden of explaining what comes back, and it does not say what a 'code strategy' record contains or whether the list is paginated. Adequate for invocation, incomplete for understanding 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?
The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get all code strategies'), and 'all' implies an unfiltered list, which separates it from get_strategy_code_id and get_strategy_code_total. It does not explicitly name those siblings or the near-duplicate list_all_public_code_strategy, so it falls 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?
Usage is only implied by the word 'all' – an agent can infer this is the bulk-listing variant, but there is no explicit when-to-use versus get_strategy_code_folder or get_strategy_code_id, and no stated prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all code strategy folders. GET /api/v2/strategy/code/folder
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds only the REST endpoint path and the fact that a full collection is returned; it says nothing about result shape, ordering, or whether the list is flat or tree-structured.
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 terse fragments, purpose front-loaded, nothing padded. The trailing 'GET /api/v2/strategy/code/folder' is marginally redundant for an agent but costs little.
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 no-arg listing tool the description is minimally adequate, but with no output schema it leaves the return structure undefined and does not clarify how the result differs from the _id and _root variants. Enough to call correctly, not enough to use confidently.
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 of 4 applies. The description implies an unfiltered full-collection read, which is consistent with the empty 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 clear verb (get) plus resource (code strategy folders) and the scope 'all', which implicitly separates it from siblings like get_strategy_code_folder_id (single item) and get_strategy_code_folder_root (root only). It does not, however, name or explicitly contrast those siblings, so an agent must infer the boundary.
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 when-to-use guidance and no mention of alternatives, despite a dense cluster of adjacent tools (get_strategy_code_folder_id, get_strategy_code_folder_root, get_strategy_code_total). The agent gets no signal about which retrieval variant to pick.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get code strategy folder by ID. GET /api/v2/strategy/code/folder/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Folder ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds nothing beyond that — no note on what happens for an unknown ID, no indication of the returned folder shape, and no filtering/permission 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?
Two short sentences, front-loaded with the purpose and then the underlying HTTP endpoint. Efficient, though the raw route path is largely redundant with the tool name and annotations.
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 read tool with annotations covering safety, this is minimally adequate. It still leaves the agent unable to tell when to pick this folder-by-ID call over the folder list/root siblings, which is the main decision the description should resolve.
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% with a single 'id' parameter documented as 'Folder ID', so the schema already does the work. The description only implies the path-based lookup and adds no format, sourcing, or example detail beyond the schema baseline.
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 ('Get code strategy folder by ID'), so the agent knows it retrieves a single code-strategy folder rather than a list. However, it never distinguishes itself from near-identical siblings such as get_strategy_code_folder (list), get_strategy_code_folder_root, or get_strategy_reaction_code_folder_id; only the '_id' in the name and the phrase 'by ID' carry that 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?
There is no when-to-use guidance, no prerequisite (e.g. needing a known folder ID), and no mention of alternatives like the list or root variants. The agent must infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get code strategies from root folder. GET /api/v2/strategy/code/folder/root
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so safety is covered. The description adds nothing beyond that and the endpoint path; it does not say whether the listing is recursive or root-level only, nor anything about result size or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short clauses, front-loaded with the action and resource. The trailing 'GET /api/v2/strategy/code/folder/root' restates information already carried by the name and adds little, but it is not costly.
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 with no output schema, the description is minimally adequate. It leaves open the key ambiguity of what 'root' returns (recursive vs. top level) and nothing about the shape or volume of 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?
The tool takes zero parameters, so the baseline is 4. There is nothing parameter-related the description could or should explain.
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 ('Get code strategies from root folder'), and the 'root folder' scope is meaningful next to siblings like get_strategy_code_folder_id. However, it does not distinguish itself from get_strategy_code_folder or explain what 'root' means relative to the full folder tree.
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 indication of when to use this versus get_strategy_code_folder, get_strategy_code_folder_id, or the reaction/LLM variants. The agent is left to infer selection purely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get code strategy by ID. GET /api/v2/strategy/code/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. Beyond that, the description adds nothing — no behavior on missing/invalid IDs, no auth requirements, and no indication of return contents, which matters since there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short clauses with the purpose front-loaded and no filler. The appended raw HTTP path is mildly redundant but harmless and may aid mapping to the API.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter getter with safety annotations, the description covers the core intent. However, with no output schema and 0% parameter documentation, it leaves the agent without any notion of what a successful response contains.
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% and the single 'id' parameter is undocumented. The phrase 'by ID' merely restates that the resource is identified, giving no format, source, or validation hints for the ID value.
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: fetch a code strategy by its ID. It distinguishes the single-item fetch from list-style siblings like get_strategy_code and get_strategy_code_total only implicitly, but the intent 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?
There is no guidance on when to use this over siblings such as get_strategy_code (list) or get_public_code_strategy, and no prerequisites or error conditions are mentioned. The agent must infer usage purely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the total number of Code Strategies. GET /api/v2/strategy/code/total
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and a closed world, so the safety profile is covered. The description adds only the HTTP endpoint path; it does not clarify the scope of the count (all strategies vs. the caller's own), which is the main behavioral question here.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no filler. The purpose comes first and the endpoint detail follows.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless count call whose annotations cover safety, the definition is minimally sufficient, but with no output schema it doesn't indicate what the returned total represents or its scope. Minor gap, not a blocker.
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 document; the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Get') and resource ('total number of Code Strategies'), making the operation unambiguous. It doesn't explicitly distinguish itself from the many other *_total siblings (e.g. get_strategy_llm_session_total, get_strategy_reaction_code_total), but the resource naming is clear enough not to confuse them.
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 when-to-use or when-not-to-use guidance is given. For a trivial count endpoint the usage is implied (call it to obtain a count rather than fetching full lists), but the description leaves the agent to infer that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all LLM sessions. GET /api/v2/strategy/llm-session
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered by structured data. The description adds nothing beyond that: no pagination behavior, no scope of 'all' (own vs public vs every user), no auth or rate-limit notes, and no return-shape hint despite there being no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very short and front-loaded, but the second fragment ('GET /api/v2/strategy/llm-session') is redundant with the tool name and adds no decision-relevant information. Brevity here reflects under-specification rather than efficient conciseness.
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 no-param collection reader with annotations covering safety, the definition is minimally viable. But with no output schema and no mention of pagination or what 'all' covers, an agent is left guessing the result shape and scope in a very crowded namespace.
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; the baseline for a no-param tool is 4. The trailing HTTP path is redundant rather than informative.
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 ('Get all LLM sessions'), and the word 'all' hints at a collection-level listing rather than a single-item fetch. However, it never distinguishes itself from close siblings such as get_strategy_llm_session_id, get_strategy_llm_session_total, get_strategy_llm_session_folder, or list_all_public_llm_session, so an agent cannot tell scope or ownership from the text alone.
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 when-to-use guidance, no exclusions, and no pointer to alternatives. With roughly 200 siblings including several LLM-session readers (by id, by folder, totals, public variants), the absence of routing guidance is a real gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all LLM session folders. GET /api/v2/strategy/llm-session/folder
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond the name — it does not disclose whether the response is paginated, whether it includes nested folders, or how a 'flat list of all folders' relates to the folder tree.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the purpose. The second sentence is a raw endpoint restatement that adds little beyond the path, but it is not wasteful enough to penalize below 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no params, no output schema, safety covered by annotations), but the description omits the one thing that matters here: how the returned 'all folders' set relates to the sibling folder_root and folder_id tools, and whether the result is flat or hierarchical.
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 for a parameterless listing endpoint.
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 clear verb+resource combination ('Get all LLM session folders'), which an agent can act on. However, it does not distinguish itself from two near-identical siblings, get_strategy_llm_session_folder_root and get_strategy_llm_session_folder_id, leaving ambiguity about whether this returns a flat list, the root, or a tree.
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 on when to call this versus the sibling folder tools (folder_root, folder_id). The 'all' phrasing implies a listing scope, but no alternatives or conditions are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get LLM session folder by ID. GET /api/v2/strategy/llm-session/folder/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Folder ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only the raw HTTP path and no behavioral context such as error handling, what a missing ID returns, or any auth requirements, so it contributes little beyond structured fields.
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 terse fragments, front-loaded with the operation and scoped by ID. No filler, though the endpoint string is arguably redundant given the tool name.
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 single-parameter read with no output schema and annotations covering safety, the definition is minimally adequate. It omits any indication of what the folder object contains or whether the call can fail, but nothing critical to 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?
There is a single required parameter with 100% schema description coverage ('Folder ID'), so the schema carries the semantics. The description's 'by ID' adds nothing beyond the schema, which is the expected baseline-3 case when coverage is high.
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 (get) and resource (LLM session folder) scoped by ID, and the endpoint path reinforces it. It is clear what the tool fetches, though it does not explicitly differentiate from close siblings like get_strategy_llm_session_folder (list) or get_strategy_llm_session_folder_root, relying on the name alone.
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 guidance on when to use this versus the sibling folder tools (get_strategy_llm_session_folder, get_strategy_llm_session_folder_root, get_strategy_llm_session_id). The description only echoes the resource and endpoint, leaving selection entirely to the reader.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get LLM Sessions from root folder. GET /api/v2/strategy/llm-session/folder/root
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds only the raw endpoint path and no further behavior such as pagination, result ordering, or empty-root handling, so it clears the lower bar without adding much.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the purpose. The second sentence is largely a restatement of the HTTP route, which is redundant but takes little space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read tool with no output schema, the description need not explain return values, and it does convey what is fetched and from where. The residual gap is that it doesn't say whether the root listing is recursive or how it relates to the sibling folder tools.
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; the baseline for a parameterless tool is 4.
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 ('Get LLM Sessions') and scopes it to the root folder, which separates it from the id-based sibling get_strategy_llm_session_folder_id. It does not explicitly contrast with get_strategy_llm_session or get_strategy_llm_session_folder, so the agent must infer whether this returns sessions or a folder object.
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 when-to-use vs. when-not-to-use guidance and no named alternatives, despite a dense set of sibling list/folder tools (get_strategy_llm_session, get_strategy_llm_session_folder, get_strategy_llm_session_folder_id). The 'root folder' scope is the only signal an agent has for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get LLM session by ID. GET /api/v2/strategy/llm-session/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered externally. The description adds only the REST route, which is redundant metadata rather than behavioral context — nothing about ownership/access requirements, whether a missing ID errors versus returning empty, or what the session payload 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?
Two short fragments, front-loaded with the action, with no filler. The appended HTTP path is marginally useful for humans but is largely redundant with the tool name.
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 lookup tool with zero schema descriptions and no output schema, the description leaves too much open: no indication of the returned session shape, no ID format, no access constraints. It is callable but under-specified.
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 0% on the single 'id' parameter, so the description must carry the load. Phrasing it as 'by ID' does establish that the argument identifies the LLM session specifically (rather than a user or folder), which is meaningful, but no format, source, or constraint is given.
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 verb and resource ('Get LLM session by ID'), so the operation is unambiguous. It does not, however, differentiate itself from close siblings such as get_strategy_llm_session (list), get_public_llm_session, or get_strategy_llm_session_folder_id, which matters in a namespace this crowded.
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 when-to-use guidance, no statement of prerequisites, and no mention of alternatives. The agent is left to infer that this is the single-item fetch versus the list-oriented sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the total number of LLM sessions. GET /api/v2/strategy/llm-session/total
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only the endpoint path and confirms aggregate-count semantics, disclosing nothing about scope (per-user vs global), auth needs, or the shape of the returned number.
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?
One declarative sentence with the purpose front-loaded, plus a compact endpoint path. Well sized, though the raw path is largely redundant with the tool name.
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 count endpoint with annotations covering the safety profile and no output schema, the description is sufficient. The main residual gap is that 'total' is not defined in scope terms (global vs filtered), which an agent might need to interpret the number 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?
The tool takes zero parameters, so the schema has nothing to document and the baseline is 4. No parameter meaning is needed or missing.
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: it counts LLM sessions (aggregate total), which is distinguishable from the listing sibling get_strategy_llm_session by the word 'total'. It does not explicitly name or contrast with that sibling, so it falls 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?
Usage is implied by the aggregate-count semantics ('total'), which suggests calling it when a count rather than a list is needed, but the description never says when to prefer it over get_strategy_llm_session or whether any scoping/filtering applies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all code reactions. GET /api/v2/strategy/reaction/code
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds only the HTTP route string, providing no behavioral detail on pagination, scoping, or result shape that the annotations don't already imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short fragments with the purpose front-loaded; nothing is padded. The trailing 'GET /api/v2/strategy/reaction/code' is low-value for an agent but costs little.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool with covered annotations and no output schema, the description is minimally viable but leaves the critical distinction unresolved: whether this returns the caller's own strategy code reactions versus the public ones exposed by list_all_public_code_reaction. That scope question is the main thing an agent needs here.
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 has no properties, so per the baseline there is nothing for the description to clarify. It does not misuse or misstate any parameter space.
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 verb and resource ('Get all code reactions'), but omits the 'strategy' scoping that its own name carries and never distinguishes it from close siblings like get_strategy_reaction_code_id, get_strategy_reaction_code_total, or list_all_public_code_reaction. An agent can infer this is a list endpoint, but 'all' is ambiguous about whose reactions are returned.
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 when-to-use guidance at all. With ~10 sibling reaction/strategy tools (single-id getters, public lists, totals, folders), the description never says when this collection getter should be chosen over them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all code reaction folders. GET /api/v2/strategy/reaction/code/folder
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds only the raw endpoint path, no details on return shape, pagination, or folder hierarchy, so it contributes little beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short fragments with the purpose front-loaded, no wasted prose. The trailing 'GET /api/v2/...' path is largely redundant with the name but costs little.
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 zero-argument list endpoint with annotations covering safety and no output schema, the description is minimally adequate. It still omits whether results are hierarchical, paginated, or scoped to the authenticated user, which matters when several folder-listing siblings exist.
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. Schema coverage is a nominal 100% with an empty properties object.
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 clear verb and resource ('Get all code reaction folders'), so an agent knows it is a listing operation. However, it never distinguishes itself from close siblings such as get_strategy_reaction_code_folder_root, get_strategy_reaction_code_folder_id, or get_strategy_code_folder, leaving the exact folder scope ambiguous.
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 on when to use this versus the *_folder_root, *_folder_id, or get_strategy_reaction_code_total siblings, and no prerequisites are stated. The agent must infer context purely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get code reaction folder by ID. GET /api/v2/strategy/reaction/code/folder/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Folder ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered elsewhere. The description adds nothing beyond restating the resource and echoing the HTTP route, so it contributes no behavioral context (no auth requirements, no return shape, no error 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?
Two short, front-loaded sentences with no filler. The raw endpoint path is mildly redundant given the annotations, but it is compact and does not obscure the 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?
For a simple single-parameter read tool whose annotations and schema are complete and which has no output schema, the description covers what an agent needs to invoke it. The remaining gap is sibling disambiguation, which matters given the crowded folder-tool family.
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?
With one parameter at 100% schema description coverage ('Folder ID'), the schema already carries the meaning. The description's 'by ID' adds nothing beyond what the schema documents, 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 ('Get code reaction folder by ID'), so an agent knows this is a single-folder fetch keyed by identifier. However, it does not distinguish this from the closely named siblings get_strategy_reaction_code_folder and get_strategy_reaction_code_folder_root, leaving the agent to infer the difference from the name alone.
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 on when to use this versus the base folder listing or the root-folder variant. The only cue is the 'by ID' phrasing, and no prerequisites or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get code reactions from root folder. GET /api/v2/strategy/reaction/code/folder/root
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered elsewhere. The description adds nothing behavioral beyond the endpoint URL: no pagination behavior, no return shape, no folder-depth semantics.
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, front-loaded fragments with no filler. The second sentence is essentially the raw HTTP path, which duplicates the name rather than adding information, keeping it just short of 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 annotations covering safety, the essentials are present, but there is no output schema and the description never explains what a 'code reaction' is or what the root-folder listing contains. The agent has enough to call it, but not enough to predict 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?
The tool takes zero parameters, so there is nothing for the description to clarify and the baseline of 4 applies. No parameter information is missing because none exists.
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 verb (Get) and a resource (code reactions from root folder), but the phrase largely restates the tool name itself. It does not differentiate this root-folder variant from close siblings such as get_strategy_reaction_code_folder or get_strategy_reaction_code_folder_id, so an agent still has to 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?
There is no when-to-use guidance, no conditions or prerequisites, and no mention of alternatives. The only hint of scope is the word 'root', which the agent must interpret against a large family of folder/code/total siblings on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get code reaction by ID. GET /api/v2/strategy/reaction/code/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that: it restates the HTTP verb/path and says nothing about permissions, error behavior when the ID is unknown, or what the fetched reaction 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?
Two terse fragments with the core action front-loaded and zero padding. The brevity is appropriate, though the second fragment merely echoes the REST path rather than adding agent-relevant 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?
With no output schema and no indication of the returned record's shape, the description is incomplete for an agent needing to consume the result. It also fails to disambiguate the tool from a large cluster of similarly named get_*_id siblings.
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% for the single `id` parameter, so the description must compensate. 'By ID' does indicate the identifier selects a code reaction, but gives no format (UUID, numeric, slug) or source for obtaining the ID, so it only marginally exceeds the bare 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 (Get) and resource (code reaction) scoped by ID, which distinguishes it from the list-style sibling get_strategy_reaction_code. However, it never differentiates itself from the many near-identical siblings such as get_strategy_reaction_llm_id, get_strategy_code_id, or get_public_code_reaction, leaving the 'strategy reaction code' domain ambiguous.
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 when-to-use guidance, no prerequisites, and no named alternatives. The agent must infer from the name alone that this is the single-record fetch counterpart to get_strategy_reaction_code and get_strategy_reaction_code_total.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the total number of Code Reactions. GET /api/v2/strategy/reaction/code/total
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only the REST endpoint path, with no rate limits, auth requirements, or scoping context, so it barely exceeds the annotation baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the purpose front-loaded. The second sentence is only a REST path, which is marginally useful for an agent, 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?
For a simple zero-parameter count tool this is nearly adequate, but with no output schema the description could at least confirm the return value (a number) and clarify what 'Code Reactions' totals are counted over. The scope of the count is left ambiguous.
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 per the rubric the baseline is 4; there is nothing for the description to disambiguate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Get the total number of Code Reactions'), and the word 'total' distinguishes it from the sibling list-style tool get_strategy_reaction_code. It does not explicitly name that sibling, but an agent can infer the count-vs-list 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?
There is no when-to-use guidance, no mention of alternatives, and no indication of scope (e.g. whether the total is user-scoped or global). Usage is only implied by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all LLM reactions. GET /api/v2/strategy/reaction/llm
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds nothing behavioral beyond that — no note on whether results are scoped to the caller, whether they are paginated, or how large the response may be. The API route text adds no behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action and free of filler. The second sentence is only the raw HTTP route, which is of limited value to an agent but costs almost nothing.
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?
Annotations cover the safety profile and there are no parameters or output schema to explain, so the burden is light. Still, the description omits result scope (own vs. public reactions), pagination behavior, and any differentiation from _total and _id siblings, which an agent listing reactions would need.
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 trivially complete (100% coverage), so there is nothing for the description to disambiguate. Baseline of 4 for a no-parameter tool 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 states a verb and resource ("Get all LLM reactions"), so the basic action is identifiable. However, it does not clarify scope against close siblings such as get_strategy_reaction_llm_id, get_strategy_reaction_llm_total, get_strategy_reaction_llm_folder, or the public variants (get_public_llm_reaction, list_all_public_llm_reaction), leaving "all" ambiguous.
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 use this tool versus alternatives, no prerequisites, and no routing guidance. The agent must infer from the name alone that this is the unfiltered list endpoint and that _total / _id / _folder siblings serve different needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all LLM reaction folders. GET /api/v2/strategy/reaction/llm/folder
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds nothing behavioral beyond restating the endpoint path – no mention of return shape, ordering, or pagination for this list 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?
Two short sentences with the purpose front-loaded and no padding. The endpoint path is arguably redundant but not harmful.
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 could have stated what a folder list returns, but for a trivial parameterless read tool with safety annotations the minimal description is roughly adequate rather than rich.
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; the baseline of 4 applies for a parameterless tool.
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 (Get) and resource (LLM reaction folders) plus the endpoint path. 'All' distinguishes it from the single-resource sibling get_strategy_reaction_llm_folder_id, but it never explicitly names sibling alternatives like folder_root.
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 when-to-use guidance, no prerequisites, and no routing away from the closely related siblings get_strategy_reaction_llm_folder_id and get_strategy_reaction_llm_folder_root. The agent must infer usage purely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get LLM reaction folder by ID. GET /api/v2/strategy/reaction/llm/folder/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Folder ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, covering the safety profile. The description adds only the raw endpoint path 'GET /api/v2/strategy/reaction/llm/folder/{id}', which is essentially a restatement of the name and discloses nothing new (no return shape, no error or not-found 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?
Two short sentences, front-loaded with the purpose before the endpoint. Nothing is padded, though the endpoint clause is low-value filler rather than earning 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 single-parameter read lookup with annotations covering safety and no output schema, the description is minimally sufficient. It still omits any differentiation from the sibling folder/root variants and any indication of what is returned, so it is adequate but not 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% and the single 'id' parameter is documented as 'Folder ID' in the schema. The description adds no format, ID-type, or sourcing detail beyond that, 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 ('Get LLM reaction folder by ID'), so the agent knows it retrieves a single folder entity. However, it never distinguishes itself from near-identical siblings like get_strategy_reaction_llm_folder or get_strategy_reaction_llm_folder_root, leaving the agent to infer the difference from names alone.
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 when-to-use guidance, no prerequisite (e.g. needing an existing folder ID), and no mention of alternatives. The description only restates what the tool fetches, so the agent gets no routing help among the many folder-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get LLM reactions from root folder. GET /api/v2/strategy/reaction/llm/folder/root
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that: no pagination behavior, no indication of what a 'root folder' response contains, and no note on volume or ordering. The REST path is a restatement, not new behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the purpose front-loaded. The trailing 'GET /api/v2/...' path is largely redundant for an agent choosing a tool, but it consumes little space and does no harm.
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 annotations covering its safety profile, the essentials are present. However, with no output schema, the description's phrase 'Get LLM reactions from root folder' is ambiguous about whether it returns reaction records, folder entries, or a folder tree — and that ambiguity is unresolved by anything else in the definition.
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 no parameters and the schema coverage is 100%, so there is nothing to document. Baseline 4 applies; the description neither helps nor hurts here.
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 ('Get LLM reactions from root folder'), which is more precise than the bare tool name. It doesn't explicitly contrast itself with the near-identical siblings get_strategy_reaction_llm_folder or get_strategy_reaction_llm_folder_id, so the agent must infer that 'root' means the top of the folder tree rather than a folder addressed by ID.
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 when-to-use guidance, no mention of the sibling tools that fetch folders by ID or list all folders, and no indication of when the root listing is preferable. The usage is only weakly implied by the phrase 'root folder'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get LLM reaction by ID. GET /api/v2/strategy/reaction/llm/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only the HTTP endpoint path, and says nothing about what a 'reaction' contains, error behavior, or auth requirements. With annotations doing the heavy lifting, a 3 is fair.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no filler. It is appropriately sized for a simple lookup, though the raw endpoint string adds little beyond the natural-language sentence.
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 read tool with annotations covering safety and no output schema, the description is minimally adequate. It is missing any notion of what an 'LLM reaction' is or how the ID is obtained, which would help an agent confirm it is calling the right tool.
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 0% – the single 'id' parameter has no description. The phrase 'by ID' hints that the parameter is a resource identifier, but gives no format (UUID, slug, numeric) or constraints. For a 0%-coverage parameter, the description fails 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?
States a specific verb+resource ('Get LLM reaction') plus the retrieval scope ('by ID'), which distinguishes it from the sibling list tool get_strategy_reaction_llm. It does not explicitly name or contrast with siblings, so it falls 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 when-to-use guidance, no prerequisites, and no mention of alternatives such as get_strategy_reaction_llm (list) or get_public_llm_reaction. The agent must infer the selection criteria entirely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the total number of LLM Reaction. GET /api/v2/strategy/reaction/llm/total
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds the meaningful detail that the operation returns a total number (a count), which is not conveyed by annotations alone, but offers no further behavioral context such as auth requirements or rate limits.
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 purpose in the first sentence. The second sentence repeats the operation as an HTTP path, which is redundant for an agent and does not earn its place, but the overall response remains short and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only count endpoint with no output schema, the description is nearly sufficient: it names the resource and indicates the return type is a total number. The main gap is scope ambiguity (what exactly is being counted), but the tool name and sibling context help mitigate this.
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 per the rules the baseline is 4. There are no parameter semantics to document, and the empty schema is fully covered.
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 ('Get') and resource ('total number of LLM Reaction'), making clear it is a count endpoint distinct from siblings like get_strategy_reaction_llm. However, it never explicitly names the alternative list sibling or clarifies scope (e.g., global vs. authenticated user).
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 no when-to-use guidance, prerequisites, or alternatives. The description is a bare operation statement; an agent must infer from the name alone that this is for counting rather than listing reactions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a crypto or altcoin symbol price
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Coin symbol (e.g. BTCUSDT, ETHUSDT, etc.) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds nothing behavioral beyond that: no indication of whether the price is realtime or delayed, spot or futures, the quote currency, or any rate/latency behavior for an open-world network call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler or repetition. It is efficient, though its brevity borders on under-specification for the questions an agent will actually have.
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 the description carries the burden of describing the return value — it says nothing about the shape of the result (price value, currency, timestamp, source). For a one-parameter open-world market-data tool with an ambiguous data source, this leaves real gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% — the single 'symbol' parameter is fully documented with format examples (BTCUSDT) and length constraints. The description reinforces the domain ('crypto or altcoin symbol') but adds no format, casing, or quote-currency detail beyond the schema. 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 concrete verb ('Get') and resource ('symbol price') with scope covering crypto/altcoin. It is implicitly distinguishable from siblings, which are all CRUD operations on signals, strategies, webhooks, and API configs — nothing else returns market prices. However, it names no sibling or boundary, so full 5 is not earned.
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 when-to-use guidance, no prerequisites, and no alternatives mentioned. The agent is left to infer that this is a live spot-price lookup versus any other price-related capability, and there is no note about which market/exchange the price is drawn from.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all bot webhooks. GET /api/v2/webhook/bot
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only the 'all' scope and the raw endpoint path; it says nothing about pagination, filtering, or result size for a collection endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two terse clauses, front-loaded with the action. The endpoint path is somewhat redundant developer-facing detail, 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?
For a zero-argument read-only list tool with annotations covering safety, the description is minimally sufficient. It leaves unclear whether the 'all' result is paginated or how large it may be, which matters for a collection fetch.
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 schema coverage is 100%, so per the rubric the baseline is 4. There is nothing further for the description to clarify about 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 clear verb+resource ('Get all bot webhooks'), and the plural 'all' signals an unfiltered collection fetch, distinguishing it from the many by-id and shared siblings like get_webhook_bot_id. It stops short of explicitly contrasting with those siblings, so a 5 isn't earned.
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 when-to-use or when-not-to-use guidance is provided. Given ~15 sibling webhook tools (get_webhook_bot_shared, get_webhook_bot_id, get_webhook_bot_bot_signal_id_cex, etc.), an agent gets no help choosing among them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get CEX signal bots for webhook. GET /api/v2/webhook/bot/bot/signal/{id}/cex
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| page | Yes | ||
| limit | Yes | Page size, max 100 (larger values are capped to 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered externally. The description adds nothing beyond restating the operation and repeating the HTTP path — no pagination behavior, no scoping, no note on what the id represents — so it contributes little behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is short and front-loaded, but the brevity reflects under-specification rather than economy; the second fragment ('GET /api/v2/webhook/bot/bot/signal/{id}/cex') merely restates information already conveyed by the tool name.
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?
With three required parameters, one-third schema coverage, and no output schema, the description should carry more weight. Instead it omits what the 'id' refers to, how pagination works, and what the return shape is, leaving an agent without enough to invoke it confidently.
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 'limit' is documented as capped at 100). The description says nothing about 'id' (the webhook bot signal identifier) or 'page', so it fails to compensate for the undocumented required parameters. Baseline for low coverage requires the description to fill the gap, and it does not.
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 ('Get') and resource ('CEX signal bots for webhook'), and the term 'CEX' implicitly distinguishes it from the sibling tools get_webhook_bot_bot_signal_id_dex and get_webhook_bot_bot_signal_id_prediction. It is clear what is retrieved, though the phrasing is terse and the trailing REST path adds no meaning beyond the name.
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 its close siblings (_dex, _prediction). The CEX/dex/prediction family is implied by naming, but the description never names an alternative or states a selecting condition, leaving routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get DEX signal bots for webhook. GET /api/v2/webhook/bot/bot/signal/{id}/dex
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| page | Yes | ||
| limit | Yes | Page size, max 100 (larger values are capped to 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds nothing beyond the raw REST path — no pagination behavior, no statement of what the list contains, no capping notes (that detail lives in the schema, not the description).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no padding. The appended endpoint path largely duplicates the tool name and required params rather than earning its place, so concision is fine but not maximally purposeful.
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?
Three required parameters, two of them undocumented anywhere, no output schema, and no behavioral description. For a paginated lookup tool this leaves real gaps: what a page returns, ordering, and the meaning of the id are all 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?
Schema coverage is only 33% (only 'limit' is documented, with its cap noted in the schema). The description adds no meaning for 'id' or 'page' and does not compensate for the two undocumented required parameters, so it fails the low-coverage expectation.
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 ('Get') and resource ('DEX signal bots for webhook'), and the DEX qualifier implicitly separates it from the cex/prediction siblings. However, nothing in the text explicitly contrasts it with get_webhook_bot_bot_signal_id_cex or ..._prediction, so the agent must infer the distinction from the name alone.
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 when-to-use guidance, no mention of prerequisites (a webhook bot id), and no reference to alternative tools. The only usage signal is the implied 'GET' semantics, which the annotations already convey.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get prediction signal bots by webhook ID. GET /api/v2/webhook/bot/bot/signal/{id}/prediction
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| page | Yes | ||
| limit | Yes | Page size, max 100 (larger values are capped to 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds nothing behavioral beyond restating the endpoint path, which is redundant with the name; no pagination behavior, result shape, or scope context is 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?
Very short and front-loaded, with the core purpose stated first. The trailing HTTP path is redundant with the tool name and adds no value, but overall there is little bloat.
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 paginated read tool with no output schema and 33% parameter coverage, the description omits pagination semantics, result content, and the id format. Annotations cover safety, but the functional gaps leave the agent under-informed about how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (only 'limit' is documented in the schema), so the description should compensate but does not. 'by webhook ID' weakly implies the 'id' parameter, but 'page' is left entirely unexplained in both schema and description.
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 ('Get prediction signal bots by webhook ID'), and the 'prediction' qualifier implicitly separates it from the cex/dex siblings. Clear enough that an agent can identify it, though it never names the sibling variants explicitly.
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 when-to-use guidance, no mention of when to prefer this over get_webhook_bot_bot_signal_id_cex/dex, and no note about pagination expectations. The agent gets a resource description but no routing logic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get bot webhook by ID. GET /api/v2/webhook/bot/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so safety is covered. The description adds only the raw HTTP path, which is endpoint trivia rather than behavioral context (no auth requirements, error behavior, or scope). It contributes essentially nothing beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the purpose front-loaded and no padding. The endpoint path sentence is low-value but 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 simple single-parameter read tool whose annotations already cover the safety profile, this is close to sufficient. The remaining gap is disambiguation from the large family of sibling webhook getters, which the description never addresses.
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 carries the burden for the single 'id' parameter. 'by ID' does signal that the parameter is an identifier of a bot webhook, which is marginal added meaning, but it gives no format, source, or constraints.
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 ('Get') and resource ('bot webhook') qualified by 'by ID', which is clearer than the bare tool name. It does not, however, differentiate itself from the many sibling webhook getters (e.g. get_webhook_bot_id_shares, get_webhook_bot_bot_signal_id_cex) that also operate on a webhook bot.
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 guidance on when to use this versus get_webhook_bot (the list variant) or the sub-resource getters. The agent must infer the single-record-vs-collection distinction from the 'by ID' phrasing alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all data webhooks. GET /api/v2/webhook/data
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds only the raw endpoint path and nothing about scope, pagination, or what the returned webhook objects contain, so it contributes little behavioral context beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no filler. The endpoint path is arguably redundant with the name but is a compact piece of extra routing context, so nothing meaningfully wastes space.
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 no-argument listing tool with annotations covering safety and no output schema, the definition is minimally adequate. It still omits whether results are paginated, how many webhooks are returned, and how this list relates to the shared/id variants, which an agent would want.
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; per the baseline for a 0-param tool this scores 4.
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 clear verb and resource ('Get all data webhooks'), and the plural 'all' implies a listing rather than a single-item fetch, which helps separate it from siblings like get_webhook_data_id. However, it never explicitly contrasts itself with get_webhook_data_shared or the _id variants, so the differentiation is only implicit.
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 use this tool versus the many sibling get_webhook_data_* tools, nor any exclusions or prerequisites. The agent must infer usage purely from the name and the word 'all'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get data webhook by ID. GET /api/v2/webhook/data/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds nothing beyond that – no auth requirements, no rate limits, no note on what happens with a missing/invalid ID, no return 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?
Two short sentences with the purpose front-loaded, so it is not bloated. However, the endpoint-path sentence largely restates the name-derived information and does not earn its place for an agent.
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, annotation-covered read tool with one required param and no output schema, the definition is minimally viable. The remaining gaps are the id format and any error behavior, which an agent would want 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?
With a single required parameter at 0% schema description coverage, the description must carry the load, but "by ID" only weakly signals that the id identifies the record. It gives no format hints (UUID, numeric, slug) or validation expectations for the id value.
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?
"Get data webhook by ID" states a verb and resource, but it is essentially the tool name restated, and the appended "GET /api/v2/webhook/data/{id}" is a raw endpoint path that adds no agent-relevant meaning. It does not differentiate this single-item fetch from the sibling list tool get_webhook_data or from get_webhook_data_id_shares/code_reactions beyond the implicit "by ID".
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 when-to-use guidance, no prerequisites, and no mention of alternatives such as get_webhook_data (list) or get_webhook_data_shared. The agent is left to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get code reactions for webhook. GET /api/v2/webhook/data/{id}/code-reactions
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| page | Yes | ||
| limit | Yes | Page size, max 100 (larger values are capped to 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds nothing beyond restating the HTTP path: it does not mention the mandatory pagination requirement, return shape, or rate behavior, so it contributes no behavioral context the structured fields lack.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no filler. The raw HTTP path is largely redundant given the tool name, but it costs little and the purpose statement leads.
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?
A three-parameter, pagination-driven list tool with no output schema needs the description to explain result contents and pagination expectations. Nothing about what a 'code reaction' is, its fields, or how paging behaves is provided, leaving the agent under-informed.
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% (just 'limit'), and page and id are entirely undocumented in both schema and description. With a low coverage ratio the description must compensate, but it says nothing about the meaning, format, or pagination role of any parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Get) and resource (code reactions for a webhook), which distinguishes it from the sibling get_webhook_data_id_llm_reactions by the reaction type. However, it never explicitly names that sibling or clarifies the code-vs-LLM distinction, so an agent must infer the split from the name alone.
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 when-to-use guidance, no prerequisites, and no mention of the alternative get_webhook_data_id_llm_reactions. The description gives no signal about when this tool is the right choice versus the other reaction-listing siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get LLM reactions for webhook. GET /api/v2/webhook/data/{id}/llm-reactions
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| page | Yes | ||
| limit | Yes | Page size, max 100 (larger values are capped to 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond a restatement of the route: no pagination behavior, no note that page/limit are mandatory, no empty-result semantics.
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?
It is short and front-loaded, which is good, but the second sentence is an HTTP route that largely restates the tool name and adds no semantic value. Efficient in size yet partly 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?
This is a paginated list endpoint with three required parameters and no output schema. The description never mentions pagination, required page/limit, result caps, or what a reaction object looks like, leaving real gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (limit is documented in the schema, id and page are not). The description's '{id}' fragment hints that id identifies a webhook data record, but it contributes nothing about the page parameter or valid ranges, failing to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb ('Get') and resource ('LLM reactions for webhook') plus the exact REST path, so an agent can distinguish it from the close sibling get_webhook_data_id_code_reactions. It is slightly ambiguous whether 'webhook' means the webhook itself or the webhook data record referenced by {id}.
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 use this tool versus alternatives such as get_webhook_data_id_code_reactions, get_public_llm_reaction, or list_all_public_llm_reaction. The agent must infer usage purely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all public code reaction
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that: it says nothing about pagination, result size, sorting, or whether 'all' truly means unfiltered, which is the one fact an agent would need here.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with no filler and the verb front-loaded. It is efficient, though its brevity shades into under-specification rather than tight phrasing.
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 is minimally adequate but omits what the call returns (a collection of reaction records) and whether results are complete or bounded. The annotations carry the safety story, so the gap is moderate rather than severe.
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. There is no parameter syntax for the description to clarify, and no contradiction with the empty 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 phrase 'Get all public code reaction' gives a verb and a resource, but it essentially restates the tool name rather than describing the operation. It does not distinguish this list-all variant from the sibling get_public_code_reaction (single-item fetch) or from list_all_public_llm_reaction, leaving the agent to infer the difference.
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 when-to-use guidance is provided. The description never mentions the alternative get_public_code_reaction for fetching a single reaction, nor when this bulk listing is preferred over the llm-reaction or code-strategy list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all public code strategies
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint=false, and the description adds nothing on top of them. The word 'all' is the only behavioral signal (no filtering), but nothing is said about pagination, result size, or visibility rules.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with no filler, and the resource is front-loaded. It is on the terse side rather than padded, so only the lack of any routing or scoping information 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 no-parameter, read-only list tool with a fully-covered schema and no output schema, the description is minimally sufficient. It still omits whether results are paginated or how the 'public' subset is defined, which an agent would want before calling 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 schema is trivially complete and there is nothing for the description to disambiguate. Baseline 4 applies for a no-argument tool.
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 ('Get all public code strategies'), so the agent knows exactly what it returns. However it does nothing to distinguish itself from the near-identical siblings get_public_code_strategy or list_all_public_llm_session, leaving the scope difference ambiguous.
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 on when to call this versus get_public_code_strategy, get_strategy_code, or the other list_all_public_* siblings. The agent must infer from the name alone that this is the bulk/unfiltered variant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all public llm reactions
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that: no mention of pagination, result size, ordering, or whether 'public' implies any filtering or auth requirement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short, front-loaded sentence with no filler. It is efficient, though it largely restates the tool name rather than adding information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no params, no output schema) so little is strictly required, but the description does not explain what a 'public llm reaction' is or what the caller receives, leaving the agent to infer the domain concept from the name alone.
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 per the rubric the baseline is 4. There is nothing for the description to disambiguate, and the schema is trivially complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb ('Get all') and resource ('public llm reactions'), and the 'all' plus 'public' scope distinguishes it from the singular sibling get_public_llm_reaction and from list_all_public_llm_session. It never explicitly names those alternatives, so it falls 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?
No guidance on when to use this versus get_public_llm_reaction or get_public_llm_session. The only implied usage is the tool name itself, with no exclusions or prerequisites stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all public llm sessions
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered structurally. The description adds nothing beyond that—no pagination behavior, no volume expectations, no return shape—so it contributes no incremental behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short, front-loaded sentence with no filler or redundancy. It is efficient, though its brevity reflects thin content rather than disciplined compression of richer material.
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?
With no output schema, the description is the only place to convey what a 'public llm session' is and how results are returned, yet it says nothing about the returned entities, ordering, or completeness. For a list-all tool with no parameters, this leaves the agent under-informed.
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 per the rubric the baseline is 4. There is no parameter information for the description to clarify or omit.
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 verb ('Get') and resource ('public llm sessions') with the 'all' scope implied by the name, so the basic intent is legible. However it essentially restates the tool name and does not distinguish itself from sibling get_public_llm_session (single vs list) or list_all_public_llm_reaction, leaving the agent to infer the difference.
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 when-to-use guidance, no mention of alternatives like get_public_llm_session, and no stated conditions or prerequisites. The agent is given nothing to route between this and its many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new exchange API key. POST /api/v2/api/exchange
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, so the write/non-destructive profile is already covered. The description adds nothing beyond confirming creation: no note on secret handling, validation of keys against the exchange, or whether the exchangeId must pre-exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action and followed by the endpoint path. No waste, though brevity here edges into under-specification rather than tightness.
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 output schema and a nested required body containing credentials, the description omits the return shape, error behavior, and security-relevant context. Annotations cover only the safety profile, leaving meaningful gaps.
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 single body parameter is a nested object whose required fields publicKey and privateKey have no description in either the schema or the description. The description says nothing about parameter shape, formats, or which exchanges accept 'extra', so it fails to compensate for the reported 0% top-level 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?
Clear specific verb+resource: 'Create a new exchange API key', which distinguishes it from the get_api_exchange and delete_api_exchange_id siblings. It does not, however, explicitly differentiate from post_api_exchange_test, which is the closest alternative an agent must choose between.
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 when-to-use guidance, no prerequisites, and no mention of the sibling post_api_exchange_test (which presumably creates a test key). The agent must infer the choice 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.
Test exchange API key credentials. POST /api/v2/api/exchange/test
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds only the endpoint path and the notion that this is a validation-style operation; it does not say whether credentials are persisted, whether the test can fail in ways the agent should handle, or any rate/permission 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?
Two short, front-loaded sentences with no filler; purpose comes first. The endpoint restatement is mildly redundant given the tool name, but it is cheap and 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?
With no output schema and thin annotations, the agent still lacks the key fact for a test tool: what a success or failure response signals (valid vs invalid credentials, error shape). The description identifies the operation but not the outcome semantics.
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%: the required body fields publicKey and privateKey have no descriptions and 'extra' is documented only as 'Some extra value if required'. The description says only 'credentials' and never maps the inputs (exchangeId, publicKey, privateKey) or explains the exchangeId-as-number convention, so it fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: testing exchange API key credentials, and pins the endpoint (POST /api/v2/api/exchange/test). An agent can distinguish this from post_api_exchange (create) and post_api_prediction_test (different service), though the description never names those siblings explicitly.
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 when-to-use guidance: it doesn't say to call this before/after post_api_exchange, whether it validates credentials already stored via another tool, or when to prefer post_api_prediction_test. The agent must infer the workflow entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new LLM API key. POST /api/v2/api/llm
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the write/non-destructive profile is covered. The description adds nothing beyond the annotations and the raw REST path — no statement about authentication needs, whether an existing key is invalidated, or what happens if the same service/model is registered twice.
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 brief sentences with the core action front-loaded, so it is efficiently sized. The trailing 'POST /api/v2/api/llm' line is largely redundant with the tool name and adds little value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a creation endpoint with a required nested body, three undocumented required fields, and no output schema. The description omits any information about what must be supplied or what is returned, leaving an agent under-equipped to call 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 0% and the single top-level 'body' parameter wraps three required fields (serviceId, modelId, apiKey). The description says nothing about these required identifiers or the optional name field, so it fails to compensate for the undocumented parameter surface.
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 ('Create a new LLM API key'), which cleanly separates it from sibling creators such as post_api_exchange and post_api_prediction. It stops short of naming or contrasting related LLM siblings (get_api_llm, put_api_llm_id_model), so no explicit differentiation is provided.
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 guidance on when to call this versus alternatives such as get_api_llm or put_api_llm_id_model, nor any mention of prerequisites (e.g. that a valid serviceId/modelId must be resolved first via get_api_llm_services). The agent is left to infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new prediction API key. POST /api/v2/api/prediction
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only give a weak safety profile (readOnlyHint=false, destructiveHint=false). The description doesn't disclose that it creates persistent credentials, or that walletPrivateKey is a sensitive secret that will be stored. For a credential-creation tool, that's a meaningful 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?
Very short and front-loaded, which is good, but it omits so much that the brevity reads as under-specification rather than efficiency. The endpoint URL is redundant given the tool name.
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?
A mutation tool that creates sensitive credentials, with no output schema and no schema documentation, and no annotations that explain the action. The description does not cover what happens on success/failure or how the key is used afterward.
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?
Parameter count is 1 (a nested body), and the schema description coverage is 0%. The description adds nothing about the required fields (exchangeId, funderAddress, walletPrivateKey) or what they mean, leaving the agent to infer from the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb 'Create' and resource 'prediction API key', which distinguishes it from siblings like post_api_exchange, post_api_llm, and post_api_prediction_test. However, it doesn't clarify the relationship with post_api_prediction_test or delete_api_prediction_id.
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 when-to-use guidance, no prerequisites, no mention of alternatives such as post_api_prediction_test, which appears to be a related tool for testing prediction connections. An agent has no signal about which of the two to call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test prediction API credentials. POST /api/v2/api/prediction/test
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description confirms the tool only validates credentials rather than persisting a config, but adds nothing about whether a live network call is made, whether it needs pre-stored credentials, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the purpose front-loaded and the raw endpoint path appended for routing clarity. No filler, though the endpoint path is of marginal value to an agent that already has the tool name.
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?
With no output schema, the description should explain what a "test" returns (success/failure shape, error semantics) and whether credentials must already exist. Neither is covered, and the credential-bearing body is left undescribed, so an agent cannot call this confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description says nothing about the required inputs. Schema description coverage is 0% at the top level (the `body` wrapper is undocumented), and the description does not compensate by mentioning exchangeId, funderAddress, or walletPrivateKey, leaving the agent dependent on the nested schema alone.
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 ("Test") and resource ("prediction API credentials"), which is enough to distinguish it from the sibling post_api_exchange_test (exchange credentials) and post_api_prediction (create). It stops short of explaining what "testing" actually validates, 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?
No when-to-use guidance is given: nothing says whether this should be called before saving credentials, after a failure, or in place of post_api_prediction. No alternative sibling is named or excluded, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new CEX signal bot. POST /api/v2/bot/signal/cex
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already tell the agent this is a non-read-only, non-destructive write, so the safety profile is covered without the description. Beyond that, the description adds only the HTTP route ('POST /api/v2/bot/signal/cex'), which gives no insight into side effects, whether the bot starts running immediately, authentication requirements, or default settings applied on creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded statements with no padding, and the purpose leads ahead of the route detail. The endpoint string is slightly redundant metadata, but it costs little and takes no reading effort.
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 creation tool taking a nested body of ten-plus fields with no output schema and no annotations beyond the write hint, the description is too thin. It does not say what a caller must supply, what happens on success, whether the bot is enabled on creation, or how it relates to the webhook/api resources it references.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions no parameters at all. Top-level schema description coverage is 0% (the required 'body' object carries no description), and while the nested properties are individually documented in the schema, the description contributes nothing about the required payload fields (webhook_id, api_id, symbol, amount_from_signal) or how they interact, e.g. amount vs amount_from_signal.
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 ('Create a new CEX signal bot'), which is enough to distinguish it from the DEX and prediction siblings on resource grounds. It stops short of explicitly naming those alternatives (post_bot_signal_dex, post_bot_signal_prediction, post_bot_signal_cex_duplicate), so an agent must infer the distinction from the name alone.
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 guidance on when to use this tool versus the sibling create tools (dex/prediction variants) or versus cloning an existing bot. No prerequisites are stated either, such as needing a valid webhook_id and api_id before calling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Duplicate a CEX signal bot. POST /api/v2/bot/signal/cex/duplicate
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a non-read-only, non-destructive write with openWorldHint=false. The description adds nothing beyond that: it doesn't say whether the copy is created active/inactive, how it is named, whether it needs auth, or what side effects occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the purpose front-loaded. The trailing HTTP endpoint adds little for an agent but is not wasteful enough to penalize heavily.
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 output schema and a nested required body, the description is thin. It omits what the duplicate produces (new ID, name, status) and any error/auth context an agent would need.
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 reported at 0% and the description supplies no parameter information at all. The nested 'id' field does carry a brief inline description in the schema, but the top-level body object is undocumented and the description does not 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?
States a specific verb ('Duplicate') and resource ('CEX signal bot'), which clearly separates it from the create sibling post_bot_signal_cex and from the DEX/prediction duplicate variants. It does not, however, elaborate on what the duplication entails.
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 guidance on when to use this versus post_bot_signal_cex or the other *_duplicate siblings, no prerequisites, and no exclusions. The agent must infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new CEX signal bot folder. POST /api/v2/bot/signal/cex/folder
| Name | Required | Description | Default |
|---|---|---|---|
| body | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, so the agent knows it's a safe non-destructive write to a closed system. The description adds nothing beyond the endpoint URL — no detail on what folder creation entails (nesting, ownership) 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?
Two short, front-loaded sentences with zero waste. The endpoint echo is arguably redundant but harmless.
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 write tool in a dense family of parallel folder-creation tools with no output schema and zero param docs in the description, the definition is thin. It doesn't distinguish itself from its many dex/prediction/strategy counterparts, leaving the agent to infer placement from the name alone.
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% and one nested 'body.name' param exists. The schema itself does carry an inline description ('optional, auto-generated if not provided'), so the description doesn't need to repeat it. Baseline 3 given the inline schema note.
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 ('Create'), resource ('CEX signal bot folder'), and even the HTTP endpoint. Clear and distinguishable from sibling post_bot_signal_dex_folder and post_bot_signal_prediction_folder.
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 on when to use this vs. the sibling folder-creation tools (dex/prediction variants) or vs. post_bot_signal_cex. The sibling set is large and structurally parallel, so explicit differentiation would be valuable; none is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new DEX signal bot. POST /api/v2/bot/signal/dex
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare this is a write (readOnlyHint=false) that is non-destructive and not open-world, so safety is covered. The description adds nothing beyond 'Create' - it doesn't explain what happens on success, what the required webhook/factory dependencies mean, or any auth/limit constraints, leaving the full behavioral burden unmet.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the verb-resource statement front-loaded and no padding. The trailing raw endpoint path is marginally redundant but harmless, so it reads efficiently.
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 creation tool with a nested required body and no output schema, the description is too thin: it omits prerequisites, the meaning of the signal bot being created, and any post-creation behavior an agent would need to call it confidently.
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?
Top-level schema description coverage is 0% (the single 'body' param is undocumented), so the description should compensate for the required nested fields (webhook_id, factory_id, chain_id, address, symbol). It provides no parameter meaning at all, though the nested properties do carry their own descriptions, which slightly softens the 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?
States a specific verb (Create) and resource (DEX signal bot), which lets an agent distinguish it from the CEX and prediction bot-creation siblings by name. It stops short of explicitly calling out those alternatives, so it lands at a strong 4 rather than 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 when-to-use guidance, no prerequisites (e.g., needing an existing webhook_id or factory_id), and no reference to the sibling creation tools. The agent must infer everything about context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new DEX signal bot folder. POST /api/v2/bot/signal/dex/folder
| Name | Required | Description | Default |
|---|---|---|---|
| body | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds no behavioral context beyond repeating the REST endpoint, disclosing nothing about required auth, whether the folder is created at root or under a parent, or how the auto-generated name behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no padding. The second sentence restating the HTTP route is mildly redundant but harmless.
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 create operation whose annotations already cover the safety profile, the description is minimally adequate, but it omits context a caller would want: response shape, where the new folder lands in the hierarchy, and validation 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?
With schema coverage reported at 0% and one optional parameter, the description supplies no parameter meaning at all. The fact that 'name' is optional and auto-generated is only discoverable from the schema, not the description.
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+resource ('Create a new DEX signal bot folder'), which clearly separates it from the CEX and prediction folder siblings by the DEX qualifier. It does not explicitly name those siblings, but the resource 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?
There is no guidance on when to use this versus post_bot_signal_dex, post_bot_signal_cex_folder, or when a folder is warranted at all. The agent must infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new prediction signal bot. POST /api/v2/bot/signal/prediction
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that: it does not say what is created, whether an existing webhook_id/api_id is required, or what happens on success, so behavioral value is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the action front-loaded and no wasted prose. The trailing HTTP route is of marginal value but is compact and occasionally useful for API mapping.
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 creation endpoint with a required nested body object and no output schema, the description omits the essentials: required identifiers (webhook_id, api_id), the relationship between slug_from_signal/amount_from_signal and their fallback fields, and any notion of the returned resource. It is too thin for the tool's 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?
Schema description coverage is reported at 0% and the description contributes no parameter meaning whatsoever. The nested body properties do carry their own descriptions in the schema, which limits the practical damage, but the description itself does nothing to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Create a new prediction signal bot'), which is clear and actionable. It does not, however, distinguish itself from close siblings such as post_bot_signal_prediction_duplicate or post_bot_signal_prediction_folder, leaving the agent to infer the difference from names alone.
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 guidance on when to use this tool versus the duplicate, folder, or cex/dex variants, and no mention of prerequisites such as needing an existing webhook or prediction API key. The agent must infer usage entirely from the name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Duplicate a prediction signal bot. POST /api/v2/bot/signal/prediction/duplicate
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false (mutation), destructiveHint=false, and openWorldHint=false. The description adds no behavioral context beyond restating 'Duplicate' — it does not say what the duplicate inherits, whether the original is affected, or what the response contains. It is consistent with annotations but mostly redundant.
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 with the purpose front-loaded and no wasted words. The endpoint path is included but adds little practical value for an agent that already has the tool name; still, it is efficient and 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?
For a mutation tool with a nested required body, no output schema, and no annotations covering return behavior, the description is too sparse. It omits what the duplication returns, whether the new bot has a distinct name, and any auth or rate-limit context, leaving significant gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the top-level body parameter, and the description adds no parameter meaning at all. The nested id field has a schema description ('Bot ID to duplicate'), but the tool description does nothing to compensate for the coverage gap or clarify what identifier format is expected.
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 ('Duplicate') and a specific resource ('prediction signal bot'), which distinguishes it from generic bot operations. However, it does not differentiate from sibling duplication tools like post_bot_signal_cex_duplicate, leaving the agent to infer scope from the resource name alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It simply states the operation, leaving the agent to guess usage context entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new prediction signal bot folder. POST /api/v2/bot/signal/prediction/folder
| Name | Required | Description | Default |
|---|---|---|---|
| body | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is a non-readonly, non-destructive, closed-world write (readOnlyHint=false, destructiveHint=false, openWorldHint=false). The description adds nothing beyond 'Create' – no auth requirements, no statement that the name is optional/auto-generated, no description of what the returned folder contains. It neither contradicts nor enriches the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action, zero wasted words. The trailing REST path is mildly redundant but conventional and harmless.
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 annotations cover the safety profile and there is no output schema to explain, the core need is minimal. However, for a creation tool with a nested body object the description omits success behavior, folder placement, and any return expectations, leaving a modest 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 reported at 0% and the description never mentions the single 'name' parameter or its optional/auto-generated behavior. With low coverage, the description is expected to compensate, but it does not add any parameter meaning.
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+resource combination ('Create a new prediction signal bot folder'), which is distinguishable from siblings like post_bot_signal_prediction (creates a signal) or delete_bot_signal_prediction_folder_id (removes a folder). It does not explicitly call out the sibling it complements, so it stops just short of full differentiation.
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 guidance on when to create a folder versus posting a signal directly, no mention of nesting under the prediction folder root, and no prerequisites. The agent must infer usage purely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new code strategy. POST /api/v2/strategy/code
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, which tells the agent this is a non-destructive write, so the description is not carrying the safety burden. However, it adds nothing behavioral of its own: no auth/permission needs, no note that a created strategy may start generating signals, no interaction with send_signal or webhook_id, and no statement that the call is non-idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no filler; the verb and resource come first and the endpoint path is a harmless secondary detail. It is efficient, though it is arguably terse to the point of under-specification rather than maximally informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create endpoint with a nine-field nested payload and no output schema, the description is the minimum viable: it names the operation but says nothing about what a code strategy is, how it relates to webhooks/folders, or what a successful creation returns. The rich nested schema compensates for the field-level gaps, which keeps this at an adequate rather than inadequate level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description contributes zero parameter information, but the nested schema itself documents all nine body fields with conditional requirements ('required if send_signal is true', 'required if use_price is true') and the max-255 constraint. The reported 0% coverage is an artifact of the unlabeled top-level 'body' wrapper, so the schema is effectively doing the heavy lifting and 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 clear verb+resource ('Create a new code strategy') and even echoes the REST path, so an agent knows this is a creation endpoint. It does not differentiate itself from close siblings such as post_strategy_code_duplicate or post_strategy_code_folder, which is the only thing keeping it out of the top band.
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 when-to-use guidance, no prerequisites, and no mention of alternatives, even though the sibling list contains two near-identical POST tools for this resource family. The agent must infer entirely from the name that this is the plain create rather than the duplicate or folder variant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Duplicate a code strategy. POST /api/v2/strategy/code/duplicate
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), so the bar is lower, but the description adds nothing beyond that: it doesn't say whether the copy gets a new ID/name, which folder it lands in, whether the original is untouched, or whether auth is required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action. The trailing raw endpoint 'POST /api/v2/strategy/code/duplicate' is redundant for an agent and could be trimmed.
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 output schema and a zero-coverage nested parameter, the description is too thin: an agent cannot tell what the resulting duplicate looks like, whether the original is preserved, or what success returns.
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 one required parameter ('body.id') with effectively no schema description coverage, so the description must carry the semantics; it says nothing about the ID format or that a nested 'body' wrapper is expected. The schema field text 'Strategy ID to duplicate' does the work, leaving the description with no added value.
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 gives a specific verb ('Duplicate') and resource ('a code strategy'), which is clearly distinguishable from the sibling duplication tools for reaction-code and LLM-session strategies. It is clear but never explicitly names or contrasts with those siblings.
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 guidance on when to duplicate versus create a new strategy, no prerequisites (e.g. ownership/permissions), and no mention of alternatives. The only content is the operation name plus a REST route.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new code strategy folder. POST /api/v2/strategy/code/folder
| Name | Required | Description | Default |
|---|---|---|---|
| body | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is a non-read-only, non-destructive, closed-world write, so the safety profile is covered. The description adds nothing behavioral beyond that: no statement about what is returned on creation, what happens if a folder with the same name exists, or whether authentication is required. The trailing REST path adds locational trivia rather than behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence plus the endpoint path; the purpose is front-loaded with zero filler. The raw HTTP path is arguably redundant given the tool name, but it costs little and the definition remains tight.
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 mutating creation tool with no output schema and only coarse annotations, the description omits the creation result, error/conflict behavior, and placement context (root vs. nested folder). An agent could call it, but it lacks the information needed to anticipate the 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?
Schema description coverage is reported at 0% at the top level, so the description is expected to compensate, and it does not mention the `body` object or the optional `name` field at all. The nested schema does describe `name` as auto-generated when absent, but the description duplicates none of that and adds no 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 gives a specific verb and resource ('Create a new code strategy folder'), which cleanly identifies the POST-strategy-code-folder family and separates it from the reaction-code and LLM-session folder siblings. It stops short of explicitly naming those siblings as alternatives, 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?
There is no guidance on when to create a folder versus using an existing one, no mention of prerequisites such as parent folder or strategy context, and no reference to alternative tools. The agent must infer usage entirely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new LLM session. POST /api/v2/strategy/llm-session
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, so the agent knows this is a non-destructive write. Beyond that, the description adds nothing: no word on scheduling behavior, whether the session runs immediately or on the cron interval, whether it requires an existing LLM API key, or what happens on failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, with zero filler. The endpoint path is redundant but harmless. It is concise to the point of under-specification rather than verbose.
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?
This tool creates a complex, richly parameterized LLM strategy session (15 nested fields, enum-constrained intervals, conditional chart/signal requirements) with no output schema. The description covers none of that context, leaving the agent reliant entirely on reading the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is reported at 0% for the top-level body parameter, which is itself undocumented. The description supplies no parameter meaning at all — no hint of the required llm_api_id, cron_interval, or prompt, nor the chart/signal/webhook options. It fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb+resource: 'Create a new LLM session'. An agent immediately knows this is a creation operation. However, it does nothing to distinguish itself from siblings such as post_strategy_llm_session_duplicate or post_strategy_llm_session_folder, nor does it explain what an 'LLM session' strategy actually is.
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 when-to-use guidance, no prerequisites, and no mention of alternatives. The agent is not told how this differs from duplicate/folder siblings, nor when a session vs. a strategy code or reaction LLM entity should be created.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Duplicate an LLM session. POST /api/v2/strategy/llm-session/duplicate
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is partly covered. The description adds nothing beyond that: it doesn't say whether the original is untouched, whether a new ID/name is assigned, or whether the duplicate inherits folder/public settings. The endpoint path is noise, not behavioral 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?
Two short, front-loaded sentences with the action stated first. The trailing raw endpoint path adds no value but is not confusing.
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?
A creation/mutation tool with no output schema and only partial annotation coverage. The agent does not learn what the response contains (e.g., the new session identity) or what is inherited from the source session, which is critical for chaining a subsequent get/update 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?
There is effectively one parameter (a nested body with 'id'), and the schema itself documents it as 'Session ID to duplicate'. The description adds no syntax, format, or semantics beyond the schema, so the baseline 3 applies for essentially schema-covered 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 ('Duplicate') and resource ('LLM session'), and the tool name distinguishes it from the sibling duplicates (code, reaction_code, reaction_llm, bot_signal). However, it doesn't clarify what a duplication actually copies or how the copy is identified, which matters for the sibling duplicate tools.
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 on when to duplicate versus creating a new session (post_strategy_llm_session), nor any prerequisites such as ownership or folder placement. The agent must infer all usage context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new LLM session folder. POST /api/v2/strategy/llm-session/folder
| Name | Required | Description | Default |
|---|---|---|---|
| body | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, and the description is consistent with them, but it adds no behavioral context at all: no auth requirements, no note on the auto-generated name behavior, no indication of what the response contains or whether the new folder collides with existing names.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences; the purpose clause is front-loaded and useful, but the second sentence merely restates the HTTP route already implied by the tool name, so it does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create call with annotations covering the safety profile and a schema documenting the only field, this is minimally viable; however, with no output schema, the description should say something about the created folder's identity or the auto-naming 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 reported at 0% for the single body parameter, and the description says nothing about it. The nested 'name' property does carry an inline 'optional, auto-generated if not provided' note, but the description itself contributes no meaning beyond the wrapper path.
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: 'Create a new LLM session folder'. This clearly separates it from post_strategy_llm_session (creates a session) and put_strategy_llm_session_folder_id (updates a folder), though the differentiation is carried by the name rather than the text.
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 when-to-use guidance, no prerequisites, and no mention of related siblings such as post_strategy_llm_session or the duplicate/get folder tools. The agent must infer the whole usage context from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new code reaction. POST /api/v2/strategy/reaction/code
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the agent knows this is a non-destructive write. The description adds nothing beyond restating the verb and the endpoint path -- it does not disclose that fields like symbol/webhook_id are conditionally required, that price_symbol is needed when use_price is true, or what the call returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action. The endpoint path is marginally redundant but harmless. 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?
This is a complex create tool with 11 nested fields and several conditional requirements, no output schema, and no description of the resulting entity or its side effects. The terse description leaves an agent without the context needed to call it confidently.
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 single top-level 'body' param carries no description (reported coverage 0%), so the description does not compensate. However, the nested schema properties are individually well documented (code, send_signal, symbol, webhook_id, etc.), so an agent can still construct the payload from the schema alone. Baseline 3 reflects that the schema does the heavy lifting and the description adds nothing.
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 ("Create a new code reaction"), which distinguishes it from the LLM-reaction siblings and the read/duplicate/post_strategy_code tools. However, it does not explicitly name an alternative (e.g., post_strategy_reaction_code_duplicate) or state what a "code reaction" is, so it stops short of true sibling differentiation.
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 guidance on when to use this tool versus post_strategy_reaction_code_duplicate, post_strategy_code, or post_strategy_reaction_llm. No prerequisites or context are given beyond the implied create action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Duplicate a code reaction. POST /api/v2/strategy/reaction/code/duplicate
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is a non-read-only, non-destructive, closed-world mutation. The description adds nothing beyond that: it doesn't say what the duplicate looks like (name, public/private state, whether it is enabled), nor whether the original is modified. The HTTP path is documentation residue, not behavioral insight.
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?
Very short and front-loaded, which is good, but the second sentence ('POST /api/v2/strategy/reaction/code/duplicate') merely restates the tool name and endpoint convention without adding information, so it fails the 'every sentence earns its place' test.
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 output schema and an opaque nested body, the description leaves key facts unstated: what is returned, whether the duplicate inherits the original's settings, and any permission requirements. It is too thin for an agent to call confidently.
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?
Only one parameter, and the description says nothing about it. Reported schema description coverage is 0%, so the description should carry the burden of explaining that 'id' is the source reaction's ID, but it does not; the agent must infer this from the field name alone.
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 clear verb ('Duplicate') and resource ('a code reaction'), which is unambiguous on its own. It does not explicitly distinguish itself from the close siblings post_strategy_reaction_llm_duplicate or post_strategy_code_duplicate, so it relies on the tool name for differentiation.
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 when-to-use guidance, no prerequisites (e.g., the source reaction must exist or be owned by the caller), and no mention of the sibling duplicate tools for LLM reactions or code strategies. The agent gets only the action, not the context for choosing it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new code reaction folder. POST /api/v2/strategy/reaction/code/folder
| Name | Required | Description | Default |
|---|---|---|---|
| body | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the write/safety profile is covered. The description only restates the HTTP verb and path, adding nothing about auth, name uniqueness, the auto-generated name fallback, or the response — no value beyond structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the action front-loaded and zero padding. The trailing HTTP path is borderline redundant with the POST verb but is compact enough not to hurt.
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 creation tool with no output schema and a thin input schema, the description should at least indicate what is created and where it lands (root vs. nested folder). It omits response shape, scoping, and auth requirements entirely.
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 reported at 0%, so the description carries the burden, yet it says nothing about the single body/name parameter or that it is optional. The schema's inline note about auto-generation is the only place that information exists.
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+resource combination ('Create a new code reaction folder') that lets an agent distinguish it from post_strategy_reaction_code or post_strategy_reaction_llm_folder by name. It stops short of any explicit sibling differentiation in the prose itself.
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 when-to-use guidance, no prerequisites, and no mention of alternatives such as post_strategy_reaction_code or post_strategy_reaction_llm_folder. The agent must infer everything from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new LLM reaction. POST /api/v2/strategy/reaction/llm
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the mutation nature is known. The description adds nothing beyond restating the operation and the raw HTTP route — no auth requirements, no side effects (signals, emails, webhooks triggered by the optional flags), and no rate-limit or validation notes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no filler or repetition. It is economical, though the brevity borders on under-specification for a tool with this many fields.
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 high-complexity creation tool with a large nested body, no output schema, and conditional field dependencies, the description covers none of the domain context (what an LLM reaction is, how it links to a data webhook and LLM API key, what creating it triggers). The schema fields carry the load, but the definition is too thin for the tool's 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 top-level schema has a single body parameter with no description (0% coverage), but the nested properties are individually well documented in the schema itself, including conditional requirements like 'required if use_chart is true'. The description adds no parameter meaning, so it neither compensates nor detracts.
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 ('Create a new LLM reaction'), and the endpoint path confirms the target collection. However, it gives no differentiation from close siblings such as post_strategy_reaction_llm_duplicate or post_strategy_reaction_code, so the agent must infer which tool applies.
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 guidance on when to use this tool versus the duplicate/code-folder siblings, nor any prerequisite information. The description does not mention that llm_api_id, data_webhook_id and prompt are required, leaving the agent to discover this only from the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Duplicate an LLM reaction. POST /api/v2/strategy/reaction/llm/duplicate
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is partly covered, but the description adds nothing behavioral: it does not say a new reaction is created, whether the copy gets a new ID/name, whether it lands in the same folder, or whether the source is mutated. The REST path echoes the tool name rather than disclosing 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?
Two short, front-loaded sentences with no wasted wording; the verb and resource come first. The trailing REST path is redundant with the tool name but not harmful.
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?
This is a mutation tool with no output schema, so the description should explain what duplication produces (new reaction ID, copied configuration, placement). It also omits whether folder/status fields on the source are carried over. For a duplicate endpoint, that leaves the agent guessing about 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?
Schema description coverage is reported as 0% and the description mentions no parameters at all. The nested 'id' field does have an inline description in the schema ('Reaction ID to duplicate'), but the description contributes zero meaning beyond it, and the wrapper 'body' object is undocumented in both places.
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 ('Duplicate') and resource ('LLM reaction'), which separates it from the create tool post_strategy_reaction_llm and the code analogue post_strategy_reaction_code_duplicate. It does not explicitly name siblings, but the resource noun is distinctive enough for an agent to route correctly.
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 guidance on when to duplicate versus creating a new reaction (post_strategy_reaction_llm) or editing one (put_strategy_reaction_llm_id). The usage is only implied by the word 'Duplicate', and no prerequisites or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new LLM reaction folder. POST /api/v2/strategy/reaction/llm/folder
| Name | Required | Description | Default |
|---|---|---|---|
| body | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the write-safe profile is covered. The description adds only the raw REST path, which conveys nothing about auth needs, folder nesting/conflict behavior, or what happens if the name collides with an existing folder.
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?
Very short and front-loaded, which is good, but the second sentence merely restates the HTTP endpoint and adds no information an agent can act on.
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 a nested object body, no output schema, and no annotations covering anything beyond safety, the description omits expected response, folder placement, duplicate-handling, and permissions. It is too thin for the tool's 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 single nested body parameter has 0% schema description coverage at the top level, and the description says nothing about the request body. The optional auto-generated 'name' behavior is documented only inside the schema, so the description contributes no meaning beyond it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Create a new LLM reaction folder.' This distinguishes it from sibling post_strategy_reaction_llm (reaction, not folder) and the duplicate/put variants, though it does not explicitly name those siblings.
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 when-to-use guidance, no prerequisites, and no mention of alternatives or how this differs from post_strategy_reaction_llm_folder_id-style PUT operations. The agent must infer all context from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new bot webhook. POST /api/v2/webhook/bot
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds nothing beyond that — no note on what happens when a bot hook with the same name exists, what the hash_key/is_safe interplay does, or any side effects. It only restates the HTTP method and path.
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 that are short, but the second sentence 'POST /api/v2/webhook/bot' merely restates the HTTP method and endpoint, adding little actionable value. It is front-loaded but not maximally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema and a nested-object body whose key fields (is_safe/hash_key) are semantically opaque, the description is too thin. It omits what the created hook is, how it is triggered, and the meaning of its security-related fields.
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% for the single 'body' parameter, and the description supplies no parameter meaning at all. The ambiguous nested fields (is_safe, hash_key) get no clarifying explanation in the description, so it fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Create a new bot webhook'), which is clearly distinguishable in kind from delete_/get_/put_webhook_bot siblings. However, it offers no differentiation from other create tools (e.g., post_webhook_data, post_webhook_bot_share_id), so the agent gets no help picking among the post_* family.
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 guidance on when to use this tool versus related siblings such as post_webhook_bot_share_id or put_webhook_bot_id, nor any prerequisite or context. The agent must infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new data webhook. POST /api/v2/webhook/data
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the agent knows this is a non-destructive write confined to the service. The description adds only the raw endpoint path (POST /api/v2/webhook/data), with no auth requirements, side effects, or idempotency notes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, action front-loaded, zero filler. It is efficient rather than verbose, though the endpoint string is arguably redundant with the tool name.
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/mutation tool wrapping a nested object, the description omits what a data hook is, what happens on creation, and whether the nested fields are fully optional. With no output schema, the agent gets no return-value expectations either; only annotations carry the safety profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description says nothing about parameters, and top-level schema coverage is 0% for the single 'body' parameter. However, the nested body properties (name, is_safe, hash_key, description) each carry their own schema descriptions, so the field-level meaning is largely covered by structured data and the description is not required to compensate much.
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 ("Create a new data webhook"), which cleanly separates it from the read/update/delete webhook_data siblings and from post_webhook_bot. It stops short of explaining what a 'data webhook' is versus a bot webhook, so the agent gets the action but not the object's role.
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 when-to-use guidance, no prerequisites, and no named alternatives. Siblings such as post_webhook_data_share_id or post_webhook_bot are never referenced, leaving the agent to infer which creation endpoint applies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update API key status. PUT /api/v2/api/exchange/{id}/status
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds nothing beyond that: it does not say what setting INACTIVE actually does (e.g., whether it disables the key for live trading), whether the change is reversible, or whether elevated permissions are required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short fragments, no filler, purpose front-loaded before the endpoint. It is appropriately sized for what little it says, though the brevity reflects under-specification rather than disciplined editing.
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 a nested required body, a status enum, 0% schema description coverage, and no output schema, this description is far too thin. An agent cannot tell from it what values are valid, what the operation affects, or what it returns.
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% and the description compensates for none of it. The URL template hints that {id} is a path identifier, but the required 'body' object and its status enum (ACTIVE/INACTIVE) are never mentioned, leaving the enum semantics undocumented anywhere.
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 ('Update') and resource ('API key status') plus the underlying endpoint, so an agent knows this mutates an exchange API credential's status. It does not differentiate itself from near-identical siblings like put_api_prediction_id_status or put_bot_signal_cex_id_status, which is why it stops short of 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 when-to-use guidance, no prerequisites, and no mention of alternatives such as delete_api_exchange_id (removal) versus this status toggle. The agent must infer usage entirely from the name and endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update model for an API key. PUT /api/v2/api/llm/{id}/model
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish a non-destructive write (readOnlyHint=false, destructiveHint=false), so safety is covered. The description adds only the HTTP verb/path, saying nothing about whether the change affects in-flight sessions, requires ownership of the key, or is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with the core action first. The raw endpoint path is somewhat redundant filler given the name, but nothing else is wasted.
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 a nested body, no output schema, and near-zero parameter documentation, the description is too thin: no prerequisites, no effect of the change, no link between the id and the key being modified.
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 effectively 0% per signals (only the nested modelId carries a terse note). The description never explains that 'id' is the API key identifier or that modelId must reference an existing LLM model, so it fails to compensate for the undocumented 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 ('Update model for an API key') plus the underlying endpoint, so the operation is unambiguous. It does not name or contrast any sibling such as get_api_llm or post_api_llm, and the term 'API key' is a loose stand-in for the LLM configured key.
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 when-to-use, when-not-to-use, or alternative is given. An agent must infer that this changes the model bound to an existing LLM key rather than creating (post_api_llm) or deleting (delete_api_llm_id) it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update prediction API key status. PUT /api/v2/api/prediction/{id}/status
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, so the safety profile is covered structurally. The description adds essentially nothing beyond restating the operation -- it doesn't say whether the change is reversible, what effect it has on in-flight predictions, or any auth requirements. Only the bare status toggle is conveyed.
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 compact sentences, front-loaded with the operation and followed by the endpoint. No wasted words, though the endpoint path is largely redundant with the tool name.
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 a nested body object, no output schema, and 0% schema description coverage, the description is too thin. It omits parameter meaning, side effects, and return behavior, leaving the agent without enough to call it correctly and interpret 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?
Schema description coverage is 0%, so the description carries the full burden of explaining the two required parameters. It explains neither the meaning of 'id' nor that 'body.status' accepts ACTIVE/INACTIVE. The enum is only discoverable in the schema, and the description compensates for none of the 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?
States a specific verb and resource: 'Update prediction API key status.' Combined with the PUT path, an agent understands this toggles the status of a prediction API key. It doesn't name or distinguish itself from the many sibling status tools (put_bot_signal_prediction_id_status, put_webhook_bot_id_status, etc.), so it falls short of full sibling differentiation.
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 no when-to-use guidance, no prerequisites, and no alternatives. It never explains when an agent should change key status versus creating a new key (post_api_prediction) or deleting one (delete_api_prediction_id). Usage must be entirely inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update CEX signal bot folder. PUT /api/v2/bot/signal/cex/folder/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Folder ID | |
| body | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so safety is partly covered. The description adds nothing beyond the raw endpoint: it doesn't say whether the update is full-replace or partial, whether the folder must exist, auth needs, or what happens to unmentioned fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero waste and front-loaded with the action. Very efficient, though the endpoint string is arguably redundant with the name.
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?
A mutation tool with no output schema and a nested body object gets a bare-bones description. Nothing explains the mutation semantics an agent would need to call it safely or 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 only 50% and the description adds no parameter meaning beyond the endpoint template ({id} is implied). The auto-generated name behavior lives in the schema, not the description, so the description fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Update CEX signal bot folder'), which cleanly identifies it against the many sibling PUT folder tools (dex, prediction, strategy_code). It stops short of explicitly distinguishing itself from those siblings in the text, relying on the name alone.
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 on when to use this versus put_bot_signal_dex_folder_id, post_bot_signal_cex_folder (create), or get_bot_signal_cex_folder_id. Only the HTTP verb implies a modification context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update CEX signal bot. PUT /api/v2/bot/signal/cex/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare it as a non-read-only, non-destructive mutation, but the description adds no behavioral context of its own. It does not say whether this is a full replacement of the bot config, what happens to fields omitted from the body, whether permissions are required, or what the response returns.
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?
Very short and front-loaded with the verb+resource, which is good, but the trailing 'PUT /api/v2/bot/signal/cex/{id}' adds little for an agent that already has the tool name and schema. It is efficient but under-specified rather than tight.
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 taking a required 11-field nested body, with no output schema to explain results, the description is far too thin. It omits update semantics, required-field implications, and return behavior, leaving the agent to infer almost everything from structured fields.
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?
Top-level schema coverage is 0%: the 'id' path parameter and the nested 'body' object are undocumented at that level, and the description supplies nothing to compensate. The inner body properties do carry schema descriptions, which saves this from a 1, but the description itself contributes zero parameter meaning.
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 clear verb+resource ('Update CEX signal bot') and confirms the CEX variant via the endpoint path, so the agent knows this mutates a CEX signal bot rather than a DEX or prediction one. It does not, however, distinguish itself from the close sibling put_bot_signal_cex_id_status or say which fields are updatable.
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 when-to-use guidance is given: nothing tells the agent when to call this full update versus put_bot_signal_cex_id_status, or what preconditions (existing bot, valid API/webhook ids) must hold. The only implicit signal is the HTTP verb in the path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update CEX signal bot status. PUT /api/v2/bot/signal/cex/{id}/status
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond restating the operation and echoing the HTTP route: it doesn't say what toggling to INACTIVE does to the running bot, whether it's reversible, or what auth is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the operation front-loaded and no filler. It is efficient, though the brevity reflects under-specification rather than disciplined editing.
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?
A mutation tool with a nested body object, no output schema, and 0% schema description coverage needs more explanation than this. The description leaves the state semantics and the nested parameter undocumented.
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 carries the burden, yet it only echoes the '{id}' path token from the URL and never explains that id is the bot identifier or that body.status is the ACTIVE/INACTIVE toggle. The enum meaning is left entirely to 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+resource: 'Update CEX signal bot status', which an agent can distinguish from put_bot_signal_cex_id (full bot update) and the dex/prediction status siblings by resource. It stops short of explicitly differentiating from siblings, but the purpose 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?
No when-to-use guidance, no prerequisites, and no mention of the alternative put_bot_signal_cex_id or delete_bot_signal_cex_id. The agent must infer that this is the narrow status-only mutation 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.
Update DEX signal bot folder. PUT /api/v2/bot/signal/dex/folder/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Folder ID | |
| body | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare that this is a non-read-only, non-destructive, closed-world operation. The description adds only the HTTP method and route, with no additional behavioral context such as partial-update semantics, auth requirements, or what happens to unspecified fields.
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, front-loaded statements with no filler. It is efficiently sized, though its brevity contributes to the broader under-specification.
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 a nested body parameter and no output schema, the description is too thin. It does not explain what the body can update, whether the update is partial or replacement, or what the response contains.
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%, and the description mentions neither the required id parameter nor the optional body.name field. It therefore does not compensate for the missing schema documentation.
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: update DEX signal bot folder. It distinguishes the DEX folder endpoint from CEX/prediction siblings by name, but does not explicitly differentiate from sibling put_bot_signal_dex_id.
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, nor about prerequisites or when not to use it. The agent must infer usage from the name and endpoint alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update DEX signal bot. PUT /api/v2/bot/signal/dex/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond the annotation-covered 'this is a mutation' implication, saying nothing about partial vs. full replacement semantics, permissions, or what happens to unspecified fields.
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 terse fragments with the action front-loaded. The repeated HTTP endpoint is mildly redundant with the tool name but plausibly useful for API-mapping agents, so it is not wasted space.
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?
This is a PUT mutation with a nested required body object and no output schema. The description omits update semantics (full replace vs. patch), required body fields, and result behavior, leaving significant gaps for a tool of this 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?
Top-level schema coverage is 0% for the 'id' and 'body' parameters, and the description provides no clarification. While the nested body properties (name, delay, symbol, folder_id, webhook_id) do carry schema descriptions, the description itself adds no parameter meaning and does not compensate for the uncovered top-level params.
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 ('Update DEX signal bot'), which an agent can distinguish from the CEX and prediction variants via the 'DEX' qualifier. However, it does not explicitly name or route against the closest siblings like put_bot_signal_dex_id_status or post_bot_signal_dex.
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 on when to use this versus alternatives such as put_bot_signal_dex_id_status (status changes) or post_bot_signal_dex (creation). The agent must infer usage purely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update DEX signal bot status. PUT /api/v2/bot/signal/dex/{id}/status
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is covered. The description adds nothing behavioral beyond that—no idempotency, auth requirements, or what happens to running signals—and the endpoint path merely restates the tool name. It neither contradicts nor meaningfully enriches the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, purpose front-loaded, no filler. The trailing HTTP path is the only mildly redundant element.
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 a nested body and zero schema coverage, no output schema, and no parameter documentation, the description is too thin. An agent cannot tell how to populate status or what the update returns without opening the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is expected to compensate, but it does not. It never explains the id format or that the body accepts exactly ACTIVE/INACTIVE (the enum the schema happens to carry), leaving the nested body largely undocumented.
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 (update) and resource (DEX signal bot status), and the DEX/status qualifiers distinguish it from the CEX and prediction status siblings and from put_bot_signal_dex_id. The trailing HTTP path restates the same operation. It is clear, though it never names the sibling it is contrasted with.
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 when-to-use, when-not, or alternative guidance. The agent must infer from the name alone that this toggles status rather than editing the bot config (put_bot_signal_dex_id). No prerequisites or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update prediction signal bot folder. PUT /api/v2/bot/signal/prediction/folder/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Folder ID | |
| body | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), and the description adds nothing beyond restating the mutation via 'Update'. It never says what is being modified (only the folder name), that the change is non-destructive/reversible, or what happens when the body is omitted despite the schema noting auto-generation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action. The raw 'PUT /api/v2/...' fragment is largely redundant for an agent that already has the tool binding, but it costs little.
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 with a nested request body, no output schema, and no annotations covering mutation specifics, the description is silent on what fields are updatable, the auto-generated-name behavior on an empty body, and any permission requirements. An agent cannot call this confidently beyond passing an id.
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 50%: the bare 'body' object carries no description, and the description adds no parameter meaning at all, only echoing the path template. With a nested body object and half the schema undocumented, the description should compensate and does not.
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 (Update) and resource (prediction signal bot folder), which is distinguishable from the sibling delete_/post_/get_ variants on the same resource. The phrasing 'prediction signal bot folder' is slightly scrambled but an agent can still route correctly 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?
No when-to-use guidance, no prerequisites, and no mention of alternatives such as post_bot_signal_prediction_folder for creation or put_bot_signal_prediction_folder_id versus the bot-level put_bot_signal_prediction_id. The agent must infer scope 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.
Update prediction signal bot. PUT /api/v2/bot/signal/prediction/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly=false, destructive=false, openWorld=false), so the bar is lower, but the description adds nothing beyond the route: it does not say whether this is a full replace or partial patch, whether unknown fields are dropped, what permissions are required, or what the response contains. For a mutation tool that is a real 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?
Two short sentences with the operation front-loaded, so nothing is wasted, but the second sentence merely restates the HTTP verb/path and the whole entry is under-specified rather than genuinely 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 nested-payload mutation tool with no output schema and only safety annotations, the description leaves the agent guessing about update semantics, required fields, and side effects. The rich body schema partially compensates, but the definition as a whole is thin for this 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?
Top-level schema description coverage is 0% — neither id nor body is documented, and the description does not compensate by explaining that id identifies the bot instance and body carries the update payload. The nested body properties are well described in the schema, but that credit belongs to the schema, not the description.
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 ("Update prediction signal bot") plus the exact HTTP route, which maps unambiguously to the prediction-bot update family and distinguishes it from post_bot_signal_prediction and delete_bot_signal_prediction_id. It does not, however, contrast itself with the very similar sibling put_bot_signal_prediction_id_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this over put_bot_signal_prediction_id_status, the folder variant, or post_bot_signal_prediction_duplicate. The agent must infer intent purely from the name and route.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update prediction signal bot status. PUT /api/v2/bot/signal/prediction/{id}/status
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the write-but-not-destructive profile is covered. The description adds nothing beyond restating the endpoint URL; it does not mention required permissions, whether the change is reversible, or side effects on a running bot. With annotations carrying the safety profile, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences that lead with the action and follow with the endpoint. No wasted words, though the endpoint path is largely redundant given the tool name.
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 output schema and 0% parameter documentation, the description is too thin. An agent cannot tell what the status values do, what 'id' refers to, or what a successful response looks like; the burden falls entirely on an undescribed schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so both the 'id' path parameter and the nested 'body.status' enum are undocumented in structured fields. The description does not compensate at all - it never explains that 'id' identifies the prediction signal bot or that status accepts only ACTIVE/INACTIVE.
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 ('Update prediction signal bot status'), which distinguishes it from the cex/dex variants in the sibling list (put_bot_signal_cex_id_status, put_bot_signal_dex_id_status). It stops short of explicitly naming those siblings as alternatives, 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?
There is no guidance on when to use this versus the many sibling status-update tools (cex, dex, api_prediction) or how it relates to put_bot_signal_prediction_id. Usage is only implied by the name, with no conditions or prerequisites stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update code strategy folder. PUT /api/v2/strategy/code/folder/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Folder ID | |
| body | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, so the mutation/safety profile is covered. The description adds nothing beyond that — no note on required permissions, whether name is the only mutable field, or what happens to unspecified fields — and the REST path is just a restatement of the 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?
Two short, front-loaded sentences with no filler. The second sentence (the raw PUT path) is largely redundant with the tool name and schema, but it is brief and does aid mapping to API docs.
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 a nested, loosely-typed body object, no output schema, and only half the parameters documented, the description is too thin. It omits request semantics, error conditions, and any indication of what the update returns or affects.
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 50%: the nested 'body' object has no description and is open-ended (additionalProperties), while id and name are documented in the schema. The description contributes no additional meaning about the body payload or how the auto-generated name behavior works, so it fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb+resource ('Update code strategy folder'), which is enough to distinguish it from sibling read/delete variants. It does not, however, differentiate it from near-neighbors like put_strategy_reaction_code_folder_id or put_strategy_llm_session_folder_id, relying on the name alone for that.
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 when-to-use guidance, no mention of prerequisites (does the folder need to exist?), and no reference to alternative tools such as post_strategy_code_folder for creation. The agent must infer everything from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update code strategy. PUT /api/v2/strategy/code/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that: it does not say whether this is a full replacement (fields omitted from body may be cleared) or a merge, nor any auth or side-effect 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?
Two short fragments, front-loaded with the verb and resource; nothing is padded. The REST path is somewhat redundant but cheap and useful for disambiguation.
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 endpoint with a nested 10-field body, no output schema, and no explanation of replacement semantics, the description is too thin. An agent cannot tell from the definition alone what a PUT here overwrites.
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?
Top-level coverage is 0%: the required 'id' and 'body' parameters have no descriptions in either the schema or the description. The nested body fields are documented in the schema, but the description does not compensate for the undocumented path parameter or explain the update semantics of the 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 specific verb (Update) and resource (code strategy), and the REST path disambiguates it from sibling POST/GET variants. It does not explicitly name the alternatives, but the operation is identifiable 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?
There is no when-to-use guidance and no mention of alternatives such as post_strategy_code for creation or put_strategy_code_id_status for status changes. The agent must infer usage purely from the verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update code strategy public visibility. PUT /api/v2/strategy/code/{id}/public
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag this as a non-read-only, non-destructive mutation, so the safety profile is covered. The description adds no behavioral context beyond that - it doesn't say what becomes public, whether existing state is overwritten, what auth is required, or what toggling off does. It essentially restates the name plus a raw REST path.
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 terse lines, front-loaded with the action, no padding. The trailing raw endpoint (PUT /api/v2/strategy/code/{id}/public) is somewhat redundant with the name but harmless and mildly informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with a nested body, no output schema, and unresolved parameters, the description is too thin. It omits permissions, side effects (e.g. appearance in list_all_public_code_strategy), reversibility, and response behavior that an agent needs 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?
Schema description coverage is 0%; the only documented parameter (isPublic) is described in the schema itself, while the required 'id' is undocumented everywhere. The description does not compensate - it clarifies neither the id format nor how the body's visibility flag behaves.
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 (Update) and resource (code strategy public visibility), so the intent to toggle public visibility on a strategy code is discernible. The 'code strategy' qualifier implicitly differentiates it from the sibling llm_session/reaction variants, though it never names them.
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 when-to-use guidance, no prerequisites, and no indication of when to prefer this over put_strategy_code_id_status or the other *_public siblings. Usage must be inferred entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reset code strategy triggers and/or storage. PUT /api/v2/strategy/code/{id}/reset
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is covered structurally. The description adds only that triggers and/or storage can be reset, without saying what state is lost, whether it is reversible, or what permissions are needed. Useful but thin given 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?
Two compact phrases, front-loaded with the action and followed by the HTTP route. No filler, though the route adds little beyond the tool name.
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?
A mutation tool with a nested required body, no output schema, and no annotations explaining effects. The description never says what a reset actually does to the strategy's runtime state or what is returned, leaving the agent unable to predict the outcome of 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?
Top-level schema description coverage is 0%, but the nested body properties carry inline descriptions ('Set true to reset store/triggers') and the description's 'triggers and/or storage' wording maps to those two booleans. It does not explain how the two flags interact (both required, set false to skip).
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 ('Reset') and resource ('code strategy triggers and/or storage'), so the operation is identifiable. It is not differentiated from sibling mutations like put_strategy_code_id_status or delete_strategy_code_id_store, but the action itself is 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 on when to reset versus using put_strategy_code_id (edit), put_strategy_code_id_status (enable/disable), or delete_strategy_code_id_store. The agent must infer the use case 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.
Update code strategy status. PUT /api/v2/strategy/code/{id}/status
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish it is a non-destructive write with no open-world access, so the safety profile is covered. The description adds nothing beyond that: no mention of what deactivating does to a running code strategy, whether the call is idempotent, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no wasted filler. The raw HTTP path is arguably noise for an agent, but it does encode that id sits in the path.
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 a nested body, no output schema, and only bare annotations, the description omits critical context: valid status transitions, effects on active strategies, and any permission requirements. It is too thin for the operation's 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?
Schema description coverage is 0%, so the description carries the burden of explaining 'id' and 'body.status'. The path template hints that id is the strategy code identifier and status is the mutated field, but the ACTIVE/INACTIVE enum meaning is left entirely to the schema with no added interpretation.
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 ('Update code strategy status'), which an agent can distinguish from the sibling put_strategy_code_id that edits the strategy body. It does not clarify which statuses exist or what changing them means, but the core action 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?
No indication of when to use this versus put_strategy_code_id, put_strategy_code_id_public, or put_strategy_code_id_reset. The agent gets the verb but no selection criteria or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update LLM session folder. PUT /api/v2/strategy/llm-session/folder/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Folder ID | |
| body | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=false, destructive=false, openWorld=false, so the safety profile is covered and not contradicted. The description adds essentially nothing beyond that — no permission requirements, no statement of whether the update is partial/merge, and no note that only 'name' is mutable here.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded segments with no padding. The REST path adds little agent value and is slightly redundant, keeping 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 mutation tool with no output schema and a nested body object, the description omits what the update affects, whether unspecified fields are preserved, and any permission context. It is too thin to call the tool correctly without opening the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only 'id' documented at the top level), so the description is expected to compensate but does not mention any parameter meaning. The useful detail about the optional 'name' lives in the schema, not the description.
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 ('Update LLM session folder'), and the resource is precise enough to separate it from the session-level sibling put_strategy_llm_session_id. It does not, however, explicitly name or contrast any sibling, 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 guidance on when to use this versus put_strategy_llm_session_id (update the session) or post_strategy_llm_session_folder (create a folder), and no prerequisites or conditions are stated. Only the REST path is provided, which is not agent-facing usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update LLM session. PUT /api/v2/strategy/llm-session/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so safety is covered. The description adds nothing beyond the HTTP verb PUT; it does not state whether this is a full replacement or a partial update, what gets overwritten, or any auth/permission requirements for a mutation with a rich body.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short fragments, front-loaded with the action. It is efficient, though the raw endpoint URL is largely redundant with the tool name and the brevity borders on under-specification rather than tightness.
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 complex mutation with a deeply nested configuration body and no output schema, the description does far too little: it never explains the update contract, the many configurable fields, or what identifies/affects the target session.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Reported schema description coverage is 0% and the top-level id and body parameters are undocumented in the description. The nested body properties do carry schema-level descriptions, but the description itself adds no meaning beyond them, leaving the id and overall body contract unexplained.
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 (Update) and resource (LLM session), which is clear. However, it does not distinguish itself from closely-named siblings like put_strategy_llm_session_id_public, _reset, or _status, so an agent cannot tell which variant to pick from the description alone.
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 no when-to-use context, no prerequisites, and no comparison to the sibling tools that also mutate the same resource (public/reset/status variants, folder moves). Usage must be inferred entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update LLM session public visibility. PUT /api/v2/strategy/llm-session/{id}/public
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveHint=false, so the mutation boundary is known, but the description adds nothing beyond the raw endpoint path. It does not say whether the change is idempotent, what permissions are required, or what happens to the existing shared/private state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the purpose front-loaded before the endpoint reference; nothing is padded. It is appropriately sized but borders on under-specified for a mutation endpoint.
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 a nested body object, no output schema, and zero schema annotation coverage, the description is too thin. It omits side effects, response shape, and any confirmation of what the boolean toggles.
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% and the description never mentions parameters; only the raw path string hints at the {id} mapping. It does not clarify that the body's boolean sets visibility on/off, leaving the 2 required params to be inferred entirely from 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+resource combination ('Update LLM session public visibility'), which is distinguishable from the sibling put_strategy_llm_session_id_status and put_strategy_llm_session_id_reset. It does not explicitly name those siblings, but the resource noun 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?
No when-to-use guidance and no mention of alternatives (e.g. the sibling status/reset endpoints or get_public_llm_session). The agent gets no condition that selects this tool over its near-identical siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reset LLM session triggers, history or responses. PUT /api/v2/strategy/llm-session/{id}/reset
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is partly covered. The description adds useful context by enumerating what is reset (triggers, storage/response history), but says nothing about irreversibility, required auth, or the response. Note the tension: clearing stored history is arguably destructive while destructiveHint=false, though 'reset' can reasonably mean restore-to-default rather than destroy.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the action front-loaded; nothing is padded. The trailing HTTP endpoint adds locational context at little cost, though it is largely derivable from the tool name.
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?
With no output schema, the description should say more about what a successful reset returns and whether the operation is reversible. It covers the what and the endpoint, but omits permissions, irrevocability, and result shape for a state-mutating tool with a nested body.
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?
Top-level schema coverage is 0%, but the nested body properties carry their own boolean descriptions ('Set true to reset storage', etc.). The description names the three reset targets, loosely mapping to those fields, but adds no clarity on the 'id' path parameter or the true=enable boolean semantics beyond what the schema states.
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 concrete verb ('Reset') and the resource it acts on (LLM session triggers, history or responses), which is more specific than the bare name. It does not explicitly differentiate itself from close siblings such as put_strategy_llm_session_id or put_strategy_code_id_reset, but the scope of what is reset is 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?
The description gives no indication of when to use this tool versus put_strategy_llm_session_id (update) or the sibling reset tools. No prerequisites, permissions, or side-effect warnings are stated, leaving the agent to infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update LLM session status. PUT /api/v2/strategy/llm-session/{id}/status
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds nothing behavioral beyond the URL: it doesn't say whether the status change is reversible, whether it restarts/stops a running session, or what constraints exist — and the name and endpoint already convey the same information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded fragments with no filler. The endpoint restatement is low-value but costs almost nothing in length.
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 endpoint with two undocumented parameters, allowed additional properties on the body, and no output schema, the description does not supply enough for confident correct invocation. Against annotations that cover only the safety profile, the missing semantics of the status field and the operation's effect remain a real 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 0% for both parameters, so the description carries the full burden and fails: it never explains that 'id' is the LLM session identifier or what the ACTIVE/INACTIVE status values actually toggle. The body.status enum is visible in the schema, but the lifecycle meaning of the transition is left entirely unexplained.
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+resource ('Update LLM session status') and repeats the concrete endpoint path, so the agent knows exactly which resource is mutated. It does not explicitly distinguish itself from the many sibling status-updaters (put_strategy_code_id_status, put_webhook_bot_id_status, etc.), but the named 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?
No when-to-use guidance, no prerequisites, and no mention of the adjacent siblings (put_strategy_llm_session_id_public, _reset, or plain put_strategy_llm_session_id) that also target the same session. The agent must infer that this is the status-toggle variant purely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update code reaction folder. PUT /api/v2/strategy/reaction/code/folder/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Folder ID | |
| body | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that, merely restating the operation and echoing the HTTP verb/path; it never says the call renames an existing folder or what happens when the body is empty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no filler. The HTTP path restatement is largely redundant with the tool name, costing it a point, but nothing is wasted or buried.
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 output schema, the description should at least say the folder is renamed and what a successful response yields. It omits this, so an agent knows the endpoint but not the observable behavior or 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?
Schema coverage is at the 50% boundary: 'id' and the nested 'name' are documented, but the 'body' wrapper is not, and the description mentions no parameters at all. It therefore contributes no meaning beyond the schema and does not compensate for the undocumented wrapper.
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 ('Update code reaction folder'), and the 'reaction code' qualifier distinguishes it from the code-folder and reaction-llm-folder siblings. It is clear enough to select, though 'update' understates that the only mutable field is the name.
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 on when to use this versus post_strategy_reaction_code_folder (create) or delete_strategy_reaction_code_folder_id (remove), even though those siblings sit right next to it. The agent must infer that this is the rename/rename-folders route 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.
Update code reaction. PUT /api/v2/strategy/reaction/code/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered, but the description adds almost nothing on top of that. It does not explain PUT semantics (full replace vs. merge), what happens to body fields that are omitted, permission requirements, or side effects of changing code/signals on a running reaction.
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?
It is compact and front-loaded, so nothing is bloated. However, the second sentence is a raw endpoint string that adds negligible selection or invocation value on top of the tool name, and the overall brevity comes at the cost of substance rather than through efficiency.
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 a large nested body, two required top-level params, no output schema, and no annotation detail about side effects, the description is far too thin. An agent cannot learn from it whether the update replaces or merges fields, what the required data_webhook_id/code pair implies, or what to expect on success.
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?
Top-level schema description coverage is 0%: neither id nor the body wrapper is described, and the description supplies no parameter meaning to compensate. The nested body properties do carry descriptions in the schema, which limits the damage, but the description itself contributes zero semantic detail about which fields are honored on update.
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 verb and resource ("Update code reaction") but is essentially the tool name expanded, and it gives no way to tell this apart from close siblings such as put_strategy_reaction_llm_id, put_strategy_code_id, or the _public/_reset/_status variants. The appended HTTP path anchors it to an endpoint but does not clarify what a "code reaction" is or how it differs from an LLM reaction or a strategy code.
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 when-to-use or when-not-to-use guidance and no mention of alternatives, despite many near-identical put_* siblings for reactions, llm sessions, and strategies. An agent must infer from the name alone that this mutates an existing code reaction rather than creating, resetting, publishing, or toggling the status of one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update code reaction public visibility. PUT /api/v2/strategy/reaction/code/{id}/public
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds nothing behavioral beyond that – no note on ownership requirements, reversibility of toggling visibility, or effect on existing shares.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short fragments, zero filler, and the operation is front-loaded. It is arguably too terse for a mutation, but nothing is wasted.
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 with a nested object body, 0% parameter coverage, and no output schema, the description does too little. It never explains the id source, the body shape, or what success returns, leaving the agent reliant on schema inference.
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% for the two top-level parameters (id, body). The description mentions 'public visibility', which hints at the nested isPublic flag, but adds no meaning for the id or body envelope. It fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Update code reaction public visibility', which is meaningfully more precise than the bare name. An agent can tell it apart from the LLM/strategy variants conceptually, though the description never names siblings explicitly to disambiguate.
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 indication of when to use this versus alternatives such as put_strategy_code_id_public, put_strategy_reaction_code_id_status, or the delete counterparts. It only restates the operation with no context, exclusions, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reset code reaction triggers and/or storage. PUT /api/v2/strategy/reaction/code/{id}/reset
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, openWorldHint=false, destructiveHint=false, so the safety profile is partly covered. The description adds that triggers and/or storage are reset, but does not say whether the reset is reversible, what state is lost, or what permissions are needed — notable gaps for a state-mutating operation whose name ('reset ... storage') could plausibly destroy data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no filler; the operation and scope come first. The trailing endpoint URL is somewhat redundant against the tool name but does helpfully anchor the HTTP semantics.
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 output schema and a nested body object, the description is adequate but thin: it names the target state but omits reversibility, side effects, and the meaning of the required id. An agent can call it, but cannot fully anticipate the consequences.
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 nested body properties resetStore and resetTriggers already carry their own schema descriptions, and the description's 'triggers and/or storage' maps loosely onto them. But the required 'id' path parameter is unexplained in both description and schema, so the agent gets no help on what identifier to supply.
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 ('Reset') and the affected resources ('code reaction triggers and/or storage'), which is enough to separate it from sibling reset tools like put_strategy_reaction_llm_id_reset and put_strategy_code_id_reset by its 'code' scope. However, it never explicitly contrasts itself with those siblings, so differentiation is inferred from the name 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?
There is no when-to-use guidance, no preconditions, and no mention of alternatives such as put_strategy_reaction_code_id_status or the delete siblings. The agent must guess whether a reset or a status change is appropriate 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.
Update code reaction status. PUT /api/v2/strategy/reaction/code/{id}/status
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the write-vs-read question is covered. The description adds nothing beyond restating the HTTP method and path: it does not say whether the change is reversible, whether permissions are required, or what effect ACTIVATE/INACTIVATE has on a running reaction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler, front-loading the purpose before the endpoint. It is efficient, though the endpoint echo is redundant padding for an agent that already knows the tool name.
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?
This is a mutation tool with no output schema and minimal annotations, so the description should explain parameters, effect, and error/permission behavior. Instead it provides only a purpose sentence and the URL, leaving the agent under-informed for invoking it correctly among many similar sibling tools.
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 carries the full burden of explaining the two parameters, yet it mentions neither 'id' nor the status field. The only documentation of valid values is the nested enum inside the schema, which the description never references or explains.
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 clear verb+resource combination ('Update code reaction status') and repeats the REST endpoint, so the agent knows it mutates a reaction's status. It does not, however, distinguish itself from close siblings such as put_strategy_reaction_code_id or put_strategy_reaction_code_id_reset, so the specific scope of 'status' versus other mutations is left implicit.
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 guidance on when to use this tool instead of put_strategy_reaction_code_id, put_strategy_reaction_code_id_reset, or put_strategy_reaction_code_id_public, all of which act on the same resource. No prerequisites or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update LLM reaction folder. PUT /api/v2/strategy/reaction/llm/folder/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Folder ID | |
| body | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond restating the mutation and echoing the HTTP verb/path; it doesn't say what the update affects or that the body is optional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences and front-loaded, but the second sentence (the raw endpoint path) largely duplicates what the name already conveys rather than earning 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?
A mutation tool with a nested body object, no output schema, and no annotations covering reversibility or permissions. The description omits what the update does, what happens to unmentioned fields, and the auto-generated-name 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 coverage is only 50%. The description gives no parameter meaning at all, leaving the 'name is auto-generated if omitted' behavior and the id semantics entirely to the schema without compensation 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?
States a specific verb (update) and resource (LLM reaction folder), which separates it from the sibling put_strategy_reaction_llm_id that updates a reaction rather than a folder. Clear but relies on the tool name for finer differentiation.
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 when-to-use, prerequisites, or alternative guidance is given. The only context is the raw HTTP method and path, which does not tell an agent when to prefer this over post_strategy_reaction_llm_folder or put_strategy_reaction_llm_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update LLM reaction. PUT /api/v2/strategy/reaction/llm/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish this is a non-read-only, non-destructive mutation, and the description adds nothing on top of that. It does not say whether the body is a full replacement or a partial merge, what happens to omitted optional fields, or what permissions are needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the verb+resource front-loaded and no filler. It is efficiently sized, though the second sentence merely restates the endpoint path and adds no 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 tool with a deep nested body object, conditional field requirements, and no output schema, the description is far too thin. It explains no update semantics, no required-field behavior, and no relationship to the other put_*strategy_reaction_llm* variants.
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?
Top-level schema coverage is 0%: the id and body parameters carry no descriptions, and the description supplies none. With nested required fields (data_webhook_id, llm_api_id, prompt) and conditional requirements (webhook_id if send_signal, chart fields if use_chart), the description fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
"Update LLM reaction" names a verb and a resource, but it does nothing beyond restating the tool name and echoing the HTTP route. It gives no sense of what an LLM reaction is or which of the many strategy_reaction_llm siblings (public, reset, status) this one differs from.
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 when-to-use guidance at all. The description never distinguishes a plain update from put_strategy_reaction_llm_id_status, _public, or _reset, nor does it say an existing reaction must already exist. The agent must infer usage purely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update LLM reaction public visibility. PUT /api/v2/strategy/reaction/llm/{id}/public
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the mutation safety profile is covered. The description adds nothing beyond that: it does not say whether the change is reversible, who may flip visibility, or what happens on unsharing, and it wraps up with a redundant URL.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action and resource before the endpoint. The trailing 'PUT /api/v2/...' restates what the name and schema already encode, so it is not perfectly economical.
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 a nested body, no annotations explaining semantics beyond safety hints, and no output schema, the description should clarify ownership/permission requirements and the effect of flipping visibility. It provides none of that, leaving real gaps.
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% and the description carries no parameter detail. The nested 'isPublic' field happens to have an inline description in the schema, but the required 'id' path parameter is undocumented in both places, so the description fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Update') plus the resource and the exact facet being changed ('LLM reaction public visibility'), which distinguishes it from put_strategy_reaction_llm_id (content update) and _status/_reset siblings. It does not explicitly name or route to those alternatives, 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?
No statement of when to use this versus put_strategy_reaction_llm_id, _status, or _reset, and no prerequisites (ownership, published state, whether the reaction must already exist). The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reset LLM reaction triggers, history or responses. PUT /api/v2/strategy/reaction/llm/{id}/reset
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveHint=false, which is the safety profile the agent gets; the description adds nothing beyond that. It does not say whether a reset is recoverable, whether it interrupts a running strategy, whether all three flags must be true, or what happens to already-consumed triggers, which matters for a state-clearing 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?
One short sentence covering the action plus the endpoint path — front-loaded and waste-free. It is arguably too terse rather than bloated, which is an under-specification problem counted elsewhere.
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?
A mutation endpoint with no output schema, a nested required body, and no annotations beyond hints is under-described: the agent knows what is reset but not the effect, the response, or failure modes. The definition omits everything an agent would want before triggering an irreversible-sounding state clear.
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 reported at 0% for the top-level id/body params, though the nested booleans carry their own descriptions. The phrase 'triggers, history or responses' helps map the request to resetTriggers/resetStorage/resetResponse, but the description gives no indication that all three flags are required or what false values mean.
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 ('Reset') and resource ('LLM reaction triggers, history or responses'), with the endpoint path reinforcing the target. It distinguishes itself from code/session reset siblings by naming 'LLM reaction', but it never explicitly contrasts with put_strategy_reaction_code_id_reset or put_strategy_llm_session_id_reset.
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 when-to-use guidance, no prerequisites, and no mention of what state the strategy must be in before a reset is meaningful. The three reset axes imply use cases, but the agent must infer when this tool is the right call versus updating or deleting the reaction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update LLM reaction status. PUT /api/v2/strategy/reaction/llm/{id}/status
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that: it doesn't say the update is a status flip, that it targets an existing reaction, or what the effect of ACTIVE vs INACTIVE is. With annotations present the bar is lower, but this adds no context at all.
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 terse fragments with no filler and the action front-loaded. It avoids waste, though the brevity edges toward under-specification rather than genuine economy.
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 with a nested body, no output schema, and 0% schema description coverage, the definition is too thin. It leaves unstated whether the reaction must already exist, whether the change is reversible, and how the enum values map to 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 0% across 2 parameters including a nested body object, so the description must compensate and does not. It only implies that {id} identifies the reaction and 'status' is what changes, without explaining the ACTIVE/INACTIVE enum semantics or the body structure.
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?
"Update LLM reaction status" gives a specific verb and resource, so the action is understandable. But it essentially restates the tool name (put_strategy_reaction_llm_id_status) and offers no differentiation from close siblings like put_strategy_reaction_llm_id or put_strategy_reaction_llm_id_reset. Vague on scope relative to the family.
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 when-to-use guidance and no reference to alternatives, despite a large family of put_*_id_status and put_strategy_reaction_llm_id* tools. The agent must infer that this is the status-toggle variant 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.
Update bot webhook. PUT /api/v2/webhook/bot/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is partly covered. The description adds nothing about what gets updated, whether omitted body fields are cleared (PUT semantics), or auth requirements, leaving the mutation behavior opaque.
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?
Very short and front-loaded, with the verb+resource leading. The trailing 'PUT /api/v2/webhook/bot/{id}' largely restates the tool name and endpoint already encoded in the name, so it is mild redundancy rather than waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with a nested body object, no output schema, and partial annotation coverage, the definition omits whether the update is full or partial replacement, what fields are required in the body, and what a successful response looks like. An agent lacks enough to call it confidently.
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?
Top-level schema coverage is 0% for both id and body, and the description supplies no parameter information. The nested body properties carry their own descriptions, but the description itself does nothing to compensate for the undocumented top-level parameters, falling below the baseline for a 2-param tool.
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 ('Update bot webhook'), which lets an agent distinguish it from get_/delete_/post_webhook_bot siblings. It does not explicitly differentiate from the close-named put_webhook_bot_id_status, which also updates a bot webhook variant, 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?
No when-to-use guidance, no mention of alternatives, and no prerequisites (e.g., when to call this vs. put_webhook_bot_id_status). The agent must infer usage entirely from the name and endpoint path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update webhook status. PUT /api/v2/webhook/bot/{id}/status
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare it is a non-read-only, non-destructive, closed-world mutation, so safety is covered. The description adds nothing beyond that — it does not say whether the change is immediate, what deactivating a webhook actually stops, or whether it is reversible. It essentially restates the HTTP route.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short fragments, front-loaded with the action. It is not bloated, though the raw HTTP path adds little value to an agent that already has the tool name and schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with a nested body, 0% parameter documentation, and no output schema, the description is too thin. An agent cannot confirm which entity it mutates or what the status change implies operationally.
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 carries the burden and fails: it never explains that 'id' identifies the webhook bot or what ACTIVE/INACTIVE actually enable or disable. The path fragment '{id}' in the description is the only hint, and the nested body object's semantics are left entirely to 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 clear verb+resource: 'Update webhook status'. An agent can tell it changes the status flag of a webhook bot rather than its other fields. It does not, however, explicitly differentiate itself from adjacent siblings like put_webhook_bot_id or put_webhook_data_id_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no prerequisites, and no mention of alternatives such as delete_webhook_bot_id (remove) or put_webhook_bot_id (edit other fields). The reader must infer usage purely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update data webhook. PUT /api/v2/webhook/data/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is covered, but the description adds nothing beyond them. It does not say whether the update is a full replace or a partial merge, what happens to omitted fields, whether permissions/ownership are required, or how the hook behaves after modification.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, verb and resource front-loaded, with the endpoint appended compactly. There is no filler, though the terseness means it omits useful substance rather than being over-long.
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 that takes a nested body object with no output schema and no annotation detail, the description is nearly silent: no field semantics, no update semantics, no side effects, and no return information. An agent has to guess at much of the call's contract.
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 reported at 0% for the top-level id and body parameters, and the description supplies no parameter meaning at all. The nested body fields (name, is_safe, hash_key, description) are documented in the schema itself, so the description neither compensates for the top-level gap nor adds anything new.
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 (Update) and resource (data webhook), plus the HTTP endpoint PUT /api/v2/webhook/data/{id}, so the agent knows it is a mutation on an identified webhook. It does not differentiate from close siblings such as put_webhook_data_id_status (status-only update) or put_webhook_data_* variants, leaving the agent to 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?
No guidance on when to use this versus put_webhook_data_id_status, delete_webhook_data_id, or post_webhook_data. There are no prerequisites, exclusions, or alternative routing hints, so usage must be inferred entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update webhook status. PUT /api/v2/webhook/data/{id}/status
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered externally. The description adds nothing beyond that — it doesn't say the status field is a toggle, whether the change is reversible, or whether authorization is required, so it contributes no behavioral context of its own.
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?
Very short and front-loaded, which is good, but the second sentence merely restates the tool name as a REST path and adds no information. It is under-specified rather than genuinely 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 mutation tool with a nested body, 0% parameter documentation, and no output schema, the description leaves the agent guessing what the endpoint changes and what the status values mean. It is not complete enough to call the tool confidently.
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% and there are two required parameters, so the description carries the full burden of explaining them. It provides no information about the id path parameter or the enum-constrained status values (ACTIVE/INACTIVE), falling short of compensating for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a verb and resource ('Update webhook status'), so the general purpose is legible. However, it fails to differentiate from close siblings such as put_webhook_bot_id_status and put_webhook_data_id — 'webhook status' could describe either, and only the tool name disambiguates that this targets webhook data.
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 when-to-use guidance is given: nothing says when to flip a status versus calling put_webhook_data_id for a full update, or when ACTIVE vs INACTIVE is appropriate. The path string is a routing artifact, not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replaces template variables in a llm-reaction prompt template with values and returns the final prompt.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | ||
| prompt | Yes | ||
| request | No | ||
| withSystemPrompt | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and closed-world, so the safety profile is covered. The description adds that this is a pure transform that returns the final prompt, but it does not disclose which template variable names are supported or how state/request values are bound into them, which is the core behavior an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero filler; the transformation and its return value come first. It is efficient, though arguably too terse given the tool's nested parameters.
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 nested 4-parameter tool with 0% schema descriptions and no output schema, the description is inadequate: it omits the shape of state/request, the effect of withSystemPrompt, and any indication of which template variables exist or what error occurs on unknown variables.
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% with four parameters, two of them nested objects (state, request). The description vaguely says 'variables ... with values' but never maps prompt, state, request, or withSystemPrompt to any template variable, so it fails to compensate for the schema 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?
States a specific verb and resource: 'Replaces template variables in a llm-reaction prompt template with values and returns the final prompt.' It is clearly distinct from generic read/write siblings by name, but it never explicitly differentiates itself from the near-identical sibling resolve_llm_session_prompt_template, leaving the agent to infer the reaction-vs-session scope from the name alone.
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 when-to-use guidance, no prerequisites, and no mention of the sibling resolve_llm_session_prompt_template, which is the obvious alternative an agent must choose between. The only signal is the implied 'resolve a template before use' flow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replaces template variables in a llm-session prompt template with values and returns the final prompt.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | ||
| prompt | Yes | ||
| withSystemPrompt | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the pure-transformation nature is covered. The description adds only that it returns the final prompt, but says nothing about the template variable syntax, where substitution values come from, or how 'state' influences resolution 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?
A single front-loaded sentence with no filler; the core action is stated immediately. It is efficient, though it is so terse that it omits necessary context rather than being maximally 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?
With no output schema, a nested state object, and 3 parameters at 0% schema coverage, the definition should carry much more weight. It omits parameter roles, the template syntax, and return structure, leaving the agent unable to invoke it reliably.
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% across 3 parameters, including a nested 'state' object and the unexplained 'withSystemPrompt' flag. The description implies variables are replaced 'with values' (hinting at 'state') but never maps any parameter to its role, so it fails to compensate for the documentation 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?
States a specific verb and resource ('Replaces template variables in a llm-session prompt template') plus the outcome ('returns the final prompt'). The 'llm-session' qualifier distinguishes it from the sibling resolve_llm_reaction_prompt_template, though it never names that alternative explicitly.
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 only states what the tool does; it gives no when-to-use context, no prerequisites, and no indication of when to pick this over resolve_llm_reaction_prompt_template or how the resulting prompt should be consumed. The agent must infer usage entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search across the documentation to find relevant information, code examples, API references, and guides. Use this tool when you need to answer questions about Sigrex Documentation, find specific documentation, understand how features work, or locate implementation details. The search returns contextual content with titles and direct links to the documentation pages.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, covering the safety profile. The description adds value on top by disclosing the return shape ('contextual content with titles and direct links'), which annotations cannot convey, though it omits ranking/pagination 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?
Three sentences that are front-loaded, with the core action stated first, then usage, then return behavior. Efficient, with only minor redundancy between the first sentence's content list and the second sentence's use cases.
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?
With no output schema, the description steps in to describe the return ('titles and direct links'), which is exactly what an agent needs. The remaining gap is the undocumented query parameter, but overall it is complete enough for a single-param read tool whose annotations cover safety.
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 one required parameter (query) with 0% schema description coverage, so the description carries the full burden of explaining it. It only implies a free-text search string and gives no guidance on syntax, natural-language vs. keyword input, or filtering — insufficient compensation for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (search) and resource (documentation) and enumerates the content types returned: information, code examples, API references, guides. However, it does not distinguish itself from the sibling askQuestion, which is a plausible alternative for answering doc questions, so sibling differentiation is missing.
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 when-to-use guidance: 'answer questions about Sigrex Documentation, find specific documentation, understand how features work, or locate implementation details.' It does not, though, state when NOT to use it or name the sibling alternatives (askQuestion, getPage) that would route an agent differently.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a message to the bot hook. It can send trading signals, trading orders to a specific webhook for execution.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | The key of the webhook, if the webhook is protected by a key | |
| hash | Yes | The hash of the webhook, you can get it from the webhook URL. The last part of the URL is the hash. eg.:3e39b91e-1f50-4a49-9f1c-23476f83b203 | |
| payload | Yes | The payload to send to the webhook |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=false, and the description usefully adds that the message triggers real order execution on a webhook, which is the key consequence. It stops short of disclosing delivery behavior, failure handling, or what happens when the hash/key is invalid, so it does not meaningfully exceed annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the verb and target, with no filler. The second sentence slightly restates 'send' from the first, but it earns its place by naming what is actually transmitted and why (execution).
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 destructive, nested-payload, no-output-schema tool that can trigger live order execution, the description is minimal: it does not explain post-invocation behavior (results going to the optional callback), nor how it relates to send_data_hook_message. The rich schema and annotations carry most of the load, leaving this adequate but thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the nested payload (symbol, side, size, flags, callback, dilution, forceSize) is documented in detail in the schema itself. The description adds nothing parameter-level, so the baseline 3 applies even though it gestures at 'trading signals, trading orders'.
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 verb (send) and resource (a message to the bot hook) and clarifies the payload can be trading signals or trading orders delivered to a webhook for execution. That is clear, but it never differentiates itself from the near-identical sibling send_data_hook_message, so an agent must infer the split from the tool name alone.
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 when-to-use guidance and no mention of alternatives such as send_data_hook_message, which is the obvious competing tool. The description only implies the tool's domain (trading signals/orders to a webhook) without stating prerequisites or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a JSON message to the data hook. It can send data to a specific webhook for data processing.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | The key of the webhook, if the webhook is protected by a key | |
| data | Yes | The data to send to the webhook this can be any JSON object | |
| hash | Yes | The hash of the webhook, you can get it from the webhook URL. The last part of the URL is the hash. eg.:3e39b91e-1f50-4a49-9f1c-23476f83b203 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true and openWorldHint=false, but the description's benign framing ('send a JSON message') adds no behavioral context and never hints at any destructive or side-effecting outcome, nor whether the call is fire-and-forget or awaited. It leaves the significant destructiveHint entirely unexplained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, but the second is near-redundant with the first ('send data to a specific webhook' repeats 'send a JSON message to the data hook'), so it does not fully earn 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 mutating tool flagged destructive with no output schema, the description omits what happens after the send, whether delivery is synchronous, and any failure behavior. It is too thin for the operation's risk profile.
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% (hash, data, and key are all documented in the schema), so the baseline is 3. The description adds no parameter meaning beyond the schema, e.g. no clarification of the key/data relationship.
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 (Send) and resource (JSON message / data hook / webhook), so an agent knows this posts JSON payloads to a hook endpoint. The second sentence largely restates the first and does not distinguish it from the sibling send_bot_hook_order_message, leaving differentiation to the name alone.
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 on when to use this versus send_bot_hook_order_message or the post_webhook_data family. Nothing states prerequisites such as needing a hook configured first, or when the optional key is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report an issue in the documentation of Sigrex Documentation so the team can fix it. Use it whenever, while helping a user, you come across content that is outdated, contradictory, missing information, or otherwise unhelpful. Also use it when the user themselves reports a problem with the docs, even if you could not verify it yourself. If it's your own observation, do a quick sanity check that the issue is real before reporting — no need to exhaustively re-read the page. Send one call per distinct issue and do not report the same issue twice in a conversation. Do not use this tool to confirm that a page is accurate; it is for reporting problems only.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | No | The broader end goal you were ultimately trying to accomplish (as/on behalf of the user) when you hit this issue. Gives the team the context you were working towards. Optional. | |
| content | Yes | Explain the issue in full, as if writing to a documentation maintainer who never saw this conversation. Describe what is wrong, where on the page it appears (quote the exact sentence or section title when possible), what the user was trying to do, and, when relevant, what the correct or expected information should be. Write a few clear, specific sentences in English. Never include personal or confidential information from the conversation. Up to 2048 characters. | |
| pageUrl | Yes | The full URL of the page the issue is about (e.g. https://docs.sigrex.io//getting-started), so the finding is linked to the exact page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, so the write/side-effect profile is known; the description confirms this by framing the tool as a submission the team acts on. It adds real behavior beyond annotations: one call per distinct issue, no duplicate reports per conversation, and a sanity-check expectation before reporting. It does not say whether feedback is rate-limited or what confirmation comes back, which keeps it out of the top band.
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 before the detailed triggers, and every sentence carries a rule or constraint rather than filler. It is on the long side and the de-duplication rule could be tightened, but nothing 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 3-parameter, no-output-schema reporting tool, the description supplies the trigger conditions, preconditions, and de-duplication policy an agent needs. The one gap is that with no output schema, the description never says what a successful submission returns or looks like.
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 all three parameters (goal, content, pageUrl) are already fully documented in the schema, including format, character limit, and confidentiality rules. The description adds no parameter-level meaning beyond that, 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 ('Report an issue in the documentation of Sigrex Documentation') plus the consequence ('so the team can fix it'). The closing exclusion ('Do not use this tool to confirm that a page is accurate') sharply bounds the purpose against the nearest read-oriented siblings like getPage/searchDocumentation.
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?
Explicit triggers are enumerated (outdated, contradictory, missing information, unhelpful) and it covers the indirect case ('when the user themselves reports a problem... even if you could not verify it yourself'). It also gives a precondition (do a quick sanity check) and an anti-pattern (do not use to confirm accuracy), leaving almost nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
askQuestiondelete_api_exchange_iddelete_api_llm_iddelete_api_prediction_iddelete_bot_signal_cex_folder_iddelete_bot_signal_cex_iddelete_bot_signal_dex_folder_iddelete_bot_signal_dex_iddelete_bot_signal_prediction_folder_iddelete_bot_signal_prediction_iddelete_strategy_code_folder_iddelete_strategy_code_iddelete_strategy_code_id_storedelete_strategy_llm_session_folder_iddelete_strategy_llm_session_iddelete_strategy_reaction_code_folder_iddelete_strategy_reaction_code_iddelete_strategy_reaction_code_id_storedelete_strategy_reaction_llm_folder_iddelete_strategy_reaction_llm_iddelete_webhook_bot_iddelete_webhook_bot_share_iddelete_webhook_data_iddelete_webhook_data_share_idget_account_friend_all_statusget_account_friend_rejectedget_account_friend_status_sideget_account_meget_api_exchangeget_api_exchange_bot_signal_idget_api_llmget_api_llm_models_serviceIdget_api_llm_servicesget_api_predictionget_api_prediction_bot_signal_idget_bot_signal_cexget_bot_signal_cex_folderget_bot_signal_cex_folder_idget_bot_signal_cex_folder_rootget_bot_signal_cex_idget_bot_signal_cex_totalget_bot_signal_dexget_bot_signal_dex_chainId_addressget_bot_signal_dex_factory_chainId_exchangeIdget_bot_signal_dex_folderget_bot_signal_dex_folder_idget_bot_signal_dex_folder_rootget_bot_signal_dex_idget_bot_signal_dex_totalget_bot_signal_predictionget_bot_signal_prediction_folderget_bot_signal_prediction_folder_idget_bot_signal_prediction_folder_rootget_bot_signal_prediction_idget_bot_signal_prediction_market_exchange_slugget_bot_signal_prediction_totalget_exchangeget_exchange_cexget_exchange_dex_chainget_exchange_predictionget_exchange_with_exchange_rateget_log_data_hook_hookId_paginatedget_log_data_paginatedget_log_error_idget_log_error_paginatedget_log_error_source_idget_log_signal_hook_hookId_paginatedget_log_signal_paginatedget_log_signal_source_id_paginatedget_log_signal_source_paginatedget_log_transactionget_log_transaction_bot_signal_type_service_idget_log_transaction_idget_public_code_reactionget_public_code_strategyget_public_llm_reactionget_public_llm_sessionget_strategy_codeget_strategy_code_folderget_strategy_code_folder_idget_strategy_code_folder_rootget_strategy_code_idget_strategy_code_totalget_strategy_llm_sessionget_strategy_llm_session_folderget_strategy_llm_session_folder_idget_strategy_llm_session_folder_rootget_strategy_llm_session_idget_strategy_llm_session_totalget_strategy_reaction_codeget_strategy_reaction_code_folderget_strategy_reaction_code_folder_idget_strategy_reaction_code_folder_rootget_strategy_reaction_code_idget_strategy_reaction_code_totalget_strategy_reaction_llmget_strategy_reaction_llm_folderget_strategy_reaction_llm_folder_idget_strategy_reaction_llm_folder_rootget_strategy_reaction_llm_idget_strategy_reaction_llm_totalget_symbol_priceget_webhook_botget_webhook_bot_bot_signal_id_cexget_webhook_bot_bot_signal_id_dexget_webhook_bot_bot_signal_id_predictionget_webhook_bot_idget_webhook_bot_id_sharesget_webhook_bot_sharedget_webhook_bot_shared_by_idget_webhook_bot_shared_with_idget_webhook_dataget_webhook_data_idget_webhook_data_id_code_reactionsget_webhook_data_id_llm_reactionsget_webhook_data_id_sharesget_webhook_data_sharedget_webhook_data_shared_by_idget_webhook_data_shared_with_idgetPagelist_all_public_code_reactionlist_all_public_code_strategylist_all_public_llm_reactionlist_all_public_llm_sessionpost_api_exchangepost_api_exchange_testpost_api_llmpost_api_predictionpost_api_prediction_testpost_bot_signal_cexpost_bot_signal_cex_duplicatepost_bot_signal_cex_folderpost_bot_signal_dexpost_bot_signal_dex_folderpost_bot_signal_predictionpost_bot_signal_prediction_duplicatepost_bot_signal_prediction_folderpost_strategy_codepost_strategy_code_duplicatepost_strategy_code_folderpost_strategy_llm_sessionpost_strategy_llm_session_duplicatepost_strategy_llm_session_folderpost_strategy_reaction_codepost_strategy_reaction_code_duplicatepost_strategy_reaction_code_folderpost_strategy_reaction_llmpost_strategy_reaction_llm_duplicatepost_strategy_reaction_llm_folderpost_webhook_botpost_webhook_bot_share_idpost_webhook_datapost_webhook_data_share_idput_api_exchange_id_statusput_api_llm_id_modelput_api_prediction_id_statusput_bot_signal_cex_folder_idput_bot_signal_cex_idput_bot_signal_cex_id_statusput_bot_signal_dex_folder_idput_bot_signal_dex_idput_bot_signal_dex_id_statusput_bot_signal_prediction_folder_idput_bot_signal_prediction_idput_bot_signal_prediction_id_statusput_strategy_code_folder_idput_strategy_code_idput_strategy_code_id_publicput_strategy_code_id_resetput_strategy_code_id_statusput_strategy_llm_session_folder_idput_strategy_llm_session_idput_strategy_llm_session_id_publicput_strategy_llm_session_id_resetput_strategy_llm_session_id_statusput_strategy_reaction_code_folder_idput_strategy_reaction_code_idput_strategy_reaction_code_id_publicput_strategy_reaction_code_id_resetput_strategy_reaction_code_id_statusput_strategy_reaction_llm_folder_idput_strategy_reaction_llm_idput_strategy_reaction_llm_id_publicput_strategy_reaction_llm_id_resetput_strategy_reaction_llm_id_statusput_webhook_bot_idput_webhook_bot_id_statusput_webhook_data_idput_webhook_data_id_statusresolve_llm_reaction_prompt_templateresolve_llm_session_prompt_templatesearchDocumentationsend_bot_hook_order_messagesend_data_hook_messagesendFeedback
Add one secure layer between your agents and this server.