AIWorkers MCP
Server Quality Checklist
Latest release: v0.3.13
- Disambiguation5/5
Each tool targets a specific resource and action, with detailed descriptions that clearly distinguish purposes. Even within similar domains (e.g., multiple quote/confirm pairs), the resource (salary, tt, broadcast) is explicit, preventing confusion.
Naming Consistency5/5The naming follows a predictable pattern: each functional area uses a consistent prefix (e.g., workers_, survey_, tasks_) and verb_noun or noun_verb structure within that area. There is no mixing of conventions across the server.
Tool Count2/5With 59 tools, the count is excessive for a single MCP server. While the domain is broad, it exceeds the recommended range and would likely overwhelm agents. Splitting into sub-servers (e.g., surveys, workers, tasks) would improve usability.
Completeness4/5The tool surface covers nearly all aspects of the AI Workers platform: account, workers, surveys, tasks, memory, chats, broadcasts, ready replies, Telegram commands, and CRM. Minor gaps exist, such as no tool for listing chat message history or editing worker groups, but core workflows are well-supported.
Average 3.1/5 across 59 of 59 tools scored. Lowest: 1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden of behavioral disclosure. The description mentions 'auth, endpoints, group-bound token' but does not explain what operations are performed, whether data is mutated, what permissions are needed, or any side effects. This is almost entirely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (5 words), but it is not concise in a helpful way. It omits essential information, making it under-specified rather than efficient. Every word should earn its place, but here the words are vague and uninformative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, an output schema, and many siblings, the description is far from complete. It does not explain the tool's purpose, its input/output behavior, or how it relates to other survey agent tools. The presence of an output schema reduces the need to document return values, but the description still fails to provide basic context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage (one parameter), but the description adds no meaning to the 'format' parameter. The parameter's purpose, allowed values, and effect are not described. With 0% schema description coverage, the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Agent skill: auth, endpoints, group-bound token' is cryptic and does not clearly state what the tool does. It fails to identify any verb or resource, and it does not distinguish the tool from its many siblings like survey_agent_get or survey_agent_update. The name suggests it relates to survey agent skills, but the description offers no actionable purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With over 30 sibling tools, the description offers no context for selection, no prerequisites, and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions 'No native open-in-chat widget' which is an important limitation, but overall it lacks details about side effects, required permissions, or what happens during execution. The description is insufficient for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two fragments), but it fails to provide necessary information. This is underspecification rather than conciseness, though the structure is not padded with unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is an output schema but no parameter descriptions, the tool lacks essential clarity. The description does not explain return values or the tool's core purpose, making it inadequate for correct selection and invocation, especially among many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter, 'survey_id', with no description. Since schema description coverage is 0%, the description must add meaning, but it does not explain what 'survey_id' represents or how it should be used. The cryptic reference to 'form_url + chat_text' does not clarify the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is ambiguous: 'form_url + chat_text for workers_chat_send / readyreply' suggests some combination of a form URL and chat text, but it's not clear what action the tool performs. It does not clearly state a verb and resource, and the tool name 'survey_agent_share' implies sharing, but the description does not confirm this.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 context about prerequisites, use cases, or exclusions is provided, and the sibling tools include many survey and chat-related tools without any differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states that the tool creates a topic, implying mutation. It does not disclose any behavioral traits such as idempotency, error conditions, side effects, or output behavior. The existence of an output schema is not mentioned, so the agent cannot infer what the tool returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence), but it is under-specified. Conciseness here comes at the cost of completeness; it does not earn its place as it lacks essential details. There is no structure guiding the agent on how to use the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters with no description, no required parameters, an output schema that is not mentioned, and no annotations, the description is severely incomplete. The agent cannot reliably use this tool based on the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description provides no information about the two parameters ('name' and 'group_id'). The description does not explain what values these parameters accept, their purpose, or defaults. The agent must guess or rely on parameter names alone, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new memory forum topic' uses a specific verb ('create') and resource ('memory forum topic'), making it clear what the tool does. It distinguishes from sibling tools like workers_memory_add (likely adding to an existing topic) and workers_memory_get (retrieving topics). However, the term 'memory forum topic' is somewhat vague and could be more precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that it is for creating a new topic (as opposed to adding to an existing one), nor does it specify any prerequisites, context, or exclusions. The agent has no help in deciding when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It merely indicates non-destructive read behavior, but fails to mention permissions, side effects, response characteristics, or any constraints beyond the read-only nature. This is insufficient for safe agent invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that avoids fluff, but it is under-specified. While concise, it sacrifices completeness for brevity, making it borderline adequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (so return values are covered) and low complexity (one required parameter), the description fails to clarify what 'survey settings' includes beyond 'view mode', or how the survey_id relates to them. It leaves gaps that the agent must infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no information about the sole parameter 'survey_id'—its format, source, or purpose. The description does not compensate for the missing schema documentation, leaving the agent without parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and resource 'survey settings' with an example ('view mode'), making the purpose clear. However, it does not differentiate from sibling tools like 'survey_agent_get', which might also read survey data, so it loses a point for lack of distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'survey_agent_settings_save' or 'survey_agent_get'. There is no mention of prerequisites, context, or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'update', implying mutation, but omits critical details: atomicity, partial failure handling, permission requirements, or side effects. For a batch operation, this lack of transparency is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the core concept. However, it could expand slightly to cover the missing group_id parameter without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, return values need not be fully described, but the description still lacks essential context: the role of group_id, scope of updates (e.g., which fields are allowed), and behavioral expectations. Among many task siblings, this tool's specific functionality and constraints are under-explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains the format of updates_json (JSON array of {id, ...fields}), which adds value, but completely ignores the group_id parameter. No details on allowed fields, required keys, or validation rules are given, leaving the agent underinformed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Batch update' and specifies the input format (JSON array of {id, ...fields}), making the verb and resource clear. However, it does not differentiate from sibling tools like tasks_update (single update) or tasks_complete, missing an opportunity to clarify this is a batch variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. There is no indication of when to use batch update vs. alternatives (e.g., repeated calls to tasks_update), no mention of prerequisites, and no exclusions. The description purely focuses on input format.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided to describe safety or behavior, the description is the sole source of behavioral info. It does not disclose if the operation is idempotent, requires specific authentication (though likely implicit), or if there are rate limits or side effects (e.g., triggers, notifications). A mutation tool updating tasks needs more 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short with only 9 words. While brief, it front-loads the action. However, it sacrifices clarity and completeness for brevity, leaving out critical details about the patch_json format and parameter roles. It feels rushed rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no annotations and low schema coverage, the description fails to explain what the return value contains (though output schema exists). It also repeats patch_json fields vaguely. For a mutation tool in a suite with many similar tools, this under-specifies, making it hard for the agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'patch_json: JSON object with title/description/status/dates', but the input schema does not specify any allowed properties for patch_json (0% schema description coverage). The description only covers part of patch_json's structure and omits group_id semantics. Given the low schema coverage, the description does not compensate enough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Update task fields' which clearly identifies the verb (update) and resource (task). However, it lacks differentiation from sibling tools like 'tasks_batch_update' or 'tasks_complete'. The description could be misinterpreted without considering the tool name itself, but it is functional.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like 'tasks_batch_update' or 'tasks_cancel'. There is no mention of prerequisites, whether partial updates are allowed, or error handling. The agent receives no context to make an informed selection decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only reveals that message logs are excluded, but omits other critical traits such as ordering, pagination behavior, rate limits, handling of empty results, or any authentication requirements. The single behavioral trait is insufficient for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at five words, but this brevity comes at the cost of completeness. It front-loads the core action but fails to include essential details about parameters, behavior, or output. True conciseness balances brevity with informativeness; this description is underspecified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and two parameters, the description is only five words and does not explain the semantics of the parameters, the structure of the output, or any edge cases. The sibling tools provide some context, but the description itself is too sparse to be considered complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the input schema provides no descriptions for the parameters 'limit' and 'group_id'. The tool description does not add any meaning beyond the parameter names and default values. An agent cannot infer the purpose of 'group_id' or how 'limit' interacts with the result set from the description alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List user chats (no message logs)' clearly states the verb (list) and resource (user chats). It distinguishes from sibling tools like workers_chats_get and workers_chat_send by explicitly excluding message logs, which is a helpful differentiator. However, it does not elaborate on what constitutes a 'user chat' in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as workers_chats_get or workers_chat_send. It does not specify prerequisites, limitations, or exclusive scenarios. The only hint is the exclusion of message logs, which implicitly suggests using this tool when logs are not needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden. It only states the action (create) but omits behavioral details like whether the operation is idempotent, required permissions, side effects, or error conditions. The presence of an output schema does not compensate for missing transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise and free of fluff. However, it is underspecified for a tool with two undocumented parameters and no annotations, making it minimally adequate rather than efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 parameters, no required fields, and 0% schema coverage), the description is incomplete. It fails to describe parameter semantics, return values (though output schema may help), or usage context. The agent lacks sufficient information to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters (name, group_id) with 0% schema description coverage. The description does not explain what these parameters do, their expected format, or how they relate to the tool's purpose. The agent receives no additional meaning beyond the schema's basic types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a Telegram topic for ready replies, using a specific verb and resource. However, it does not differentiate from sibling tools like workers_memory_create_topic or other readyreply operations, which share similar naming.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., workers_readyreply_list, workers_readyreply_upsert). There is no mention of prerequisites, such as needing a group_id or when to avoid calling this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It states 'delete', implying destruction, but does not explain if the action is irreversible, what happens if the id does not exist, or any permissions needed. The description is too sparse to adequately convey the tool's effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
While very concise (one sentence), the brevity comes at the cost of essential details. The description is under-specified rather than efficiently informative. It fails to earn its place because it does not add enough value beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (two parameters, destructive action) and lack of annotations, the description is too incomplete. It omits information about return values (even though an output schema exists), error handling, and the role of group_id. An agent cannot operate this tool safely or effectively with only this description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It only implicitly covers rr_id by saying 'by id', but provides no explanation for the optional group_id parameter (its purpose, default behavior). The agent cannot determine how to use group_id correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the resource 'ready reply', and identifies the key parameter 'by id'. It sufficiently distinguishes from sibling tools (list, upsert, create_topic) by specifying the destructive action. However, it does not define what a 'ready reply' is, which is context that could aid an agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other ready reply tools (e.g., list, upsert). No prerequisites like needing an rr_id from a previous list call are mentioned. The agent is left to infer usage entirely from the tool name and minimal description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It does not mention whether this is a read or write operation, whether it has side effects, what permissions are needed, or what happens if inputs are invalid. The phrase 'Resolve...context' hints at a lookup but is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the key action and resource. It contains no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 optional parameters, no annotations, and a clear sibling set, the description is insufficient. It does not explain parameter semantics, behavioral traits, or how this tool differs from related tools. An output schema exists but the description does not hint at what it returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should explain what the two parameters ('group_id' and 'username') represent. It does not describe either parameter's meaning beyond the schema titles. However, the tool name and purpose strongly imply these are identifiers for a Telegram group and user, so the gap is partially mitigated by context. Baseline 3 is appropriate given no param descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Resolve' and specifies the resource 'Booking CRM context' with 'linked Telegram group and topic keys'. This gives a general sense of the tool's purpose, but 'Resolve' is somewhat vague and does not clearly differentiate the tool from siblings like 'crm_process' or 'workers_memory_get'. The purpose is adequate but not sharp.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. Given the sibling list includes 'crm_process' and several 'workers_memory' tools that could relate to CRM context, the lack of usage context or exclusions is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions that a mismatch in group_id leads to a 403 error, which is good. However, it does not disclose other critical behaviors, such as whether the operation is destructive, whether it requires authentication, or what side effects it has (e.g., does it modify something?).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences), which is good for conciseness. However, it lacks structure and important information about parameters. It is not overly verbose, but it sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, 1 required) and the existence of an output schema, the description should at least cover the key parameters and explain the return value context. It barely addresses the group_id constraint but ignores dsl and creator_id, leaving the agent without sufficient guidance for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning the description must explain all parameters. It only briefly mentions group_id and its constraint but says nothing about dsl (the required parameter) or creator_id. The description fails to add meaningful context beyond what the schema provides for dsl and creator_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a survey') and the method ('from DSL'). It also mentions a key constraint about the group_id. However, it does not distinguish it from sibling tools like survey_validate_dsl or survey_agent_get, which are related but handle different aspects of surveys.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 its siblings. It mentions a specific constraint (group_id must match or be omitted) but does not explain the context or prerequisites for using the tool, such as when a group_id is needed or what happens if it is omitted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It mentions "Syncs Bot API menu, no chats" which indicates a syncing effect without side effect on chats. However, it does not state whether old commands are overwritten, if permissions are needed, or what happens on failure. Acceptable but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (3 lines) and front-loaded, with no wasted words. Every sentence adds a distinct piece of info: action, input types, syncing effect. However, it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters (one optional) and no annotations, the description is too sparse. It does not explain the return value despite an output schema existing, nor the behavior when group_id is omitted. Important details about error states, rate limits, or readiness for use are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters (group_id optional, commands_json required) but 0% schema description coverage. The description adds some meaning by listing acceptable JSON types (builtin/custom/segments/translations) and mentioning syncing. This compensates partially but does not explain the exact format of commands_json or the effect of group_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states "Save bot commands" and mentions JSON types and syncing, but the verb 'save' could mean create or update. It does not clearly distinguish from the sibling tools like telegram_commands_get (which retrieves) but does not explain how this tool differs from a potential 'update' or 'create' variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description hints at syncing but offers no explicit guidance on when to use this tool vs. siblings like telegram_commands_get or when not to use it. No prerequisites, alternatives, or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states the basic operation—adding a memory entry—but omits critical behaviors: whether it appends or overwrites existing entries, what happens if the topic is missing, any permission requirements, rate limits, or side effects. The existence of an output schema is not mentioned, so agents lack insight into the return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise and front-loaded with the verb. However, it is too sparse for the tool's complexity (3 parameters, no annotations). It could include more context (e.g., parameter roles, return value) without becoming overly long. It earns its place for stating purpose but leaves significant gaps.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 3 parameters, 0% schema coverage, and no annotations, the description is insufficiently complete. It does not explain the relationship to sibling tools (e.g., that workers_memory_create_topic creates topics first), what the output schema contains, or how group_id and topic interact. An agent would lack the full context needed to use this tool correctly, especially within the broader memory system.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description only indirectly explains one parameter ('topic' via 'to a topic'). The required 'content' parameter is not explained at all—what type of data it should contain (text, JSON, etc.). The optional 'group_id' is completely unexplained. The description adds little meaning beyond the bare schema, failing to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a memory entry') and the resource ('to a topic'), with the hint '(topic_*)' indicating topic naming convention. It distinguishes itself from sibling tools like workers_memory_get, workers_memory_edit, and workers_memory_delete by using a different verb ('add' vs 'get/edit/delete'). However, it lacks specificity about what constitutes a 'memory entry' beyond the content parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like workers_memory_create_topic (if topic doesn't exist) or workers_memory_edit (to modify existing entries). There is no mention of prerequisites, such as whether the topic must already exist, or conditions that would make this tool inappropriate. The description is silent on usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'Posts the donor into the native ready-reply Telegram topic' but does not explain what 'donor' means, whether this is destructive, or if it requires specific permissions. The behavior is partially disclosed but incomplete for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and reasonably concise, but the first sentence is front-loaded with the core purpose. Some detail about item_json could be moved to parameter descriptions or structured better, but overall it's not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters (2 undocumented), no annotations, and an output schema whose content is unknown, the description is insufficient. It does not explain return values, error conditions, or the lifecycle of a ready reply. The tool does complex integration (Telegram topic) but the description glosses over key details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description only partly explains item_json (text/triggers/caption/buttons/topic_name). There is no explanation of rr_id or group_id, which have defaults that are not clarifying. The description adds some meaning for item_json but leaves two parameters entirely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates or updates a ready reply, and mentions the Telegram topic integration and item_json fields. However, it doesn't differentiate from workers_readyreply_delete or workers_readyreply_create_topic, which are the most closely related siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like workers_readyreply_delete or workers_readyreply_create_topic. The description does not specify prerequisites, such as requiring an existing topic or what happens if rr_id is omitted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It mentions mutation (create/update/cancel) but offers no details on side effects, idempotency, permissions, or failure behavior. The payload format hint is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no wasted words. The structure is efficient, but the conciseness comes at the cost of missing critical information for a tool with this complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 0% schema coverage, no annotations, and multi-operation CRUD via a string payload, the description is far too minimal. It fails to explain how actions map to operations, the role of group_id, or error handling, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description only notes that payload_json contains 'action, event, ...', adding minimal meaning beyond the raw schema. It doesn't explain group_id's purpose or the expected structure/values of the payload fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states three actions (create/update/cancel) on a 'Booking CRM event', which is a specific verb-resource combination distinguishing it from most sibling tools. However, 'Booking CRM event' is still somewhat vague, and there's no differentiation from the sibling 'crm_context'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like crm_context. No prerequisites, exclusions, or context for choosing between the three actions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only states that scenarios are saved, but does not specify whether this overwrites existing scenarios, requires authentication, is idempotent, or what happens on success or failure. Critical behavioral traits for a mutation tool are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the verb and input format. Every word contributes value. However, it could be slightly more informative without losing conciseness. Still, it is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two required parameters, no annotations, and an existing but not shown output schema, the description is incomplete. It does not mention return values, error conditions, or the relationship to 'survey_agent_scenarios_get'. A save operation typically needs to clarify whether it creates or updates, which is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, placing heavy reliance on the description. The description clarifies the expected format of 'scenarios_json' (JSON array or object with 'scenarios' key), but does not explain the purpose or constraints of 'survey_id'. The name implies it identifies a survey, but no confirmation or additional semantics are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Save' with the resource 'post-submit scenarios', and clarifies the expected input format (JSON array or object with 'scenarios' key). It distinguishes from the sibling tool 'survey_agent_scenarios_get' by indicating a write operation. However, the term 'post-submit scenarios' is somewhat cryptic and could be more explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'survey_agent_settings_save' or 'survey_agent_update'. There is no mention of prerequisites, typical workflow context, or conditions under which this tool should or should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states the purpose and does not mention whether the operation is read-only, requires authentication, or any side effects. For a stats tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise. However, it is too terse to be fully informative; important details are omitted. It is not wasteful but under-specifies.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter, no annotations, and no parameter descriptions, the description is incomplete. While an output schema exists, the description does not hint at what the stats contain (e.g., counts, conversion rates, time ranges), leaving the agent guessing about the tool's full capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'survey_id' with no description. Schema description coverage is 0%, and the tool description adds no additional meaning about this parameter (e.g., format, example, or relationship to the stats). The agent has no guidance on how to construct valid input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Funnel stats for a survey' clearly indicates the tool provides statistical data (funnel metrics) for a given survey. It distinguishes from sibling tools like 'survey_agent_list_forms' and 'survey_agent_get' which focus on retrieval or management rather than analytics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does 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 vs. alternatives. However, the name and description imply it is for retrieving funnel statistics, and among siblings, it is the only one with 'stats' in its name, so usage context is weakly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It adds only one behavioral detail ('releases calendar hold') beyond the name. It omits whether the cancellation is reversible, what permissions are required, what effects occur on related data, or any side effects. For a mutation tool, this is insufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a brief single sentence, front-loaded with the core action. However, it is too short given the missing parameter and behavioral details, sacrificing completeness for conciseness. It earns a middling score because while it avoids bloat, it under-delivers on content that needed to be present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the existence of an output schema, the tool has moderate complexity with two parameters, no schema descriptions, and no annotations. The description fails to explain the return value, prerequisites, the meaning of group_id, or the cancellation's broader impact (e.g., whether it deletes the task or just removes calendar hold). It is not complete enough for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the input schema provides no parameter descriptions. The tool description does not mention either parameter (task_id or group_id), leaving the agent to infer their meaning from names alone. It fails to add semantic value beyond what the raw parameter names suggest, which is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Cancel task' as the action on the resource, with the parenthetical 'releases calendar hold' providing specific context. This distinguishes it from sibling tools like tasks_complete (which likely marks tasks done without cancellation). The verb+resource is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use cancel versus alternatives like tasks_complete, tasks_update, or tasks_delete. It does not mention prerequisites, conditions, or when not to use this tool. The parenthetical hint about calendar holds is the only contextual clue, but it is not explicit usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states the core action without noting that the operation is read-only, whether pagination exists (though parameters hint at it), what authentication is needed, or how filtering/ordering works. The mention of 'manual + booking' is ambiguous and not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but lacks essential information. It does not waste words, but it also does not earn its place by adding value beyond the name. More structured detail could be provided in the same space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description fails to leverage context signals: it does not explain how to use the 8 parameters, what output format to expect, or how this tool differs from the many task siblings. The complexity of the tool (many parameters, no schema docs) demands a richer description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain any of the 8 parameters (q, limit, offset, source, status, group_id, to_time, from_time). The phrase 'manual + booking' might relate to the `source` parameter but is unclear. The agent gets no help understanding what values or formats are expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'List tasks for a Telegram group', which clearly identifies the verb (List), resource (tasks), and scope (Telegram group with manual+booking types). This distinguishes it from sibling tools like tasks_get (single task) and tasks_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as tasks_count (for counting) or tasks_get (for a single task). The description does not mention exclusion criteria or prerequisites, leaving the agent to infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, description carries transparency burden. It discloses that no messages are sent and returns username/id, which is a read-like operation. However, it doesn't confirm no side effects or explicitly state read-only, nor describe behavior 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no wasted words, front-loaded. Slightly fragmented but efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description leaves significant gaps: no parameter explanation, no error behavior, no output structure despite output schema existing. For a simple tool, it's minimally adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
0% schema description coverage and the description fails to mention or explain the sole parameter 'group_id'. Parameter semantics are completely absent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns bot connection status (username/id) and clarifies it does not send messages. Distinguishes it from message-sending tools, though the exact meaning of 'status' could be more specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like telegram_commands_get or telegram_restart. Description implies usage for checking bot identity but doesn't provide context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only states the listing/filtering behavior but doesn't disclose whether the tool is read-only, pagination limits, authorization needs, or what happens if rr_id doesn't exist. The behavior is implied but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loading the primary action (List ready replies) and the exception case (or one item if rr_id is set). No extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 0% schema coverage, two optional parameters, and no annotations, the description is insufficient. It doesn't explain the return structure (despite output schema existing), parameter behavior, or common patterns for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It only mentions rr_id's filtering effect in passing without explaining what group_id does, valid formats, or how the two parameters interact. The description adds minimal value over the raw schema parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists ready replies and can optionally return a single item when rr_id is set. It distinguishes the listing behavior from sibling tools like workers_readyreply_upsert and workers_readyreply_delete which perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like using rr_id vs no rr_id, or how it relates to other ready reply tools. No context is given about typical use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure, but it only states the action without any traits: no mention of read-only nature, required permissions, rate limits, pagination, or side effects. The verb 'Fetch' implies a read operation, but the description does not confirm safety or disclose any behavioral constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. It is appropriately concise for a simple tool with one parameter. However, the extreme brevity sacrifices some clarity and completeness, though it does not contain wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (as per context signals), the description does not need to explain return values. However, the tool is part of a large survey family and the description lacks any contextual cues about scope, data volume, or relation to sibling tools. It is minimally complete for a simple fetch operation but would benefit from a note on the nature of 'respondent answers' or typical usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter (survey_id) with zero description coverage. The tool description does not mention survey_id or provide any semantics (e.g., format, example, source). Since schema coverage is 0%, the description should compensate but fails to add value beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch respondent answers for a survey.' uses a clear verb ('Fetch') and specifies the resource ('respondent answers for a survey'). Among sibling tools like survey_agent_get (gets survey details) and survey_agent_list_forms (lists forms), this tool's purpose is distinct and unambiguous. However, it could be more precise by indicating whether it retrieves all answers or filtered ones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as survey_agent_get, survey_agent_list_forms, or survey_agent_scenarios_get. There is no mention of prerequisites, context, or exclusion criteria, leaving the agent 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description must fully disclose behavioral traits. It only states the action (get) and resource type. It does not mention whether the operation is read-only, idempotent, or has side effects, nor does it indicate authorization requirements or scope of results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose efficiently. However, it is arguably too terse given the lack of annotations and parameter descriptions, but the structure itself is clean and waste-free.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The presence of an output schema reduces the need to describe return values, but the description fails to explain what 'post-submit automation scenarios' are or how this tool fits into the broader workflow. For a simple getter with one parameter, the information is minimally adequate but lacks depth for confident agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full burden for explaining the single parameter 'survey_id'. The description adds no meaning beyond the parameter name; it does not explain what constitutes a valid survey_id, how to obtain it, or its role in retrieving scenarios.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get post-submit automation scenarios' uses a specific verb ('Get') and resource ('post-submit automation scenarios'), clearly indicating the tool's action. It distinguishes from siblings like 'survey_agent_scenarios_save' but does not explicitly differentiate from other 'get' tools like 'survey_agent_get', which retrieves different data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'survey_agent_scenarios_save' or 'survey_agent_get'. The description lacks context on prerequisites, expected use cases, or exclusion criteria, leaving the agent to infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states that the tool counts tasks, missing behavioral details such as whether it is read-only, side effects, rate limits, or authentication requirements. The output schema exists but is not referenced in 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, but it is overly concise. It lacks structure or elaboration, and while it is front-loaded with the key action, it does not provide a complete picture.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no annotations, and no schema descriptions, the description is woefully incomplete. It does not explain the filters, return value, or any constraints. The agent cannot reliably use this tool based solely on the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description merely references 'same filters as tasks_list' without explaining any of the six parameters (q, source, status, etc.). It adds no meaningful semantics beyond the parameter names, leaving the agent to guess or reference another tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'count' and resource 'tasks'. It distinguishes from the sibling tool 'tasks_list' by specifying that it counts with the same filters, making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool should be used when a count is needed instead of a list (via 'same filters as tasks_list'), but it does not explicitly state when to use it, when not to, or mention alternatives. The guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It indicates mutation via 'Save' but fails to specify whether this overwrites, upserts, or creates, nor does it mention error conditions or side effects. Critical context for a mutation tool is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short—two sentences—and front-loads the core purpose. It contains no filler, but the extreme brevity limits its value for complex tools.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (unseen) and two required parameters, the description lacks completeness. It doesn't explain the effect on existing settings, the behavior when survey_id is invalid, or how errors are reported. A more thorough description would significantly improve agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 adds meaning to settings_json by clarifying it can be an object or nested under 'settings', which helps the agent format the input correctly. However, survey_id remains undocumented beyond the schema field name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Save survey settings' and provides a format hint for settings_json. It distinguishes itself from sibling survey_agent_settings_get by being the write counterpart, though it doesn't explicitly note the relationship.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like survey_agent_settings_get or other survey tools. There is no mention of prerequisites, idempotency, or conditions under which saving is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the POST method workaround for PUT issues, which is useful behavioral context. However, it omits details like whether the update is destructive, requires authentication, or returns the updated survey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (one line), front-loads the verb and resource. Every word adds value except possibly the technical note in parentheses, which is context-dependent (may be noise for non-deployment agents).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, return values are covered. However, with 2 undocumented parameters and no behavioral details (idempotency, success/error), the description is incomplete for a mutation tool with 0% schema coverage and no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds zero details about parameters. It does not explain what `dsl` expects (JSON string, DSL syntax) or what `survey_id` identifies. The agent must guess parameter meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update survey DSL') and the HTTP method ('POST; nginx often 405s PUT'). It distinguishes from sibling tools like `survey_agent_get` and `survey_agent_settings_save` by focusing on DSL updates, though it could explicitly differentiate from `survey_agent_settings_save` and `survey_create`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like `survey_create` (new survey) or `survey_agent_settings_save` (settings only). The HTTP method advisory is helpful for deployment but lacks broader context on prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states the basic operation ('get one task') without mentioning read-only nature, error behavior (e.g., what happens if task_id is not found), authentication requirements, or rate limits. This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no waste. However, it may be too terse given the missing parameter explanation. For a simple tool with one required parameter, this conciseness is almost ideal but slightly incomplete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the return format is covered, but the description fails to explain the role of group_id or any edge cases. The tool has two parameters where one is completely undocumented in the description, making the tool definition incomplete for an agent to use correctly in varied contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters. It clarifies 'by id' for task_id but completely omits the purpose of the optional group_id parameter, leaving the agent unsure whether and when to provide it. This is insufficient for effective tool use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get one task by id' uses a specific verb ('Get') and a clear resource ('one task by id'). It clearly distinguishes from sibling tools like tasks_list (multiple tasks) and tasks_create (create), making the tool's purpose immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as tasks_list for multiple tasks or tasks_count for counting. It also doesn't mention use of the optional group_id parameter or any prerequisites for accessing a task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It only states 'Delete a memory entry' but does not disclose whether the deletion is permanent, whether it requires authentication, what happens if the message_id does not exist, or if there are any side effects. Behavior is minimally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. However, given the complexity of a 3-parameter delete operation with no annotations, it is too terse and misses critical context. Conciseness is achieved at the expense of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the presence of an output schema, the description lacks usage guidelines, parameter semantics for two optional fields, and behavioral transparency (e.g., irreversibility). For a delete tool with no annotations, the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It only mentions message_id, ignoring the optional parameters topic and group_id. Their purpose (e.g., scoping deletion to a specific topic or group) is not explained, leaving the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete), the resource (memory entry), and the key identifier (message_id). It is specific and easily distinguishes itself from sibling tools like workers_memory_get, workers_memory_add, and workers_memory_edit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, when to delete versus edit a memory, or any prerequisites like ownership or permissions. The description assumes the agent knows the context without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'Edit a memory entry' without disclosing whether this is a full replacement or partial update, what happens to unspecified fields, or what the response contains. The mutation nature is implied but lacks detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundancy. It efficiently conveys the core action and identifier. Every word is necessary, and it is appropriately sized for a straightforward edit operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no annotations, and an output schema not shown, the description is too brief. It lacks parameter explanations, behavioral details, and context relative to sibling tools. For the complexity of the tool, more complete information is needed for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. However, it only mentions 'by message_id' and does not explain the role of 'content' (required) or optional parameters 'topic' and 'group_id'. The agent cannot infer what values are valid or how these parameters affect the memory entry, making parameter usage ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Edit a memory entry by message_id' clearly states the action (edit) and resource (memory entry), with a specific identifier (message_id). It distinguishes this tool from siblings like add, delete, get, and create_topic by uniquely specifying 'edit' and the identification method.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 (e.g., workers_memory_add, workers_memory_delete). No prerequisites are mentioned, nor any context about when editing is appropriate. The agent is left to 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states 'Read', implying a safe, side-effect-free operation, but does not mention idempotency, error handling (e.g., topic not found), rate limits, or authentication needs. The description adds minimal transparency beyond the verb itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences and front-loads the core purpose. Every word is functional, with no redundancy. It could be slightly more precise about what exactly is returned, but overall it is well-structured for its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description leaves significant ambiguity: it does not specify whether the tool returns a list of topics, entries, or a single entry. The agent cannot determine the full scope of what is returned or how the optional filters affect the result. Given the tool's role as a read operation among many siblings, this incompleteness hinders proper invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 clarifies the topic parameter format ('topic_<id>'), which adds value beyond the schema. However, it completely ignores the group_id parameter, leaving its semantics unexplained. Partial compensation for one of two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read memory topics and entries' with a specific verb and resource, distinguishing it from sibling mutation tools like workers_memory_add or workers_memory_delete. However, it is slightly ambiguous whether it returns topics, entries, or both; the optional filter hint partially clarifies but could be more precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. While it is implicitly the read operation among memory tools, there is no mention of when to prefer this over, for example, workers_memory_create_topic or other read siblings. No exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It indicates a read-only retrieval with a note on what is excluded (message logs), but fails to mention authentication needs, error handling, rate limits, or any side effects. The minimal disclosure insufficiently informs an agent about operational constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the core action and a key limitation. While it could be expanded to cover parameters or return format, for conciseness alone it scores highly—every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters (one required) with zero schema description coverage and no annotations, the description should provide more contextual glue. It does not explain the return structure (even though an output schema exists, its contents are unknown to the agent), nor does it specify prerequisites for user_id or group_id. The agent is left with too many unknowns to reliably invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds zero detail about parameters. It does not explain what 'user_id' (required) represents or how optional 'group_id' affects results. The agent must guess parameter semantics solely from property titles, which lack any descriptive enrichment here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'one user chat card' with a distinguishing clause '(no message logs)'. This sets it apart from sibling tools like workers_chats_list (likely lists multiple) and workers_chat_send (sends messages), making the purpose immediately obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a single chat card without message logs, but it does not explicitly state when to prefer this tool over alternatives (e.g., workers_chats_list for multiple cards, workers_chat_send for messaging). No usage context or exclusions are provided, leaving selection partially ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool debits the account, adds add_usd*3600 tt, and raises salary, and that it is a preview only until confirmed. This is moderately transparent. However, it does not mention reversibility, what the output contains, or any side effects beyond the debit, which leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, making it fairly concise. The main action is front-loaded. However, the language is informal and includes jargon ('solary', 'tt') that may confuse an AI agent. Some sentences could be clearer or more structured. It is not overly verbose but lacks polish.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters, an output schema, and is part of a salary system, the description is incomplete. It explains the preview and debit behavior but fails to describe the group_id parameter, the output content, or what 'tt' means. The informal terms and missing details leave the agent without enough information to reliably use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must explain parameters. The description explains the add_usd parameter by showing its role in the formula 'add_usd*3600 tt'. However, the group_id parameter is not mentioned at all, and its default empty string is not clarified. Only one of two parameters is partially explained, leaving significant ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states it previews raising YOUR contribution by whole USD, which is a specific verb+resource. It distinguishes from the sibling workers_salary_confirm by noting the preview nature and that it does not charge until confirm. However, the phrasing is informal and includes unclear terms like 'solary' and 'tt', slightly reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly tells when to use this tool by mentioning 'Does not charge until workers_salary_confirm(quote_id, confirm=true)' and 'Other admins can raise their own share'. However, it does not explicitly state when not to use it or provide alternatives beyond the confirm step. The guidance is present but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and adds value by revealing that completing a task releases a calendar hold. However, it does not disclose other side effects, reversibility, or required states, leaving significant behavioral unknowns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that immediately states the action and a key consequence. No wasted words, well front-loaded, and perfectly scoped for a simple completion action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description omits parameter explanations, error conditions, and differentiation from tasks_cancel. For a tool with two parameters and siblings offering alternative workflows, this is insufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but fails entirely—it mentions no parameters. The agent learns nothing about what task_id or group_id represent beyond their types and names in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'Mark' and resource 'task', with a clarifying parenthetical 'releases calendar hold' that distinguishes it from sibling tools like tasks_cancel or tasks_update. It clearly communicates the core action without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives (e.g., tasks_cancel, tasks_batch_update), nor does it mention prerequisites or edge cases like already completed tasks. The agent receives no contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds some behavioral context: 'Does not charge' indicates no side-effect (no mutation, no cost). It also explains the default group_id fallback. However, with no annotations, it lacks disclosure of auth requirements, read-only nature, or rate limits. The foreign phrase 'нужен group_id' is unclear and may confuse agents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (three short sentences) and front-loaded with the key concept of two layers. However, the phrasing is cryptic and the foreign language fragment reduces clarity. It is concise but not optimally clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a simple optional parameter and an output schema, the description is marginally complete. It explains the two-layer balance and default behavior, but it does not explicitly state that the tool returns these balances, nor does it describe the output format. The lack of a clear purpose statement makes it slightly incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description carries the full burden. It explains the behavior of the sole parameter 'group_id': empty uses credentials/AIWORKERS_GROUP_ID, non-empty requires a valid group. This adds significant meaning beyond the schema's default value and type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description implies the tool returns balance information for two layers ('account.usd' and 'group.tt'), but it does not use a clear verb like 'get' or 'retrieve'. The phrase 'Two layers' is ambiguous and does not explicitly state the tool's action. Sibling tools like 'workers_salary_quote' or 'workers_tt_buy_quote' suggest balance-related queries, but the description does not differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. While it mentions empty group_id behavior, it does not compare with other tools like 'workers_list' or 'workers_get', nor does it explain prerequisites or scenarios. The 'Does not charge' note is a behavioral hint, not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the parameter flexibility (accepts id, slug, or URL) but doesn't describe any behavioral traits like whether it's read-only, what happens on invalid ID, rate limits, or auth requirements. For a simple get tool this is acceptable but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two sentences) and front-loaded with the core purpose. Every clause adds value—the first states what it does, the second clarifies a key detail about the parameter. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of rich output schema (not shown but indicated as 'has output schema: true'), the description doesn't need to detail return values. With only 1 required parameter and simple structure, the description mostly suffices but lacks fail behavior info and explicit read-only declaration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 adds that survey_id can be 'full id, public slug, or form URL,' which adds meaning beyond the schema's 'string' type. However, it doesn't specify the form URL format (e.g., must include prefix, HTTP vs HTTPS), and there's no explanation of how the tool differentiates between these input types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves survey DSL and metadata, and specifies that survey_id can be a full ID, public slug, or form URL. This distinguishes it from siblings like survey_agent_list_forms (list) and survey_validate_dsl (validate). However, the verb 'get' is somewhat generic and could be more specific about read-only nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need survey DSL/metadata by accepting multiple ID formats. However, it does not explicitly state when to use this vs alternatives like survey_get_dsl_rules or survey_agent_settings_get. No when-not-to-use guidance or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It correctly indicates a read-only fetch operation, but it does not specify if the rules are cached, if authentication is required, or what happens if the server is unreachable. The presence of an output schema mitigates the need to describe return values, but basic behavioral context is still missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with 8 words, making it extremely concise. It front-loades the core action and resource. However, it could be slightly more structured by noting optional parameters or return format, but it remains minimal without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 optional param, no required params, output schema present), the description is minimally complete for a read operation. However, it omits clarifying the format options and any server-side behavior (e.g., whether the rules are static or update dynamically). The output schema likely provides return structure, so the description does not need to explain that, but the lack of parameter context leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 optional parameter ('format') with default 'markdown'. Schema description coverage is 0%, so the description compensates by implying the tool provides survey DSL rules. However, it does not explain the 'format' parameter's purpose or allowed values (e.g., whether formats like 'json' are supported). The baseline is 3 due to low coverage, and the description barely adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch current Survey DSL parsing rules from the server' specifies a clear verb ('Fetch') and resource ('Survey DSL parsing rules'), which distinguishes it from sibling tools like 'survey_validate_dsl' that validate rules rather than fetch them. The title is null, but the description effectively conveys the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. Sibling tools like 'survey_validate_dsl' or 'survey_create' may have overlapping contexts, but no exclusions or contextual hints are given. The agent is left to infer usage solely from the tool name and description, which lacks explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry full burden. It mentions Telegram card and calendar hold but omits behavioral details such as authorization requirements, failure modes, side effects, or what 'optional' means. Adequate but incomplete for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose efficiently. However, it could be slightly expanded (e.g., listing key parameters) without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no annotations, and an output schema (not shown), the description covers only a fraction of the tool's semantics. The agent lacks information about several fields (contact, group_id, description) and potential constraints, making the tool harder to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description only hints at a few parameters ('Telegram card' for post_card, 'calendar hold' for start/end_date). Most parameters (contact, group_id, description) receive no explanation, forcing heavy reliance on parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('create a manual task') and adds distinct features ('optional Telegram card + calendar hold'), distinguishing it from sibling tools like tasks_list, tasks_update, and tasks_complete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives like tasks_update or tasks_complete. It does not mention prerequisites, exclusions, or typical scenarios, leaving the agent to 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral transparency. While it identifies this as a mutation ('Update'), it does not disclose any side effects, authorization requirements, or what happens to the worker record when fields are updated. The mention of specific fields is helpful but incomplete for understanding the full behavioral implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise two-sentence structure that front-loads the primary purpose ('Update worker fields') and provides essential negative guidance in the second sentence. Every word serves a purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the complexity of having 2 parameters with 0% schema coverage, the description provides the core purpose and a critical exclusion (avoiding TT fields), which is adequate for basic usage. However, it lacks details on how to structure the patch_json parameter, what values are valid for status or other fields, and does not leverage the output schema context to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only mentions the field values (status, lang, paid_until, translate_langs) without clarifying how they map to the two parameters group_id and patch_json. The description does not explain that patch_json likely contains the field updates or that group_id identifies the target worker, leaving the agent to infer parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update worker fields' with a specific verb and resource, listing the fields that can be updated (status, lang, paid_until, translate_langs). This distinguishes it from sibling tools like workers_get or workers_list which only read data, and from workers_salary_quote which handles salary operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when not to use this tool by stating 'Never write tt here — use workers_salary_quote or workers_tt_buy_quote', which clearly directs the agent to alternative tools for TT-related operations. It does not, however, explain when this tool should be preferred over other update tools like aiworkers_skill_update or workers_memory_edit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions that archived surveys are hidden unless include_archived is true, which is a useful behavioral trait. However, it does not disclose other behaviors such as whether this is a read-only operation, if it requires specific permissions, performance characteristics, or pagination details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences, each adding value: the first identifies the action and scope, the second clarifies the default behavior regarding archived surveys. There is no redundancy or extra verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 optional parameter, output schema present, no nested objects), the description covers the key functionality and the single parameter's effect. The presence of an output schema means return values need not be described. It does not address pagination or ordering, but for a simple list with one parameter, this feels sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (include_archived) with default false and 0% schema description coverage. The description mentions that 'archived hidden unless include_archived', which adds meaning beyond the schema's bare type/boolean/default, explaining the parameter's effect. With only one parameter and some explanation, the score is slightly above baseline, but the description does not fully compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List surveys for this API token (scoped by group_id)' which provides a specific verb ('list') and resource ('surveys') along with implicit scoping. It differentiates from siblings like 'survey_create' by indicating read-only intent, and from other list tools by specifying the API token/group_id scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it lists surveys for the current API token, which provides context about when to use it (to see available surveys). However, it does not explicitly mention when not to use it or provide alternatives among the many sibling survey tools (like survey_get_dsl_rules or survey_agent_get), leaving the agent to infer usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits itself. It mentions that the root account appears as 'the shared USD wallet once', adding some output behavior insight. However, it does not state that this tool is read-only, whether it requires authentication, or what happens if the key has no access.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short with only two sentences. It is front-loaded with the main action ('List workers this key can access') and then adds supporting context efficiently. No unnecessary words, though it could be slightly clearer with punctuation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has zero parameters and an output schema exists to describe the return values, the description covers what an agent needs to know: what the tool lists and a hint about output structure. The mention of 'Root account is the shared USD wallet once' adds helpful domain context beyond what the schema would provide.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the description does not need to explain any param details. The context signals indicate 100% schema coverage, so the baseline is 3. The description adds no param information because none exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists workers accessible to the current key. The phrase 'Each row has group tt/usd/stars' adds specific context about what information is included, which differentiates it from a generic list. However, it does not explicitly distinguish itself from all sibling tools beyond one named alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool vs workers_balance, stating 'For one group use workers_balance'. This is helpful for an agent choosing between similar tools. However, no exclusions or conditions are given beyond that one comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses the non-destructive nature ('without saving'), which is positive. However, it does not mention whether the tool requires specific permissions, returned data format, side effects, or error behavior. With a zero-annotation tool, more transparency would be warranted, making 3 a middle score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. Every word serves a purpose: 'Validate' (action), 'Survey DSL' (subject), 'without saving' (scope). Ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 1-parameter simplicity and the existence of an output schema (which reduces need to document return values), the description is largely complete. It lacks explanation of DSL format, but for a single-string validation tool, this is a minor gap. The description provides enough for an agent to distinguish it from survey_create or survey_agent_skill.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is 0% schema description coverage, but the tool has only 1 parameter ('dsl'). The description does not explain the expected format of the DSL string (e.g., does it accept JSON, XML, or plain text? What constitutes valid DSL?). Since the schema provides no description at all, the tool description should compensate. However, the brevity of the parameter set (only 1) makes the omission less critical. Score 4 for almost adequate given the simplicity, but lacking format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Validate Survey DSL without saving' clearly states the action (validate) and the subject (Survey DSL), and explicitly distinguishes from write/save operations. It provides a specific verb and resource that differentiates it from sibling tools like survey_create or survey_agent_skill.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool should be used when validation is needed without persistence, which is evident from 'without saving'. However, it provides no explicit guidance on when to not use this tool (e.g., for syntax errors vs semantic checks), nor does it reference alternatives. The lack of context about when validation is required or what constitutes success is a gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It correctly signals that the tool is read-only ('Does not send messages') and states what it returns ('segments + translations'). However, it does not disclose whether the operation requires any special permissions, whether it changes state on the Telegram side, or what happens when group_id is empty (default). These gaps prevent a higher score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences that immediately communicate the core purpose and add a key behavioral constraint. Every word serves a purpose. It is front-loaded and highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (though not shown), so return values are presumably documented there. The description properly indicates the output content type ('segments + translations'). Given the tool's simplicity (1 optional param, no annotations overhead), the description is mostly sufficient. A minor gap is the lack of clarification on what happens when group_id is omitted, but the default value suggests it retrieves a global menu.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the input schema has 0% description coverage for parameters, the tool has only a single parameter (group_id) with a default of empty string. The description does not explicitly explain group_id, but given its name and the bot command menu context, its purpose is reasonably inferable. The description adds no extra parameter semantics, but with only one simple parameter and schema coverage at 0%, a slight benefit of the doubt is warranted for clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and the resource 'bot command menu', and specifies it returns 'segments + translations'. It also adds a negative statement 'Does not send messages', which helps differentiate it from potential sibling tools like telegram_commands_save. However, it does not explicitly distinguish it from all siblings, and the sibling list is large with several other 'telegram_' prefixed tools, so some agent confusion remains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates this is a read-only retrieval tool, contrasting it with the write operation of sending messages. However, it does not provide explicit when-to-use or when-not-to-use guidance compared to siblings like telegram_status or telegram_commands_save. Given the sibling context includes telegram_commands_save, an explicit alternative mention would have raised the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. 'No bot tokens' adds a useful constraint, and 'Read' implies a read-only operation. However, it does not disclose what the worker card contains, whether it can fail, or what the output structure is, though an output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise two-sentence description with no wasted words. The main purpose and a key usage hint are front-loaded. The 'no bot tokens' clarification is valuable context packed efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and an output schema, so the description is mostly complete. However, the output schema is not shown and the description does not explain what 'worker card' data is returned, which could be ambiguous. Given the tool's simplicity, this is adequate but not exceptionally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but there is only one parameter (group_id) with no description. The tool description does not explain the meaning of group_id or its relationship to the worker card, so the agent must infer from the name. This is a notable gap since the schema provides no semantic help.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Describes the tool as reading a worker card and explicitly notes it does not require bot tokens, distinguishing it from other worker-related tools. Slightly less clear than naming the exact resource 'worker card' but does convey the primary function and a key distinction from siblings like workers_balance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear usage hint: 'For money prefer workers_balance.' This tells the agent when not to use this tool and points to an alternative, which is helpful. However, it does not fully explain when to use workers_get vs other worker-related read tools or when reading a card is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: it clarifies that the link does not credit group tt, explains the effect of amount_usd on the start payload, and warns about invalid dots. This goes beyond basic purpose and provides useful operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences) and front-loaded with the main purpose. Some redundancy exists ('Does not credit group tt. No tt_credit.' could be combined). Overall, every sentence adds value, though the structure is logical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple URL-generation tool with two parameters and an unspecified output schema, the description covers the core behavior and one parameter well. However, it neglects the group_id parameter and does not describe the output schema or potential errors, leaving gaps for a fully informed agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It thoroughly explains amount_usd (omission vs. presence, start payload values). However, it completely omits group_id, which is an optional parameter with a default empty string. The description does not clarify what group_id does or when to provide it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a URL to top up the ACCOUNT wallet, specifying the bot and balance type. It distinguishes itself by clarifying what it does not do ('Does not credit group tt. No tt_credit.'), which helps differentiate from related tools like workers_balance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains conditional behavior based on the amount_usd parameter (ask_amount vs. start=addBalance_10), which guides usage. However, it lacks explicit guidance on when to use this tool versus alternatives like workers_balance or workers_salary_quote, and does not mention any prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It correctly signals a write operation ('charge'), mentions a constraint ('confirm must be true'), and warns about a 409 error on reuse. However, it does not disclose whether the tool is idempotent, what happens if the quote is expired or invalid, or what the response looks like. The phrase 'solary unchanged' is unclear and adds minimal 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three short sentences, each packed with essential information. The first sentence states the primary action, the second adds a critical constraint, and the third provides timing and error context. No filler words. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters (0% schema coverage), an output schema (unknown content), and no annotations, the description is too minimal. It fails to explain what 'solary unchanged' means, how to interpret the output, or how to obtain a valid quote. The agent would need to infer critical details from sibling tools or trial and error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 addresses the 'confirm' parameter by stating it must be true, which is a useful constraint. The other two parameters ('quote_id', 'group_id') are not explained at all. The description does not clarify the role of 'group_id' or the format of 'quote_id', leaving significant gaps for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Charge a one-time tt quote') and identifies the resource as a 'tt quote'. It distinguishes from the sibling 'workers_tt_buy_quote' (which likely creates a quote) by implying this is the confirmation step. The verb 'charge' and resource 'quote' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context: 'confirm must be true' is a required setting, and 'Quote lives ~5 min; reuse is 409' warns about expiration and error handling. It implicitly tells the agent to first obtain a quote via workers_tt_buy_quote and then use this tool to charge it. No explicit alternatives or when-not-to-use information is given, but the constraints are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It explicitly states 'Does not change solary' (likely 'salary') and 'Does not charge until workers_tt_buy_confirm', confirming the tool is read-only and non-destructive. This is clear and sufficient for a preview action, though it could mention permissions 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four short sentences that front-load the purpose. There is no fluff, but the typo 'solary' and the lack of grouping (e.g., listing parameters separately) slightly reduce clarity. Overall efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists (from context), the description need not detail return values. However, it does not explain what the quote returns (e.g., conversion rate, total tt) or what 'group_id' is for. For a preview tool used to inform a subsequent confirm, missing output semantics and the group_id param make it less complete than ideal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It clarifies that 'amount_usd' and 'tt' are alternatives ('Pass amount_usd or tt'), but entirely omits the purpose of 'group_id', which is a string parameter with default empty string. Two of three parameters are partially addressed, leaving a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Preview one-time tt buy' which is a specific verb ('Preview') and resource ('tt buy'). It distinguishes itself from sibling tools like 'workers_tt_buy_confirm' by noting it does not charge until that tool is called, and from 'workers_salary_quote' by referencing 'tt buy' specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use this tool to preview before confirming with 'workers_tt_buy_confirm', and tells the agent to 'Pass amount_usd or tt'. However, it does not explicitly state when not to use this tool (e.g., if you want to buy immediately, use confirm directly) or mention any alternatives beyond the implicit confirm step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It states the tool does not delete answers, which is key transparency for a non-destructive action, but does not disclose effects on visibility/listing, whether restoration fully reverses the state, or any required permissions. Additional behavioral context would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence with 10 words, front-loading the core action ('Archive or restore a survey') and adding a key behavioral note. Every part earns its place with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two parameters, the complexity of a toggle action, and the presence of an output schema (which can explain return values), the description is mostly complete. It clarifies the non-destructive nature and the dual operation. It could be more complete by noting the visibility context or listing what happens to the archived state, but overall it is sufficient for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The description adds meaning to the archived and survey_id parameters by stating the tool archives or restores, implying the boolean controls which action, and that survey_id identifies the survey. However, it does not specify the default behavior (archived defaults to true) or clarify the restore case, leaving some gaps. Baseline 3 is appropriate as it adds some value but not full clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Archive (hide from list) or restore a survey. Does not delete answers.' uses a specific verb ('Archive or restore') and resource ('survey'), clearly distinguishes the tool's dual operation (archive/restore), and differentiates it from deletion tools like survey_agent_delete among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (to hide or unhide a survey), but it provides no explicit guidance on when not to use it or what alternatives exist (e.g., survey_agent_delete for permanent removal). The context is clear but lacks exclusions or comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It clearly states the tool is destructive (permanently delete) and requires a confirmation flag, giving the agent essential safety information. This is adequate for a deletion tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, consisting of two short sentences with zero waste. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 2 parameters, no enums, and presence of an output schema, the description covers the core destructive nature and safety requirement. For a simple deletion tool with an output schema, this is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 mentions survey_id implicitly by stating 'survey' but does not explain the format or meaning of the parameters beyond the schema. The confirm parameter is briefly noted. Baseline 3 is appropriate as it adds minimal meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (permanently delete) and the resource (survey, DSL file, and answers). It distinguishes from siblings like survey_agent_update, survey_agent_archive, and survey_agent_get, though it could be more explicit about which sibling tools are similar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the need for confirm=true, implying a safety guard, but does not say when to use this tool vs alternatives (e.g., survey_agent_archive for soft deletion). No explicit when-not-to-use or prerequisites beyond confirmation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It clearly states that 'rates is a constants dict — do not invent percents if empty,' which warns against a specific misuse. This adds behavioral guidance, though it does not cover safety, idempotency, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences) and front-loads the purpose. However, the first sentence is a list of nouns rather than a complete sentence, which could be more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an existing output schema, the description adequately hints at the return contents (terms, URLs, ref_link, rates). It could be more explicit about the tool's side effects or return format, but the output schema likely covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and schema coverage is trivially 100%. The description does not need to add parameter information. Baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly lists the data provided by the tool: platform partner terms, catalog/builder/community URLs, ref_link, and a rates constants dict. It also distinguishes itself from the worker-bot /ref product. However, it lacks an action verb (e.g., 'retrieve') which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage guidance is 'Not the worker-bot /ref product,' which indicates an exclusion but does not explain when to prefer this tool over siblings like workers_list or workers_get. No explicit when-to-use or when-not-to-use context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It describes the tool's effect (writing files to specific locations) and mentions no authorization keys needed. However, it doesn't disclose what happens if the file already exists (overwrite?), whether it's destructive, or any potential side effects (e.g., restarting something). The blank 'update' in the name hints at mutation, but without annotations, more detail on behavior would help.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with a clear action, followed by the trigger condition and a useful note about keys. Every word earns its place; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no annotations, and no complex output schema (though output schema exists but likely just success/error), the description is fairly complete: it tells the agent what it does, when to use it, and a key prerequisite ('No existing key required'). It could mention what the output looks like (since output schema exists), but the behavior is straightforward enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and schema description coverage is 100% (trivially). The description does not need to add parameter info since there are none. This is appropriate, and the tool likely operates on fixed paths or environment-derived context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool writes/refreshes SKILL.md into specific directories. This provides a clear verb (write/refresh) and resource (SKILL.md), and distinguishes it from aiworkers_skill which likely reads rather than writes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to call this 'to pick up the latest skill after a deploy.' This gives clear context for when to use it. While it doesn't explicitly state when not to use it, the sibling list includes aiworkers_skill, suggesting an alternative for reading skills. The 'No existing key required' note adds useful prerequisite info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully conveys the read-only nature ('Return'), the non-requirement of an existing key (authentication context), and the informational output. It does not disclose potential response format or size limits, but the presence of an output schema mitigates the need for more detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that conveys purpose, content, and a key constraint with no wasted words. Every piece of information earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (no parameters, simple output), the description adequately covers what the tool does and the key precondition. The existence of an output schema means return value details are not needed here. Minor gap: it could clarify that the output is Markdown text.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no parameter details, but none are needed since the schema is empty and fully covered. The description does not detract from the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Return' and the resource 'SKILL.md', and specifies the content type ('how to log in and which tools to call'). It distinguishes itself from the sibling 'aiworkers_skill_update' by implying this is a read-only retrieval. The condition 'No existing key required' further clarifies the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for initial onboarding ('how to log in') and signals that no key is required, but it does not explicitly state when to prefer this tool over alternatives like 'aiworkers_login_link' or 'aiworkers_whoami'. No exclusions or when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the token is shown once, that save writes to credentials.json, and that the operation is currently free but will incur costs later. This conveys key side effects and mutation behavior. However, it does not mention error conditions (e.g., duplicate token) or recovery, which would elevate transparency further.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with zero waste. The first sentence immediately states the verb and resource ('Mint a child awm_ token'), followed by constraints, then parameter effects, then pricing. Information is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no schema descriptions, and an output schema (which reduces need to explain return values), the description covers the core action, prerequisites, side effects, and future behavior. It does not detail error states or edge cases (e.g., missing group_id), but for a straightforward minting operation, it is substantially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 explains that 'module' is the target module and that 'save' writes to credentials.json. 'group_id' is only vaguely referenced as 'one group' with no elaboration on its meaning or default. The description adds value beyond the empty schema but does not fully document all parameters, leaving group_id under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Mint' and clearly identifies the resource: 'a child awm_ token for one module + one group' with the constraint 'Parent awp_ only.' It distinguishes the tool from its many siblings (none of which mention token minting) and 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.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states prerequisites ('Parent awp_ only.') and explains when to use the save parameter ('writes it to credentials.json so this MCP can call that module without Mini App'). It also notes future cost ('Free for now; later will debit group TokenTime'). While alternatives are not mentioned, no sibling tool serves the same purpose, so guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for transparency. It discloses rate limits, 429 handling, and that the tool does not send messages. However, it does not explicitly state whether the restart is a destructive operation or if it requires specific permissions, though the nature of restart is generally safe. The coverage is strong but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only three sentences, each serving a distinct purpose: stating the action and technical detail, providing rate-limit guidance, and providing usage context. No unnecessary words or redundant information. This is an excellent example of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional parameter, no enums) and has an output schema, so the description need not detail return values. However, the parameter 'group_id' is left completely unexplained, which is a gap. The description covers usage and behavior but fails to complete the parameter context, making it adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema provides no parameter descriptions. The tool description does not explain what 'group_id' represents or how to obtain it. The description adds no semantic value beyond the schema's title and default. Given low coverage, the description should compensate but fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Restart' with the resource 'Telegram worker process (pm2 aibot-<username>)'. It distinguishes itself from the sibling tool 'workers_update' by explicitly stating 'not workers_update'. The purpose is unambiguous and directly tied to a user request to restart the bot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Use when the user asks to restart the bot — not workers_update.' It also provides rate-limiting behavior (60s per bot) and error handling instructions ('on 429 wait retry_after, do not loop'), which are clear usage guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the action requires 'confirm = true', that the quote expires in ~5 minutes causing a 409 error on reuse, and that status updates go to a 'mailing topic'. This is good transparency for a mutation tool, though it omits details like idempotency or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of three short, information-packed sentences with no filler. The first sentence states the purpose immediately. Each subsequent sentence adds a distinct behavioral constraint or side effect. Every word earns its place, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (three parameters, one required) and the existence of an output schema (which can document return values), the description covers the key aspects: what it does, the confirm requirement, the quote lifetime, and the status destination. It lacks explicit mention of prerequisites (e.g., having a valid quote_id) but implies them. The omission of 'group_id' is a minor gap. Overall, it is sufficient for competent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 explicitly explains the 'confirm' parameter ('confirm must be true') and indirectly covers 'quote_id' through the 'quoted bot-user blast' phrasing and the lifetime/error hint. However, 'group_id' is entirely omitted, leaving its purpose unclear. The description adds value for two out of three parameters but does not fully address all schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb ('Start'), resource ('quoted bot-user blast'), and scope. It distinguishes the tool from siblings like workers_broadcast_quote (which creates a quote) by indicating this tool executes the blast. The mention of error code 409 on reuse further clarifies its specific role in the broadcast workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides strong contextual cues: 'confirm must be true' indicates a required precondition, and 'Quote lives ~5 min; reuse 409' gives a timeout constraint and expected error. However, it does not explicitly state when to use this tool vs. other confirm-type siblings (e.g., workers_salary_confirm), nor does it mention when not to use it. The guidance is clear but not fully exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It clearly reveals that the tool generates a preview without sending, and its output is a quote_id intended for confirmation. It doesn't disclose edge cases (e.g., what happens if the bot has no replies or if the user has no existing chats), but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, every word earns its place. The first sentence states the action, the second clarifies non-actions and related tool. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 params, 0% schema coverage, no annotations but has output schema), the description explains the preview-then-confirm workflow and exclusions. The output schema is present so return values need not be explained. It could mention typical use cases or prerequisites (e.g., must have a ready reply and a worker bot), but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 mentions 'rr_id' is implicit (a ready reply ID) and 'group_id' is optional but doesn't clarify the role of group_id (e.g., filter to a specific group). The description adds some context about what the tool does but does not fully explain parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Preview', 'Does not send') and a clear resource ('one-shot DM blast of a ready reply to everyone who already wrote this worker bot'). It distinguishes its purpose from sibling tools like workers_broadcast_confirm and workers_readyreply_list. However, the phrasing 'DM blast' could be misinterpreted as sending rather than previewing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states that the tool does NOT send, and that sending requires workers_broadcast_confirm(quote_id, confirm=true). It also notes what it does NOT apply to ('Not widget, not folders, not arbitrary ids'), helping the agent avoid misuse. This is exemplary usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral burden. It discloses that the message mirrors into the user's forum topic, explains channel options (auto, bot, embed, topic) with behavioral context, states it is rate-limited, and notes the restriction on sending to arbitrary IDs. It lacks details on error handling or exact rate limits but covers key traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is six short sentences, each adding distinct value: purpose, channel options, mirroring effect, requirements, limitation, and rate limit. No redundancy or unnecessary words. Efficiently front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and an output schema (unseen but present), the description covers purpose, channel behavior, side effects, prerequisites, and constraints. It references workers_chats_list for context. Missing: explicit return value description (though output schema may cover it), error conditions, and how to identify the chat from parameters, but overall sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It adds meaning to the 'channel' parameter with values and behavior, and indicates that text and rr_id are related (at least one needed). However, 'user_id' and 'group_id' are not explained beyond their names, and the relationship between user_id/group_id and the known chat is unclear. Partial compensation only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends one message to a known chat from workers_chats_list, using specific verbs and resource. It distinguishes itself from sibling tools like workers_chats_list (which lists chats) and workers_broadcast_quote (broadcasting) by specifying it sends a single message to an already-known chat.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for usage: it requires a chat from workers_chats_list, needs text and/or rr_id, and explicitly says it does not send to arbitrary Telegram IDs. However, it does not explicitly compare with alternatives like workers_broadcast_quote or workers_readyreply_upsert, nor does it state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully conveys that this tool is a read-only introspection call, disclosing both normal and edge-case behavior (no key returns login URL). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each purposeful and front-loaded. First sentence states core purpose, second gives usage directive, third covers edge case. No redundant or extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an output schema present, the description covers the essentials: purpose, usage order, and conditional outcome. It sufficiently differentiates from sibling tools without being overly verbose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4. The description adds meaning by explaining what the output covers (groups, modules, endpoint map) and the conditional login URL behavior, going beyond the trivial empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows what the API key can see, listing specific outputs (groups, modules, endpoint map). It distinguishes itself from siblings like aiworkers_login_link and other workers_* tools by focusing on identity/introspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs 'Call this first,' providing clear usage priority. It also describes conditional behavior when no key is present (returns login URL), helping the agent decide when to use this tool before others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses critical behaviors: the need for confirm=true, quote expiration, idempotency/conflict error, and a mutation constraint (cannot decrease contribution). The contact direction is also helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: three short sentences, each providing distinct value. Front-loaded with the core purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown), the description covers input constraints, error scenarios, and mutation rules. It omits explanation of the 'group_id' parameter and success outcomes, but the output schema likely fills gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It clarifies the 'confirm' parameter behavior. However, 'quote_id' (required) and 'group_id' are left unexplained, though 'quote_id' is partially inferred from the tool's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Charge' and resource 'salary quote', distinguishing it from related tools like workers_salary_quote (quoting) and workers_tt_buy_confirm (different quote type). The mention of 'confirm must be true' further clarifies the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides practical usage hints: quote lifespan (~5 min), reuse error (409), and a constraint on decreasing contribution. While it doesn't explicitly say 'use after workers_salary_quote', the context and sibling names make it clear. Lacks a direct 'when not to use' statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavioral traits: the link has no secret, the token is one-time, and the action requires the Mini App to show the token once. It also implies a no-destructive outcome (token generation, not modification). This exceeds what annotations would typically provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, all essential: it states the purpose, clarifies security, and provides usage instructions. Every sentence earns its place, and it's front-loaded with the core action. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no annotations, and the tool's simple nature, the description is nearly complete. It covers the purpose, workflow, and security model. Minor omission: it doesn't specify the return format (though an output schema may cover that), but overall it's highly informative for a tool with no inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters with 100% coverage, so a baseline of 4 is justified. The description adds meaning by explaining the tool's outcome and workflow, compensating for the lack of parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to share a Telegram URL that provides a one-time MCP token for login. It specifies the resource ('Telegram URL') and the action ('Share'), and it has zero parameters, making the scope unambiguous. The tool is distinct from siblings like 'aiworkers_whoami' and 'workers_balance' by its focus on login token delivery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool: to obtain a login token without an existing key. It also provides step-by-step instructions ('run `aiworkers-mcp login` and paste it') and clarifies that it works 'without an existing key,' guiding the agent away from requiring prior authentication. This effectively communicates the context and excludes alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dimaneuron/aiworkers-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server