Server Quality Checklist

Tool Scores

• lyzr_git_sync_governanceC
  2.5/5.0
  Behavior2/5

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

  Annotations already indicate readOnlyHint=false, signaling a mutation, but the description adds no further behavioral detail. It does not disclose whether the sync is local or remote, one-way or bidirectional, or what side effects occur. The phrase 'sync' is vague and offers little beyond the annotations.

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

  Conciseness3/5

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

  The description is a single, readable sentence with no wasted words, but it is overly terse. It omits important context about what sync actually does, so the brevity comes at the expense of necessary information.

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

  Completeness2/5

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

  Despite low parameter complexity and no output schema, the description is incomplete because 'sync' is ambiguous. It fails to clarify whether this operation commits, pushes, pulls, or overwrites the governance policy, which is essential for an agent to understand the tool's effects. This is a significant completeness gap.

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

  Parameters3/5

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

  The only parameter, 'agent_id', is fully described in the schema as 'Agent id', and the description adds no additional meaning beyond implying it refers to the agent owning the git repo. With 100% schema coverage, the description does not need to elaborate, but it also enriches the parameter's semantics only marginally.

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

  Purpose3/5

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

  The description states a clear action ('Sync') and resource ('governance policy for an agent's git repo'), giving a general sense of purpose. However, it does not differentiate 'sync' from closely related sibling tools like lyzr_git_save_governance or lyzr_git_get_governance, and the exact meaning of sync (push, pull, bidirectionally) is left ambiguous.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus the other governance tools (get, save, delete). The description gives no context on prerequisites, workflow, or situations where this tool is the appropriate choice, leaving the agent without any selection guidance.

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

• lyzr_schedule_resumeC
  2.6/5.0
  Behavior2/5

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

  Annotations already indicate a mutating operation (readOnlyHint=false) and idempotent behavior, so the description adds minimal value beyond the 'paused' state. It does not disclose side effects of resuming, such as whether it triggers an immediate run, or what errors occur for non-paused schedules.

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

  Conciseness4/5

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

  The description is one short sentence with no filler words, making it front-loaded and concise. However, this conciseness comes at the cost of missing essential details, which is factored into other dimensions.

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

  Completeness2/5

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

  For a state-changing tool with no output schema, the description omits return values, prerequisites, and behavioral effects. It only states the action, leaving the agent without enough context to invoke it confidently.

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

  Parameters1/5

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

  The single required parameter schedule_id is not explained at all. The description never mentions how to obtain or format the ID. With schema_description_coverage at 0%, the description must compensate but does not.

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

  Purpose4/5

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

  The description uses a specific verb 'Resume' with a resource 'schedule' and the condition 'paused', clearly stating what the tool does. However, it does not distinguish itself from sibling tools like schedule_trigger or schedule_pause beyond the verb and paused-state condition.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives. It does not mention schedule_trigger as an alternative for starting a schedule or explain what happens if the schedule is not paused. The only context is the implicit 'paused' prerequisite.

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

• lyzr_create_workflowC
  2.7/5.0
  Behavior2/5

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

  Annotations indicate readOnlyHint=false, so the write nature is already known. The description adds no further behavioral information—nothing about duplicate handling, required flow_data, authentication, or side effects. It does not contradict annotations, but fails to enrich them.

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

  Conciseness2/5

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

  The description is a single sentence that essentially restates the tool name ('Create a new workflow' vs 'Create Workflow'). While short, it is under-specified rather than informative, and the sentence does not earn its place by adding unique value.

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

  Completeness2/5

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

  With no output schema and a one-sentence description, the tool lacks contextual completeness. It does not explain what a workflow is, what flow_data should contain, or any operational context. For a create operation with multiple parameters, more context is needed for reliable invocation.

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

  Parameters3/5

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

  The input schema provides 100% parameter descriptions (flow_name, flow_data, api_key), so the baseline is 3. The description itself contributes no parameter semantics; it does not mention any of the parameters or their roles. Since schema coverage is complete, no penalty is applied.

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

  Purpose4/5

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

  The description 'Create a new workflow' clearly identifies the action (create) and resource (workflow), distinguishing it from siblings like lyzr_update_workflow, lyzr_get_workflow, and lyzr_delete_workflow. It is a straightforward purpose statement, though it adds little beyond the title.

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

  Usage Guidelines2/5

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

  The description gives no guidance on when to use this tool versus alternatives. It does not mention prerequisites, how it relates to update/get/delete workflow tools, or any context for when creation is appropriate. There is no usage direction beyond the stated purpose.

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

• lyzr_get_agent_eval_resultC
  2.7/5.0
  Behavior2/5

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

  The description adds no behavioral detail beyond what annotations already declare. Annotations indicate readOnly, idempotent, and non-destructive, but the description does not mention return format, pagination, auth requirements, or any other behavioral trait. It does not contradict annotations, but it also provides no supplementary context.

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

  Conciseness4/5

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

  The description is a single, front-loaded sentence with no wasted words. It is efficient for a simple getter, though its brevity is also a cause of under-specification. It earns high marks for conciseness but not for substance.

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

  Completeness2/5

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

  With no output schema and minimal annotations, the description leaves important context unstated, such as what the result contains or whether the ID is a config ID rather than an evaluation run ID. Given the simplicity of the tool, a slightly richer description would be needed to ensure correct invocation and interpretation of results.

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

  Parameters2/5

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

  The schema already covers 100% of parameter documentation, but the description introduces ambiguity by saying 'agent eval id' while the schema clarifies 'Agent eval config id'. The description does not add meaning and could mislead the agent about which ID type is expected.

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

  Purpose4/5

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

  The description uses a clear verb ('Get') and resource ('agent evaluation results') with a scoping identifier ('by agent eval id'). However, it does not distinguish itself from closely related siblings like lyzr_get_agent_eval or lyzr_get_agent_eval_result_by_agent, which also involve agent evaluations.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives. It simply states what it does without mentioning when it is appropriate, conditions, or exclusions. Related sibling tools exist that could be confused with this one.

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

• lyzr_kb_sync_sharepoint_oauth_exchangeC
  2.7/5.0
  Behavior2/5

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

  Annotations already indicate readOnlyHint=false and idempotentHint=false, so the agent knows it is a non-read, non-idempotent action. However, the description adds no behavioral context beyond the bare word 'exchange' and the deprecated flag. It does not disclose side effects, what happens to tokens, or any required preconditions.

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

  Conciseness5/5

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

  The description is a single sentence, front-loaded with [deprecated] and a clear action. It is appropriately concise for a tool with no parameters, with no wasted words.

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

  Completeness2/5

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

  With no output schema and no parameter documentation, the description should explain what 'exchange' produces or how it fits into the SharePoint OAuth flow. It does neither. The deprecated status is noted, but the tool's purpose, inputs, and outputs remain largely unexplained for an agent.

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

  Parameters1/5

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

  The input schema has zero properties, yet the description refers to an 'OAuth authorization code' as the thing being exchanged. This implies a required parameter that cannot actually be provided through the schema, which is misleading. The description does not add useful parameter semantics; it creates a mismatch.

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

  Purpose4/5

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

  The description uses a specific verb and resource: 'Exchange a SharePoint OAuth authorization code.' This clearly states the action and target. It does not explicitly differentiate from sibling tools like authorize/callback, but the [deprecated] tag plus the action verb gives reasonable clarity.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives. The [deprecated] marker implies it should not be used but does not name a replacement or explain the OAuth flow context. Sibling tools (authorize, callback) suggest a multi-step flow, but the description does not clarify the relationship.

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

• lyzr_livesource_ext_webhook_postC
  2.7/5.0
  Behavior2/5

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

  Annotations indicate readOnlyHint=false and destructiveHint=false, so it is known to be a non-destructive write. However, the description adds no behavioral details such as whether the call is idempotent (though idempotentHint=false is already set), what happens on success/failure, or any prerequisites. No additional context beyond annotations is provided.

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

  Conciseness5/5

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

  The description is a single concise sentence, front-loaded with the verb 'Send'. There is no fluff or redundant phrasing, making it easy to parse quickly.

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

  Completeness2/5

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

  With one parameter and no output schema, the description should still explain what happens after sending the payload (e.g., return value, errors, side effects). It does not, so the agent cannot predict the outcome of the call. This is a significant gap for a mutation tool.

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

  Parameters3/5

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

  The schema has one required parameter 'payload' described as 'Webhook notification payload' with 100% coverage. The tool description adds only the example 'from a SharePoint change feed', which gives a hint about payload provenance but no further structure or validation information. Thus it meets the baseline for well-covered schemas.

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

  Purpose3/5

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

  The description uses the verb 'Send' with the resource 'live source webhook notification payload', which states the basic action. However, it does not explain the purpose or effect of sending the payload, nor does it distinguish this from sibling tools like lyzr_livesource_ext_webhook_get or lyzr_kb_sync_webhook_notification. The example 'from a SharePoint change feed' adds some context but leaves ambiguity about whether the agent is sending or receiving the notification.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus the many sibling webhook-related tools. No alternatives or exclusions are mentioned. The single example does not imply a clear usage scenario beyond having a payload from a live source.

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

• lyzr_update_file_upload_credentialC
  2.7/5.0
  Behavior1/5

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

  The description says 'optionally replacing its files', which implies a potentially destructive action (overwriting/removing old files), while annotations set destructiveHint to false. This is a contradiction, as the description suggests destructive behavior that the annotation explicitly denies. The description also does not disclose other behavioral nuances such as whether existing files are merged or completely replaced.

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

  Conciseness5/5

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

  The description is a single, concise sentence that front-loads the main action and key optional behavior. No unnecessary words; every phrase contributes to understanding the tool's purpose.

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

  Completeness2/5

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

  Given that there is no output schema, the description should explain return values or additional side effects, but it does not. It also fails to specify what fields are valid in update_data or how file replacement interacts with existing files. The tool is minimally described, leaving the agent to rely solely on parameter names.

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

  Parameters3/5

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

  Schema description coverage is 100%, so all parameters (credential_id, update_data, files) are already documented in the schema. The description merely restates the optional file replacement, adding no new semantic details. It does not clarify the structure of update_data beyond 'JSON-encoded string'.

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

  Purpose4/5

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

  The description clearly states the action ('Update') and the resource ('file-upload provider credential'), and adds the optional file replacement behavior. It distinguishes itself from the more generic sibling tool 'lyzr_update_provider_credential' by specifying 'file-upload'. However, it doesn't elaborate on what 'update_data' encompasses.

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

  Usage Guidelines2/5

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

  No explicit guidance is provided on when to use this tool versus alternatives like 'lyzr_update_provider_credential'. The specialization to 'file-upload' is implied by the name, but the description does not state any exclusions or direct comparison with sibling tools.

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

• lyzr_create_composio_auth_configC
  2.8/5.0
  Behavior2/5

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

  Annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false) already convey the safety profile, but the description adds no further behavioral context: it does not state the return value (there is no output schema), whether duplicates are created on repeat calls, or whether an OAuth flow is triggered. The description essentially restates the title and nothing more.

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

  Conciseness3/5

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

  The one-sentence description is free of fluff, but it is largely redundant with the title ('Create Composio Auth Config' vs 'Create a Composio auth config for a provider') and provides no additional value, so it reads as under-specification rather than efficient conciseness.

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

  Completeness2/5

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

  For a create operation with 4 parameters and no output schema, the description should explain the response format, prerequisites, and relationship to the sibling get/delete_composio_auth_config tools. None of this is present, making the description incomplete for an agent to invoke and interpret results correctly.

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

  Parameters3/5

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

  Schema description coverage is 100% with useful per-parameter descriptions (e.g., 'Space-separated OAuth scopes', 'OAuth client id'). The description itself adds no parameter detail, so the baseline of 3 applies.

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

  Purpose4/5

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

  The description uses a specific verb ('Create') with a specific resource ('Composio auth config') and adds scope ('for a provider'). It distinguishes from the sibling get/delete_composio_auth_config tools via the verb, though it does not clarify how a Composio auth config differs from other credential tools like lyzr_create_oauth_tool_credential.

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

  Usage Guidelines2/5

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

  No usage guidance is provided. The description does not mention when to use this tool, prerequisites, or alternatives such as lyzr_create_provider_credential or lyzr_create_oauth_tool_credential, leaving the agent to guess among many similar create-credential siblings.

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

• lyzr_create_oauth_tool_credentialC
  2.8/5.0
  Behavior2/5

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

  The description adds no behavioral context beyond what annotations already provide. Annotations indicate non-read-only, non-idempotent, non-destructive, but the description merely describes the create action without disclosing side effects, authentication requirements, or response behavior.

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

  Conciseness3/5

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

  The description is a single sentence, which is concise, but it is also under-specified and essentially restates the title. It lacks meaningful content, so while it is short, it doesn't add value.

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

  Completeness2/5

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

  Given the tool's complexity (11 parameters, nested objects, no output schema), the description is far too minimal. It doesn't explain when to use OAuth credentials, how the flow works, or any other context. It is incomplete for this complexity level.

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

  Parameters3/5

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

  The schema has 100% coverage of parameter descriptions, so the tool description doesn't need to add parameter details. It doesn't, but the schema already provides meaning for all 11 parameters, so baseline 3 is appropriate.

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

  Purpose4/5

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

  The description uses a clear verb 'Create' and specifies the resource as 'OAuth tool credential for a provider', which unambiguously states the action. However, it does not differentiate from sibling tools like lyzr_create_static_tool_credential or lyzr_create_provider_credential, so it lacks sibling differentiation.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or context. It simply states the action without exclusions or alternative references.

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

• lyzr_kb_sync_cc_pairs_resumeC
  2.8/5.0
  Behavior2/5

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

  The description adds minimal behavioral context beyond the title. Annotations already indicate a non-destructive, idempotent write operation, but the description does not explain what 'resume' entails (e.g., whether it re-enables scheduled syncs or triggers an immediate sync), nor any side effects. It is not contradictory to the annotations, but it does not enrich them.

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

  Conciseness3/5

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

  The description is a single concise sentence with no waste. However, it essentially restates the tool's title and lacks substantive detail, so it is more under-specified than minimally viable, though not as sparse as a pure tautology.

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

  Completeness2/5

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

  For a simple one-parameter tool with annotations and no output schema, the description is incomplete. An agent would need to infer the relationship to pause/sync/list siblings and understand what resuming implies for the pair's state. This contextual gap limits the agent's ability to select and invoke the tool confidently.

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

  Parameters3/5

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

  The input schema provides 100% coverage with a clear description for 'cc_pair_id', so the description does not need to compensate. The tool description merely repeats the resource name without adding extra meaning such as how to obtain the ID or validation rules, which meets the baseline for high schema coverage.

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

  Purpose4/5

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

  The description clearly states the action ('Resume syncing') and the resource ('connector-credential pair'), effectively conveying the tool's purpose. It distinguishes from the sibling 'sync' tool by implying a continuation of prior syncing rather than a fresh manual trigger, though this differentiation is implicit rather than explicit.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool relative to alternatives like lyzr_kb_sync_cc_pairs_sync or lyzr_kb_sync_cc_pairs_pause. There is no mention of prerequisites (e.g., the pair must be paused or already exist) or when not to use it.

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

• lyzr_schedule_createC
  2.8/5.0
  Behavior2/5

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

  Annotations already indicate a non-read-only, non-idempotent operation, but the description adds nothing beyond the cron format, which is already in the schema. It doesn't disclose whether multiple calls create multiple schedules, whether an existing schedule is overwritten, or any side effects beyond simply creating a schedule.

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

  Conciseness5/5

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

  The description is a single, tightly worded sentence that front-loads the core action. It includes the most important detail (cron format) and nothing superfluous.

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

  Completeness2/5

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

  With 7 parameters including timezone and retry settings, and no output schema, a one-sentence description is inadequate. The agent gets no sense of persistence behavior, return value, or failure modes, leaving significant ambiguity for a create operation.

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

  Parameters2/5

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

  The description repeats the 5-field cron format already documented in the schema's cron_expression parameter. No additional meaning is added for timezone, retries, message, or user/agent IDs beyond the schema field descriptions.

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

  Purpose4/5

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

  The description clearly states the action ('schedule an agent') and specifies the cron expression format. It is distinct from the sibling schedule tools in name (py_schedule_create vs trigger/delete/list), though the description itself doesn't explicitly contrast with them.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives like lyzr_schedule_trigger, lyzr_schedule_pause, or lyzr_schedule_delete. It doesn't mention prerequisites such as the agent needing to exist or how to later manage the schedule.

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

• lyzr_agent_create_single_taskC
  2.9/5.0
  Behavior2/5

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

  Annotations already indicate a non-read-only create operation (readOnlyHint=false), and the description adds no extra behavioral context such as required credentials, side effects, or return value. The word 'template' hints at a behavioral distinction, but it is not elaborated, so the description adds little beyond the annotations.

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

  Conciseness4/5

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

  The description is a single, front-loaded sentence with no filler or redundancy. It is concise, though extremely brief; the conciseness itself is good, but the terseness limits the value added.

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

  Completeness2/5

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

  For a create tool with 11 parameters, 5 required fields, a nested object, and no output schema, a one-sentence description is inadequate. It fails to explain the return value, the meaning of 'template', or any prerequisites, so the agent cannot confidently understand the tool's full behavior.

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

  Parameters3/5

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

  The input schema covers 91% of the parameters with meaningful descriptions, so the schema carries most of the parameter semantics. The description adds no parameter-specific meaning, but with high schema coverage, the baseline score of 3 is appropriate.

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

  Purpose4/5

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

  The description states the core action ('Create') and the resource ('a single-task template agent'), which is specific and distinguishes it somewhat from general agent creation. It uses 'template' to add nuance, but it does not explicitly contrast with the sibling lyzr_create_agent, so it falls just short of full differentiation.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives. It does not mention that lyzr_create_agent might be more appropriate for general agents or that lyzr_agent_update_single_task is the corresponding update tool, leaving usage entirely to inference from names.

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

• lyzr_agent_update_single_taskC
  2.9/5.0
  Behavior2/5

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

  Annotations already declare this as a mutating, idempotent, non-destructive operation, but the description adds no behavioral context such as whether the update is partial or full, which fields are required, or what happens to omitted fields. This is a significant gap for an update 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/5

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

  The description is a single concise sentence with no filler words, making it front-loaded and easy to parse. However, it is under-specified, sacrificing completeness for brevity.

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

  Completeness2/5

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

  For a 12-parameter mutation tool with no output schema, the description is too sparse. It omits update semantics (partial vs. full), required fields' behavior, and return value format. The schema covers parameters but not the behavioral context needed for correct invocation.

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

  Parameters3/5

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

  With 92% schema description coverage, the schema already documents most parameters clearly. The description adds no additional parameter semantics, so it does not improve on the schema but also does not detract from it.

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

  Purpose4/5

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

  The description clearly states the verb ('Update') and resource ('single-task template agent by id'), which distinguishes it from sibling tools like lyzr_update_agent and lyzr_agent_create_single_task. However, 'template agent' is not defined, leaving some ambiguity about what exactly is updated.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives such as lyzr_update_agent or lyzr_agent_create_single_task. The description implies usage by naming the resource, but it lacks explicit context, prerequisites, or exclusions.

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

• lyzr_chat_completions_v4C
  2.9/5.0
  Behavior2/5

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

  The description adds only 'OpenAI-compatible' and '(model + messages)' beyond the annotations. It does not disclose implications of readOnlyHint=false and openWorldHint=true, such as potential side effects from tool calls or streaming behavior, which would be valuable for a chat completion endpoint.

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

  Conciseness4/5

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

  The description is a single, front-loaded sentence that immediately conveys the essential compatibility and required inputs. It loses a point because 'v4' redundantly repeats the title and the sentence could have used the scarce space to include usage differentiation.

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

  Completeness2/5

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

  This is a complex 17-parameter endpoint with no output schema and many related sibling tools, yet the description is too sparse to guide correct invocation. It leaves out response format, streaming behavior, and how this endpoint differs from other chat completion variants, making it inadequate for confident use.

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

  Parameters3/5

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

  The input schema has 100% description coverage for all 17 parameters, so the description is not required to explain them. The mention of 'model + messages' only reinforces the schema's required fields without adding new meaning.

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

  Purpose4/5

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

  The description clearly states this is an OpenAI-compatible v4 chat/completions endpoint requiring model and messages, which gives a specific resource and identifies the key inputs. However, it does not distinguish itself from sibling tools like lyzr_simple_chat_completions or lyzr_agent_chat_completions, so it falls short of a 5.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives such as lyzr_chat, lyzr_agent_chat_completions, or lyzr_create_inference_v4. The description merely labels it as OpenAI-compatible, which implies a context but does not explicitly state exclusions or preferred scenarios.

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

• lyzr_create_aci_custom_appC
  2.9/5.0
  Behavior2/5

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

  Annotations indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false, which already convey that this is a mutating, non-destructive, non-idempotent operation. The description adds no behavioral context beyond the word 'create'. Notably, the schema includes a skip_dry_run parameter implying a dry-run validation behavior, but the description does not mention this or any side effects, making it under-transparent for a creation tool.

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

  Conciseness4/5

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

  The description is a single concise sentence that is easy to parse and directly states the action. However, it is minimal to the point of lacking useful structure, such as separating out key details (e.g., validation, required fields) that could aid comprehension. Still, it earns its place and has no wordiness.

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

  Completeness2/5

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

  This is a complex creation tool with nested objects, a dry-run option, and no output schema, yet the description is only one sentence. It does not explain what an ACI custom app is, what should go into app_json/functions_json, or the significance of skip_dry_run. The annotations and schema cover some basics, but the description alone is inadequate to guide an agent through using this tool correctly.

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

  Parameters3/5

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

  The input schema has 100% description coverage for all four parameters (app_json, functions_json, secrets, skip_dry_run), so the schema already documents the parameters well. The tool description itself adds no parameter information, so it fits the baseline for high schema coverage. No additional semantic detail is provided by the description.

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

  Purpose4/5

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

  The description 'Create a new ACI custom app with its functions' clearly states the verb (create), resource (ACI custom app), and scope (with functions). It distinguishes from sibling tools like create_agent or create_workflow because it names the specific resource type. However, it could be slightly more detailed about what an ACI custom app is, but the core purpose is unmistakable.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives, such as lyzr_create_aci_configuration or lyzr_create_lyzr_aci_tool. It does not mention any prerequisites, use cases, or exclusions. The agent is left to infer when this tool is appropriate based solely on the name.

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

• lyzr_create_feature_flagC
  2.9/5.0
  Behavior2/5

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

  The description adds no behavioral traits beyond what annotations already indicate. While annotations show this is a non-readOnly, non-destructive operation, the description does not mention side effects, uniqueness constraints on the flag key, or any error conditions. It simply restates the title.

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

  Conciseness4/5

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

  The description is a single sentence with no wasted words, making it extremely concise and front-loaded. It conveys the core purpose clearly, though it borders on being too sparse.

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

  Completeness2/5

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

  For a tool with 8 parameters, no output schema, and minimal annotations, the description is insufficiently complete. It does not explain what the tool returns, what happens on duplicate keys, or any behavioral details. The rich schema offsets some gaps, but the description itself adds very little context.

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

  Parameters3/5

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

  Schema description coverage is 100% (all 8 parameters have descriptions in the schema), so the baseline is 3. The description itself provides no parameter-specific semantics, but it does not need to compensate for missing schema info.

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

  Purpose4/5

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

  The description 'Create a new feature flag' uses a specific verb and identifies the resource (feature flag). It distinguishes itself from sibling tools like update/delete/get feature flags by indicating the create operation, though it does not add additional scope or 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/5

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

  There is no guidance on when to use this tool versus alternatives such as update_feature_flag or list_feature_flags. The only implied usage is the verb 'create,' which is minimal and does not cover prerequisites, exclusions, or common use cases.

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

• lyzr_create_lyzr_aci_toolC
  2.9/5.0
  Behavior2/5

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

  Annotations declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds no behavioral context, such as the dry-run validation implied by the 'skip_dry_run' parameter, nor does it mention side effects, permissions, or reversibility.

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

  Conciseness4/5

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

  The description is a single, efficient sentence with zero waste. However, it is somewhat under-specified, but the brevity is still a strength.

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

  Completeness2/5

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

  There is no output schema, behavioral information, or usage context. For a creation tool with required nested objects (app_json, functions_json) and a dry-run flag, the description should explain what the tool accomplishes, when to use it, and what outcomes to expect. It falls short.

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

  Parameters3/5

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

  The input schema provides descriptions for all 5 parameters, covering 100% of the schema. The description adds no additional parameter semantics, so the baseline of 3 is appropriate.

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

  Purpose4/5

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

  The description states 'Create a new org-wide Lyzr ACI tool' with a specific verb (create), resource (Lyzr ACI tool), and scope (org-wide). It clearly identifies the action, though it does not differentiate from sibling tools like create_aci_custom_app or create_tool.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives. The description is a single sentence with no mention of use cases, prerequisites, or exclusions, leaving the agent without direction for tool selection.

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

• lyzr_create_lyzr_providerC
  2.9/5.0
  Behavior2/5

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

  Annotations already indicate a mutating, non-idempotent operation, but the description adds no further behavioral context. It does not mention side effects, duplicate behavior, auth requirements, return values, or what happens to existing provider connections.

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

  Conciseness4/5

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

  The description is a single concise sentence with no filler and is easy to parse. It is slightly too terse to convey important distinctions, but as a summary statement it is well-structured and front-loaded.

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

  Completeness2/5

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

  With no output schema and a very large sibling set including lyzr_create_provider, the description is too incomplete. It does not explain return behavior, the meaning of 'Lyzr-managed', or the role of meta_data, making it insufficient for reliable tool selection and invocation.

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

  Parameters3/5

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

  The input schema has 100% description coverage for all three parameters, so the baseline is 3. The description adds no extra meaning about how 'type' or 'meta_data' relate to Lyzr-managed providers, so it does not improve upon the schema.

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

  Purpose4/5

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

  The description clearly states a specific verb ('Create') and resource ('Lyzr-managed provider connection'), so the basic purpose is unambiguous. However, it does not explain what 'Lyzr-managed' means or how it differs from the sibling lyzr_create_provider, so distinction from related tools is incomplete.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives like lyzr_create_provider, lyzr_credential_create, or other provider-related tools. The phrase 'Lyzr-managed' implies a use case, but there are no explicit contexts, prerequisites, or exclusions.

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

• lyzr_create_providerC
  2.9/5.0
  Behavior2/5

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

  Annotations indicate readOnlyHint=false and openWorldHint=true, so it is clearly a mutating operation with open-world side effects, but the description adds no behavioral context such as whether this overwrites existing connections, requires authentication, or has any side effects (e.g., provisioning external resources). It only states the action and object.

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

  Conciseness4/5

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

  The description is a single, clear sentence with no wasted words. It is front-loaded and easy to parse, though it is minimal and does not elaborate on context.

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

  Completeness2/5

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

  For a tool with four parameters (three required), nested objects, and no output schema, the description is too thin. It fails to explain what a 'provider connection' is, how it relates to credentials or other provider concepts, and what the expected outcome is. The abundance of sibling tools increases the need for context, which is absent.

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

  Parameters3/5

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

  The input schema covers all four parameters with descriptions (100% coverage), so parameters are already documented. The description adds no parameter information, so it doesn't improve on the schema. Baseline 3 applies.

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

  Purpose4/5

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

  The description uses the specific verb 'Create' and identifies the resource as 'a new provider connection' (not just a provider). However, it does nothing to distinguish this from closely named siblings such as lyzr_create_lyzr_provider or lyzr_create_provider_credential, so it doesn't fully disambiguate.

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

  Usage Guidelines2/5

  Does 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 choose this tool over the many provider-related alternatives (e.g., lyzr_create_lyzr_provider, lyzr_create_provider_credential, lyzr_update_provider), nor any prerequisites or exclusions.

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

• lyzr_create_response_v4C
  2.9/5.0
  Behavior2/5

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

  Annotations already indicate readOnlyHint=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false. The description adds no extra behavioral context about what the endpoint actually does, what side effects it has, or what the response looks like. It merely restates the endpoint name.

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

  Conciseness4/5

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

  The description is a single sentence with zero fluff, which is concise and front-loaded. But, it is so short that it omits important decision-making information. Still, from a pure conciseness and structure standpoint, it is efficient and earns a 4.

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

  Completeness2/5

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

  Given the tool has 16 parameters, no output schema, and a one-line description, it is inadequate for an agent to understand the full behavior, return values, or when to use it. The description provides only a bare label without any situational or operational context.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all 16 parameters. The description mentions model, input, and tools, but these are trivially understandable from their names. The description adds no extra semantic meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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

  Purpose4/5

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

  The description clearly identifies the tool as an OpenAI-compatible v4 responses endpoint with 'create response' semantics, which distinguishes it from many siblings. However, it doesn't explicitly differentiate it from closely related tools like lyzr_chat_completions_v4 or lyzr_create_inference_v4, so it's clear but not fully distinguishing.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It simply states what the endpoint is without any context on when it should be preferred over chat/completions or other response-generation tools.

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

• lyzr_create_static_tool_credentialC
  2.9/5.0
  Behavior2/5

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

  Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false, which align with the creation operation. The description adds no behavioral context beyond what annotations provide—it doesn't disclose conflict behavior, required permissions, or whether credentials are stored securely. Without this, the agent lacks insight into the mutation'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.

  Conciseness4/5

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

  The description is a single sentence with no redundant words, making it concise and front-loaded. The mention of 'static (non-OAuth)' is valuable for disambiguation. However, it is extremely brief and could incorporate useful context (e.g., relationship to providers) without becoming verbose.

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

  Completeness3/5

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

  Given the 100% schema coverage and annotations, the description provides minimal but sufficient context to distinguish static from OAuth credentials. Yet it omits practical details such as return values (no output schema exists), prerequisites (e.g., provider must exist), and the intended use of the credential in tools or agents. This makes the tool adequate but not fully self-explanatory.

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

  Parameters3/5

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

  Input schema has 100% coverage with clear parameter descriptions (e.g., 'Credential key/value payload, e.g. { api_key: ... }'). The tool description adds no parameter-specific semantics, so it relies entirely on the schema. Since schema coverage is complete, a baseline score of 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states 'Create a static (non-OAuth) tool credential,' specifying the verb (create), resource (tool credential), and key differentiator (non-OAuth). This distinguishes it from the sibling tool lyzr_create_oauth_tool_credential. However, it doesn't elaborate on what a 'tool credential' is used for, which would enhance clarity further.

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

  Usage Guidelines2/5

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

  The description only implicitly suggests usage for static credentials versus OAuth, but it provides no explicit guidance on when to choose this tool over alternatives like lyzr_credential_create or lyzr_create_provider_credential. There are no when/when-not criteria or references to other tools, leaving the agent to infer usage context.

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

• lyzr_execute_workflowC
  2.9/5.0
  Behavior2/5

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

  Annotations indicate a non-read-only, non-idempotent operation, but the description adds no behavioral context beyond that, such as whether execution is asynchronous, returns a run ID, or has potential side effects. The phrase 'optionally passing input data' is already captured by the schema.

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

  Conciseness5/5

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

  The description is a single sentence that efficiently states the action and the optional parameter. It is front-loaded and contains no unnecessary words.

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

  Completeness2/5

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

  For a side-effecting tool with no output schema, the description is incomplete. It does not explain what the caller gets back (e.g., run ID, status), whether the workflow must already exist, or how this relates to sibling workflow tools. This leaves the agent uncertain about the execution result.

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

  Parameters3/5

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

  Schema coverage is 100% with clear descriptions for both flow_id and input_data, so the baseline is 3. The description merely rephrases the optional input_data without adding detail like expected format or examples.

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

  Purpose4/5

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

  The description clearly states the tool executes a workflow with optional input data, using a specific verb and resource. This distinguishes it from workflow creation, deletion, or listing, though it does not explicitly contrast with lyzr_trigger_workflow_with_file.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives such as lyzr_trigger_workflow_with_file or how to decide between executing a workflow and starting a task. There is no mention of prerequisites or scenarios where this tool is preferred.

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

• lyzr_git_deploy_branchC
  2.9/5.0
  Behavior2/5

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

  Annotations indicate the operation is not read-only and is not destructive, but the description adds no details about side effects (e.g., whether deployment overrides the current live version, requires a commit, or is reversible). The agent is left unaware of what actually happens during deploy, making this a significant transparency gap.

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

  Conciseness5/5

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

  The entire description is a single 9-word sentence that is front-loaded and contains no filler, precisely conveying the tool's core action.

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

  Completeness2/5

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

  This deployment tool has no output schema and annotations only state the operation is non-read-only and non-destructive. The description fails to explain the outcome, return value, or any post-deployment steps, making it incomplete for an AI agent to use safely, especially given the existence of a large set of sibling git tools.

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

  Parameters3/5

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

  The input schema already describes both parameters ('Branch to deploy', 'Agent id') at 100% coverage, and the description only restates the same information ('branch of an agent's git repo'), adding no syntactic or semantic detail beyond the schema.

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

  Purpose4/5

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

  The description states 'Deploy a branch of an agent's git repo,' which uses a specific verb ('deploy') and resource ('branch'), clearly distinguishing it from sibling git tools like merge_branches or switch_branch. However, it doesn't elaborate on what deployment entails or explicitly contrast with alternatives, so it's clear but not maximally differentiated.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool over sibling git operations (e.g., git_merge_branches, git_switch_branch, or git_create_pr). It doesn't mention prerequisites, workflow 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.

• lyzr_git_init_repoC
  2.9/5.0
  Behavior2/5

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

  Annotations already indicate this is not read-only and not idempotent, but the description adds no extra behavioral context. It does not explain what 'initializing' entails (e.g., creating a local repo, configuring remotes) or any side effects on the agent's workspace. The description essentially restates the action without disclosure.

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

  Conciseness5/5

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

  The description is a single sentence with no fluff. It is front-loaded and every word earns its place, though it is extremely brief.

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

  Completeness2/5

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

  Even with low complexity (one param, no output schema), the description is too sparse to be complete. It does not explain what happens when the repo is initialized, how it relates to other git tools, or any side effects. The agent would likely need to guess about the expected behavior.

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

  Parameters3/5

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

  Schema coverage is 100% and the single parameter 'agent_id' is described with 'Agent id'. The description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate.

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

  Purpose4/5

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

  The description uses a specific verb 'Initialize' with a clear resource ('git repository') and target ('for an agent'), distinguishing it from other git operations like status, commit, or branch. It is clear enough, though it doesn't differentiate from similar setup tools like git_save_config.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool vs alternatives. There is no mention of prerequisites, such as needing to create the agent first, or that this should be the first step before other git operations. The context is only implied by the tool name and description.

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

• lyzr_kb_sync_webhook_notificationC
  2.9/5.0
  Behavior2/5

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

  Annotations already indicate readOnlyHint=false and openWorldHint=true. The description only adds deprecation status and does not disclose what happens to the payload (processing, side effects, response format). It adds minimal behavioral context beyond the annotations.

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

  Conciseness4/5

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

  The description is a single, concise sentence with the deprecation notice front-loaded. It contains no fluff, though it could have briefly mentioned an alternative tool for the deprecated functionality.

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

  Completeness2/5

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

  For a webhook receiver with one optional object parameter and no output schema, the description is too thin. It lacks usage context, deprecation replacement, accepted payload structure, and what the caller should expect after invoking the tool.

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

  Parameters3/5

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

  Schema coverage for the single 'payload' parameter is 100% with a clear description ('Raw webhook notification payload'). The tool description does not add new parameter meaning, but the schema already fully documents it, so the baseline score of 3 applies.

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

  Purpose4/5

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

  The description clearly states the tool receives a KB Sync webhook notification payload, using a specific verb and resource. However, it does not differentiate from the sibling lyzr_kb_sync_webhook_validation tool or explain how 'notification' differs from 'validation'.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. The '[deprecated]' marker implies it should not be used but does not mention a replacement tool or the webhook notification flow context.

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

• lyzr_kb_train_pdfC
  2.9/5.0
  Behavior2/5

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

  The annotations already indicate this is a non-read-only, non-idempotent operation, but the description adds little beyond that it uploads and trains a PDF. It does not disclose asynchronous behavior, output/return format, file size limits, or potential side effects on the knowledge base, which is significant for a mutating tool with no output schema.

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

  Conciseness4/5

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

  The description is a single, focused sentence with no filler or redundancy. It is well-structured and front-loaded, though it is quite sparse and could incorporate more useful detail without becoming verbose.

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

  Completeness2/5

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

  Given the tool has 9 parameters, no output schema, and mutating behavior, the one-line description is incomplete. It does not explain how the training process works, whether it is synchronous or async, how to verify success, or what the caller should expect in return, leaving significant gaps for an agent.

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

  Parameters3/5

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

  The schema provides 100% parameter coverage with clear descriptions for all 9 fields, so the baseline is 3. The tool description itself adds no parameter-level meaning beyond what the schema already documents, so it neither improves nor harms the agent's understanding.

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

  Purpose4/5

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

  The description clearly states the action ('upload and train') and the resource ('a PDF file into a knowledge base'), which is more specific than the title alone. However, it does not explicitly distinguish this from sibling tools like lyzr_kb_train_documents or lyzr_parse_pdf, so it stops short of full differentiation.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives such as lyzr_kb_train_text, lyzr_kb_train_website, or lyzr_kb_train_documents. The description offers no context, prerequisites, or exclusions, leaving the agent without direction for tool selection.

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

• lyzr_kb_train_textC
  2.9/5.0
  Behavior2/5

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

  The description adds no behavioral context beyond what annotations already provide. It does not disclose whether the operation appends or replaces existing content, whether it is asynchronous, or whether there are rate limits or other consequences. With readOnlyHint=false, idempotentHint=false, the agent knows it's a write and non-idempotent, but the description offers no additional transparency.

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

  Conciseness5/5

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

  The description is a single concise sentence that is front-loaded with the action and resource. Every word earns its place, with no unnecessary filler.

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

  Completeness2/5

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

  Given the simplicity of the tool, the description remains incomplete: it does not explain the return behavior, whether the operation is synchronous, or any prerequisites. The absence of an output schema means the agent may be left unsure about the outcome or error conditions.

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

  Parameters3/5

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

  Schema coverage is 100% with both parameters ('texts', 'rag_id') already described. The description adds no new parameter semantics, so the baseline of 3 applies.

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

  Purpose4/5

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

  The description clearly states the action (ingest) and the resource (text chunks into a knowledge base), distinguishing it from sibling tools like train_website or train_documents. It lacks explicit sibling differentiation, but the resource type is specific enough.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives such as lyzr_kb_train_website or lyzr_kb_train_documents. There is no mention of prerequisites (e.g., KB must exist) or context for choosing this over other training methods.

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

• lyzr_kg_deduplicateC
  2.9/5.0
  Behavior2/5

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

  The description adds minimal behavioral context beyond the annotations. It does not explain whether duplicates are merged or removed, whether the operation is asynchronous, or whether special permissions are needed. Despite destructiveHint=false, deduplication could involve irreversible changes, and the description does not address this.

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

  Conciseness5/5

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

  The description is a single concise sentence with no fluff or redundant wording. It is front-loaded and effectively communicates the core action.

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

  Completeness2/5

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

  Contextual completeness is low: the tool mutates the knowledge graph, has no output schema, and the description does not mention return values, side effects, or whether the operation is synchronous or asynchronous. An agent cannot confidently anticipate the outcome or follow-up steps.

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

  Parameters3/5

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

  The schema fully covers the single parameter, rag_id, with the description 'Knowledge base id'. The tool description adds no parameter-specific details, so the baseline of 3 is appropriate because the schema already provides sufficient clarity.

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

  Purpose4/5

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

  The description uses a specific verb 'deduplicate' with a clear resource ('entities in a knowledge base's graph'), making the tool's purpose understandable. However, it does not explicitly differentiate from the sibling tool lyzr_kg_ext_deduplicate_neo4j, so it is clear but not fully distinguishing.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives like the Neo4j-specific deduplication tool. There are no exclusions, prerequisites, or mention of alternative workflows, leaving the usage context only weakly implied by the name and description.

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

• lyzr_kg_ext_train_fileC
  2.9/5.0
  Behavior2/5

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

  Annotations already indicate a non-read-only, non-idempotent, open-world operation, but the description adds no behavioral detail. It does not disclose whether training appends to or replaces existing graph data, whether it is synchronous, or what side effects it has. The annotation openWorldHint=true is acknowledged, but the description fails to explain what 'train' actually does in practical terms.

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

  Conciseness4/5

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

  The description is a single concise sentence that front-loads the core action and target. It wastes no words and is appropriate for a tool that mostly relies on the schema for parameter details. However, the brevity also omits helpful context, which prevents a perfect score.

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

  Completeness2/5

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

  For a tool with 6 parameters, no output schema, and complex behavior (training a knowledge graph), this description is far too minimal. It does not mention asynchronous behavior, return values, data size limits, or how to handle the rag_id. Given the extensive list of sibling tools, the lack of contextual guidance makes it hard for an agent to select and invoke this tool confidently.

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

  Parameters3/5

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

  The schema covers 100% of the parameters with descriptions, so the baseline is 3. The tool description does not add any extra meaning beyond the schema; it only repeats 'base64-encoded' which is already in the schema. The description could contextualize how rag_id, filename, and file_content_base64 relate to each other, but it does not, so it stays at baseline.

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

  Purpose4/5

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

  The description clearly states the action ('Upload a file') and the target ('train the Neo4j knowledge graph'), naming both the input medium and the system. However, it does not differentiate this from sibling variants like lyzr_kg_ext_train_file_neo4j or lyzr_kg_train_text, so the purpose is clear but not uniquely positioned.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives such as lyzr_kg_train_text or lyzr_kg_ext_train_file_neo4j. The description offers no prerequisites (e.g., need an existing rag_id), no exclusions, and no mention of which scenario (file upload) makes this the appropriate choice. This is a significant gap given the many closely related sibling tools.

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

• lyzr_kg_ext_train_file_neo4jC
  2.9/5.0
  Behavior2/5

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

  The annotations already indicate this is a non-read-only, non-destructive write operation. The description adds a minor detail about base64 encoding but does not disclose whether the training is synchronous, that it modifies the knowledge graph, or that a task variant exists for async processing. The 'namespaced endpoint' hint is vague and not expanded upon.

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

  Conciseness4/5

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

  The description is a single, front-loaded sentence with no wasted words. It effectively conveys the core action and input format, though the brevity leaves out context that would improve decision-making. Acceptable conciseness for a simple tool definition.

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

  Completeness2/5

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

  Given six parameters, no output schema, and many closely related sibling tools, the description is under-specified. It does not explain the expected return value, whether the operation is asynchronous, what prerequisites exist (e.g., a created rag), or how this differs from the '_task' variants. An agent may fail to anticipate the outcome or the proper sequencing.

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

  Parameters3/5

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

  All parameters are fully documented in the schema (100% coverage), so the description does not need to re-explain them. The description mentions base64 encoding, but that is already present in the file_content_base64 parameter schema. It adds no meaningful parameter semantics beyond what structured data provides.

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

  Purpose4/5

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

  The description states 'Upload a file (base64-encoded) to train the Neo4j knowledge graph (namespaced endpoint)' with a specific verb and resource. It identifies the action (upload/train) and target (Neo4j KG), but does not clearly differentiate from the non-Neo4j file-train variant beyond the 'Neo4j' wording.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives such as lyzr_kg_ext_train_file (non-Neo4j), the task-based variants, or website/text training. The description does not mention exclusions or conditions, 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.

• lyzr_kg_ext_train_file_taskC
  2.9/5.0
  Behavior2/5

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

  Annotations already indicate readOnlyHint=false and openWorldHint=true, so the side-effect profile is known. The description adds the 'async task' behavior but does not disclose the response format, whether the graph is appended or replaced, or that a task ID is returned for status polling. Minimal behavioral context beyond the annotations.

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

  Conciseness4/5

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

  The description is a single sentence, front-loaded with the verb and resource, and contains no fluff. It is efficient, though quite terse given the need for more contextual guidance. Every word earns its place, but the brevity comes at the cost of missing useful usage information.

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

  Completeness2/5

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

  No output schema exists, and the description does not explain the return value or how to poll task status. With six parameters and many sibling KG training tools, the description is too thin to fully orient an agent about the async workflow, backend selection, or post-invocation steps.

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

  Parameters3/5

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

  Schema descriptions cover 100% of parameters, so the description need not repeat parameter details. The sentence mentions base64 encoding and file upload, but these are already in the schema's property descriptions. No additional parameter semantics or usage examples are provided.

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

  Purpose4/5

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

  The description clearly states the verb 'upload' and the resource 'Neo4j knowledge graph,' and it marks the operation as an async task, which distinguishes it from synchronous variants. However, it does not differentiate from similarly named siblings like lyzr_kg_ext_train_file_task_neo4j, leaving ambiguity about which graph backend is targeted.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus the synchronous lyzr_kg_ext_train_file or how to track the async task. It does not mention using lyzr_kg_task_status to poll progress or criteria for choosing async over sync, leaving the agent to infer the workflow.

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

• lyzr_kg_ext_train_website_neo4jC
  2.9/5.0
  Behavior2/5

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

  Annotations already provide safety hints (readOnly=false, not destructive). The description only states the action and does not reveal additional behavior like whether it overwrites data, how long it takes, or whether it requires an existing RAG/agent. It adds little beyond the annotations.

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

  Conciseness5/5

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

  The description is one short, front-loaded sentence with no filler. It is concise but perhaps too sparse for a complex tool.

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

  Completeness2/5

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

  The tool has 11 parameters, nested objects, and no output schema. The description does not mention return values, side effects, prerequisites, or what 'namespaced endpoint' implies. It is not complete enough for an agent to fully understand the tool's behavior.

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

  Parameters3/5

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

  All 11 parameters have schema descriptions (100% coverage), so the description does not need to explain them. The schema already defines required fields and defaults. The description adds no parameter semantics, so baseline 3 is appropriate.

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

  Purpose4/5

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

  The description uses a specific verb ('crawl and ingest') and names the target resource ('Neo4j knowledge graph'), plus a distinguishing detail ('namespaced endpoint') that separates it from generic KG train tools. However, the meaning of 'namespaced endpoint' is left undefined, 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 Guidelines2/5

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

  No explicit guidance on when to use this tool over its siblings such as lyzr_kg_train_website or lyzr_kg_ext_train_text_neo4j. The 'namespaced endpoint' hint is implicit but does not constitute clear usage instructions.

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

• lyzr_kg_train_textC
  2.9/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint=false and destructiveHint=false, and the description adds minimal behavioral context. It mentions 'v4' but does not explain whether the operation is synchronous or asynchronous, how it handles duplicate text, or any side effects beyond what annotations already signal.

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

  Conciseness4/5

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

  The description is a single sentence with no filler, demonstrating strong efficiency. However, the brevity leaves out contextual information that would help the agent, so it is concise but not optimally structured for full understanding.

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

  Completeness2/5

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

  With six parameters, nested objects, and no output schema, the tool has moderate complexity. The description is too sparse to cover important aspects like synchronous vs. asynchronous execution, required fields, or expected return behavior, leaving clear gaps.

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

  Parameters3/5

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

  Schema description coverage is 100%, so all six parameters are already well-documented in the input schema. The description adds no additional parameter-level meaning, placing it at the baseline of 3 without further compensation.

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

  Purpose4/5

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

  The description 'Ingest text into the v4 knowledge graph' uses a specific verb and resource, and the 'v4' qualifier adds useful specificity. It distinguishes from kb_train_text (KB vs KG) and kg_train_website (text vs website), but does not explicitly contrast with the async lyzr_kg_train_text_task sibling, leaving slight 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/5

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

  No guidance is provided on when this tool should be chosen over alternatives like lyzr_kg_train_text_task or lyzr_kg_train_website. The description lacks any mention of preferred use cases, exclusions, or context-based recommendations.

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

• lyzr_list_assetsC
  2.9/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is clear. The description adds only that it is paginated, which is already captured by the input schema parameters. No additional behavioral context such as return format, asset types, or access considerations is disclosed.

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

  Conciseness5/5

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

  The description is four words long, front-loaded, and free of filler. It communicates the core action and pagination in a single concise phrase, earning high marks for conciseness, though it sacrifices informative detail.

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

  Completeness2/5

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

  This is a simple two-parameter list tool with no output schema, but the description still feels incomplete. It does not define what 'assets' refers to, whether results are scoped to the user or organization, or how this tool differs from similar sibling tools like lyzr_list_user_assets. The agent would need to guess from context.

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

  Parameters3/5

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

  Schema description coverage is 100% for both parameters (page and limit), each with clear descriptions including defaults and limits. The tool description does not add semantic value beyond the schema, so baseline 3 is appropriate.

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

  Purpose4/5

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

  The description 'List assets, paginated' clearly indicates a read-only listing operation on 'assets' with pagination. However, it does not specify whether these are all assets or a filtered subset, and it does not distinguish itself from similar sibling tools like lyzr_list_user_assets or lyzr_search_user_assets.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives. The description gives no context about preferred use cases, exclusions, or relationships to other listing/search tools, 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.

• lyzr_ops_generate_reportC
  2.9/5.0
  Behavior2/5

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

  Annotations are minimal (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false). The description adds no context about side effects, performance, required permissions, or expected behavior. It simply states the action, leaving the agent to infer everything else.

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

  Conciseness4/5

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

  The description is a single concise sentence with no unnecessary words. It is appropriately sized for a simple tool, though it could be expanded with usage context without becoming verbose.

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

  Completeness2/5

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

  The tool has only 2 parameters and no output schema, but the description is too minimal to be complete. It does not explain what an operations report contains, how the result is returned, or any caveats. With many sibling report tools, more differentiation and context are 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.

  Parameters3/5

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

  The input schema has 100% description coverage for both parameters, clearly defining start_date and end_date with YYYY-MM-DD format. The description mentions 'date range' which aligns with the schema, but adds no additional meaning beyond what the schema already provides.

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

  Purpose4/5

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

  The description clearly states a specific action ('Generate an operations report') with a date range scope. It is distinguishable from many siblings by the 'ops' prefix, but does not explicitly differentiate from other report tools like lyzr_report_usage_by_* or lyzr_ops_export_report_csv.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical scenarios, or any exclusions. The sibling list contains many report-related tools, but no comparison or selection criteria is given.

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

• lyzr_parse_txtC
  2.9/5.0
  Behavior2/5

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

  The description adds only the output detail of 'text chunks' beyond the annotations (readOnlyHint false, destructiveHint false). It does not disclose potential side effects, whether content is persisted, size limits, or return structure. Since there is no output schema, the burden on the description is higher, and this minimal statement is insufficient for full behavioral transparency.

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

  Conciseness5/5

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

  The description is a single, focused sentence with no redundant words. It front-loads the purpose and is appropriately sized for the tool's core function, despite lacking additional context.

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

  Completeness2/5

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

  Given the tool has 10 parameters (including optional S3 and chunking options) and no output schema, the description is too brief to be complete. It does not explain how the input should be provided (base64 vs. S3), what the chunking defaults are, or what the return value looks like. While the schema covers parameters, the overall context for the tool is underdeveloped.

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

  Parameters3/5

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

  The input schema has 100% coverage with descriptions for all 10 parameters, so the description does not need to add parameter-level detail. The description adds no extra meaning beyond the schema; it merely states the high-level operation. The baseline of 3 is appropriate because the schema already handles parameter semantics comprehensively.

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

  Purpose4/5

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

  The description 'Parse a plain-text file into text chunks' clearly states the tool's verb ('parse'), resource ('plain-text file'), and outcome ('text chunks'). It is specific and unambiguous, but it does not explicitly differentiate itself from sibling tools like lyzr_parse_text or lyzr_parse_pdf, which have similar 'parse' actions.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool instead of alternatives. It does not mention prerequisites (e.g., base64 encoding, S3 source), exclusions, or scenarios where other parsers would be more appropriate. With sibling tools like lyzr_parse_text, lyzr_parse_pdf, and lyzr_parse_docx, this lack of differentiation is a clear gap.

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

• lyzr_publish_agentsC
  2.9/5.0
  Behavior2/5

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

  Annotations already indicate this is a non-read-only, non-idempotent, non-destructive operation, so the description should clarify side effects and context. It merely restates the action and access level without explaining what publishing means, reversibility, or external visibility.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence with no filler. It communicates the core operation and scope efficiently.

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

  Completeness2/5

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

  With no output schema and sparse annotations, the description must carry more explanatory weight. It fails to describe publishing semantics, valid access levels, return values, permission requirements, or failure behavior, making it incomplete for a mutation tool.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description adds no parameter details beyond the schema, such as allowed access_level values or how agent_ids are sourced, but the schema already documents both parameters adequately.

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

  Purpose4/5

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

  The description clearly states the action ('Publish') and resource ('agents'), and includes useful scoping ('one or more', 'given access level'). It does not explicitly distinguish from sibling tools, though no direct 'publish agent' sibling appears in the list.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives, prerequisites, or exclusions. The only usage signal is the implied 'when you want to publish agents', which is redundant with the title.

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

• lyzr_session_createC
  2.9/5.0
  Behavior2/5

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

  The description merely repeats the 'create' action which is already implied by the readOnlyHint=false annotation. It adds no additional behavioral context such as required user association, session binding to agents, or side effects. With annotations present but minimal, the description fails to add any value beyond them.

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

  Conciseness4/5

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

  The description is one sentence with zero redundant words, making it very concise. However, it is so minimal that it lacks context, though this dimension specifically rewards lack of waste, so a high score is justified.

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

  Completeness2/5

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

  Given the large sibling tool set with multiple session creation tools, the description is far from complete. It does not explain what a session is, how this differs from other session tools, what the return value looks like (no output schema), or any important behavioral context. The description alone is insufficient for an agent to confidently select and invoke the tool.

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

  Parameters3/5

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

  The input schema has 100% coverage of parameter descriptions, so the schema carries the burden of documenting each parameter. The description 'Create a new session' adds no extra meaning to the parameters, netting a baseline score of 3.

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

  Purpose4/5

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

  The description clearly states the action (create) and the resource (session) in 'Create a new session.' It is specific enough for basic understanding, but it does not differentiate this from sibling tools like lyzr_session_create_for_agent or lyzr_session3_create, which also create sessions.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives. The description lacks any mention of prerequisites, when to choose this over other session-creation tools, or any exclusions.

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

• lyzr_session_updateC
  2.9/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=true, so the safety profile is covered. However, the description adds no extra behavioral details beyond what the name implies, such as whether the update is partial or full, merge semantics, or error behavior. It provides no value beyond the annotations.

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

  Conciseness4/5

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

  The description is a single, front-loaded sentence with no fluff. It conveys the primary purpose efficiently, but given the complexity of the schema (nested objects), it could benefit from a bit more context without becoming verbose. Still, it earns a 4 for its concise structure.

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

  Completeness2/5

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

  There is no output schema, so the description should communicate return behavior, but it does not. It also fails to clarify which session variant this targets compared to session3 tools, and doesn't mention prerequisites or side effects. With 5 params and nested objects, the description is insufficient for an agent to fully understand the tool's operational context.

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

  Parameters3/5

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

  Schema description coverage is 100% with meaningful descriptions for all 5 parameters (e.g., 'Owner of the session', 'Additional Session fields to merge into the body'). The description does not add any parameter semantics beyond the schema, so it sits at the baseline of 3.

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

  Purpose4/5

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

  The description states the core action clearly: 'Update an existing session by id.' It identifies the verb (update), resource (session), and scope (by id), distinguishing it from create/get/delete. However, it doesn't differentiate from the sibling tool lyzr_session3_update, and 'session' is not qualified, which keeps it from a 5.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool vs alternatives like session_create, session3_update, or session_delete. No context is provided for choosing this over similar tools, so the agent gets no explicit usage direction.

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

• lyzr_sharing_update_groupC
  2.9/5.0
  Behavior2/5

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

  The description adds minimal behavioral context beyond the annotations. It does not disclose that 'shared_with' is a replacement list, which could remove existing users, nor does it describe any side effects or permissions required. Given openWorldHint is true and destructiveHint is false, the description offers no clarification on impact, leaving the agent uninformed about potentially destructive behavior.

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

  Conciseness5/5

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

  The description is a single, concise sentence that front-loads the verb and resource, with no wasted words. It is appropriately sized for a straightforward update action, though it omits details that could be included.

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

  Completeness2/5

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

  The tool has 4 parameters, one required, and a nested array, but no output schema. The one-sentence description does not explain the replacement semantics of 'shared_with' or what the update returns. Given the complexity and lack of output schema, the description is too sparse to be considered complete.

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

  Parameters3/5

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

  The schema covers 100% of parameters with descriptions, so the baseline is 3. The description's mention of 'access levels or shared users' vaguely summarizes the parameters but adds no additional meaning beyond what the schema already provides. It does not clarify the relationship between access_level, org_access_level, and shared_with, but the schema descriptions are sufficient.

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

  Purpose4/5

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

  The description clearly states the action ('Update') and the resource ('a sharing group'), and specifies the scope ('access levels or shared users'). However, it does not explicitly distinguish from the sibling 'sharing_share_group' tool, which could cause ambiguity. Overall, the purpose is clear for the 'Update' verb in the sharing family.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like create, delete, or share group. It does not mention prerequisites, such as needing an existing group_id, or when to use it to modify access levels versus using a dedicated share function. This lack of usage context makes it hard for an agent to choose this tool appropriately.

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

• lyzr_update_feature_flagC
  2.9/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false, establishing the mutation and safety profile. The description adds minimal context (that it targets an existing flag), but doesn't disclose partial-update semantics, null-field behavior, or failure modes. No contradiction with annotations.

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

  Conciseness4/5

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

  The description is a single front-loaded sentence with zero filler: 'Update an existing feature flag's fields.' It is structurally efficient and every word contributes meaning, though additional sentences could have enriched it without bloat.

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

  Completeness2/5

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

  For a 7-parameter update tool with nullable enablement settings and no output schema, the description is underspecified. It omits return values, null-clearing semantics, prerequisites (the key must exist), and how enabled_for_envs/plans/roles combine. The schema and annotations carry most of the burden, and the description leaves important gaps.

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

  Parameters2/5

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

  Schema description coverage is 71% (covers key, description, and the enabled_for_* fields), but is_visible and is_accessible are undocumented in the schema, and the tool description adds nothing about parameters. It doesn't clarify what the booleans control, how null values behave, or how the enabled_for_* lists interact, so it fails to compensate for the mid-range coverage gap.

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

  Purpose4/5

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

  The description 'Update an existing feature flag's fields' clearly states the action (update), the resource (feature flag), and scope (existing resource's fields), distinguishing it from sibling tools like create/delete/get feature flag. It is specific enough to identify the operation, though it doesn't enumerate which fields or add detail beyond the title.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives like create_feature_flag, get_feature_flag_admin, or delete_feature_flag. The word 'existing' weakly implies the flag must already exist, but there is no explicit context, prerequisites, or when-not-to-use information.

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

• lyzr_credential_listB
  3/5.0
  Behavior2/5

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

  The annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is clear. The description adds no behavioral context such as pagination, result format, or authentication requirements, offering no value beyond the annotations.

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

  Conciseness4/5

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

  The description is a single, front-loaded sentence with no fluff. It is appropriately sized for a zero-parameter tool, though it is minimal and could be slightly more descriptive while still remaining concise.

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

  Completeness2/5

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

  Given the large number of sibling credential-list tools and the absence of an output schema, the description is incomplete. It does not specify the credential scope, type, or filtering, making it difficult for an agent to determine if this is the right tool for a given task.

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

  Parameters4/5

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

  The tool has zero parameters and the schema is empty, so the baseline of 4 applies. The description does not need to explain parameters, and it adds no additional semantic information that could be relevant.

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

  Purpose4/5

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

  The description clearly states the action (list) and resource (credentials), matching the tool name and title. However, it does not specify the scope (which credentials, user's or org-wide) nor distinguish it from sibling tools like lyzr_livesource_list_credentials or lyzr_list_provider_credentials_by_type.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternative credential-listing tools. There are no scenarios, exclusions, or mentions of alternatives, leaving the agent without context for tool selection.

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

• lyzr_get_multiple_context_values_internalB
  3/5.0
  Behavior1/5

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

  The description says 'fetch,' implying a read-only operation, but annotations set readOnlyHint to false, indicating the tool may not be read-only. This is a direct contradiction. Additionally, no side effects or internal behaviors are disclosed beyond what annotations already imply.

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

  Conciseness5/5

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

  The description is a single concise sentence that includes the key elements: internal endpoint, action, resource, and mechanism. There is no filler or redundancy.

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

  Completeness2/5

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

  With no output schema, the description should explain the return format (e.g., a map of context names to values), but it does not. It also lacks information about how multiple values are returned, error behavior, or how it differs from the singular sibling, leaving an agent underinformed.

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

  Parameters3/5

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

  Schema coverage is 100%, with both parameters (api_key and context_names) already described in the input schema. The description's mention of 'internal api_key' adds no new meaning beyond the schema.

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

  Purpose5/5

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

  The description clearly states the action (fetch), the resource (multiple context values), and the method (by name using an internal api_key). It also distinguishes from the singular sibling tool lyzr_get_context_value_internal by explicitly indicating 'multiple'.

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

  Usage Guidelines2/5

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

  The description notes this is an 'Internal endpoint,' which provides some audience context, but it does not specify when to use this tool versus alternatives like lyzr_get_context_value_internal or lyzr_get_context_by_name_internal. No exclusions or decision criteria are given.

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

• lyzr_kb_sync_sharepoint_oauth_callbackB
  3/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is somewhat covered. However, the description adds no behavioral context such as side effects, prerequisites, or the OAuth flow. It doesn't explain what 'handling the callback' does, whether it stores tokens, or why it is deprecated, leaving an opaque behavior despite the annotations.

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

  Conciseness4/5

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

  The description is a single concise sentence and front-loads the deprecation notice. It is appropriately short for a deprecated stub, though it could have used one more clause to mention that this is an OAuth redirect endpoint, but as written it is efficient and not padded.

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

  Completeness2/5

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

  Despite having no parameters and no output schema, the tool participates in a multi-step OAuth flow with sibling tools for authorization and exchange. The description fails to explain when this callback is triggered, how it relates to the other OAuth tools, or what the agent should do with it. The deprecation notice alone is insufficient.

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

  Parameters4/5

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

  The tool has zero parameters and the schema is empty, so there is nothing for the description to clarify. Per the baseline for no parameters, the description doesn't need to add parameter semantics, and the missing detail about callback query parameters is already impossible in this schema.

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

  Purpose4/5

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

  The description clearly identifies the tool as handling the SharePoint OAuth callback, and the title adds 'Deprecated'. It distinguishes from sibling tools like lyzr_kb_sync_sharepoint_oauth_authorize and lyzr_kb_sync_sharepoint_oauth_exchange by naming the callback step, though 'Handle' is a generic verb that doesn't explain what handling entails.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives. The '[deprecated]' marker implies it should not be used, but no alternative is named, and the description does not explain that this is likely invoked by the OAuth provider rather than directly by an agent. Sibling tools exist for authorization and token exchange, but the relationship is not communicated.

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

• lyzr_memory_listB
  3/5.0
  Behavior3/5

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

  Annotations already provide readOnlyHint, openWorldHint, and idempotentHint, so the description need not restate those. It adds a little context by referencing 'given identifiers' as filters, but does not disclose behavior such as default scope when no identifiers are provided, pagination semantics, or return format. With annotations covering the safety profile, this is adequate but not rich.

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

  Conciseness5/5

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

  The description is a single sentence with no filler or redundant information. It is concise and front-loaded, stating the core action and object clearly.

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

  Completeness2/5

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

  For a tool with 6 optional parameters and no output schema, the description is too sparse. It does not explain the filtering behavior across identifiers, pagination defaults, or what a successful response looks like. This leaves an agent under-informed about how to invoke the tool effectively.

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

  Parameters2/5

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

  Schema coverage is 50% (agent_id, owner_id, session_id have descriptions; limit, offset, cross_session do not). The description mentions 'identifiers' but does not explain which parameters are identifiers or how filtering works, nor does it compensate for the undocumented pagination and cross_session parameters. Parameter semantics remain ambiguous beyond what the schema already says.

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

  Purpose4/5

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

  The description clearly states the tool 'List stored memories for the given identifiers.' It uses a specific verb (list), names the resource (stored memories), and mentions scoping by identifiers. It is distinct from 'get' or 'search' siblings, though it does not explicitly differentiate itself from lyzr_memory_search or clarify what 'identifiers' encompasses.

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

  Usage Guidelines2/5

  Does 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 lyzr_memory_get or lyzr_memory_search. It does not mention that all parameters are optional filters, nor what happens when no identifiers are provided. No exclusions or alternative recommendations are given.

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

• lyzr_update_toolB
  3/5.0
  Behavior2/5

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

  The description adds no behavioral detail beyond what annotations already provide. It does not clarify whether the update is partial (merge) or full replacement, what happens to unspecified fields, or any side effects. Since annotations cover the safety profile (readOnlyHint=false, destructiveHint=false), the minimal description fails to add meaningful context.

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

  Conciseness3/5

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

  The description is a single, short sentence—concise but almost redundant with the tool name ('Update Tool'). It lacks informative content that would justify its existence, but it is not bloated or poorly structured.

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

  Completeness2/5

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

  Given the large number of sibling tools and the free-form 'update' object (additionalProperties empty), the description is too sparse. It does not explain the update semantics (e.g., partial vs full replacement), what fields are valid, or how errors are handled. With no output schema, more detail is needed for reliable usage.

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

  Parameters3/5

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

  The schema already describes both parameters perfectly: 'tool_id' as the identifier and 'update' as the fields to update, with 100% coverage. The description adds no further semantic detail, so it neither helps nor hurts—baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the function: 'Update fields on an existing tool by id.' It uses a specific verb ('Update'), identifies the resource ('tool'), and specifies the identifier ('by id'), effectively distinguishing it from other update tools for different entities like agents or workflows.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives (e.g., lyzr_update_agent, lyzr_update_workflow), nor any mention of prerequisites or conditions. The description only states what the tool does, not when to choose it.

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

• lyzr_agent_sessionsB
  3.1/5.0
  Behavior2/5

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

  The description adds no behavioral traits beyond what the annotations already provide (readOnlyHint, openWorldHint, idempotentHint). It does not mention pagination, sorting, return format, or any session-specific caveats, so it fails to add value beyond the structured hints.

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

  Conciseness4/5

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

  The description is a single concise sentence that clearly states the action and target. It is appropriately sized, though slightly under-specified regarding selection context, which prevents a perfect score.

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

  Completeness4/5

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

  The tool is simple with one parameter and strong annotations. The description is enough to invoke it correctly, but the lack of guidance on which session type or alternatives to use is a minor gap, given the many sibling tools.

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

  Parameters3/5

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

  The single parameter agent_id is fully covered by the schema with a description ('Agent id'), and the description's 'for an agent' adds minimal extra context. This meets the baseline for good schema coverage; no further semantics are needed.

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

  Purpose4/5

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

  The description uses a specific verb (List) and resource (sessions for an agent), making its purpose clear. However, it does not distinguish among the many sibling session listing tools such as lyzr_session3_list or lyzr_session_history_by_agent, so it misses the differentiation needed for a 5.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives. With numerous session-related sibling tools, the description should specify exclusions or conditions, but it provides none.

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

• lyzr_classifyB
  3.1/5.0
  Behavior2/5

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

  Description only says it returns labels but does not disclose behavior on edge cases like no matches, multiple matches, or malformed rules. Annotations are minimal and do not add clarity.

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

  Conciseness4/5

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

  A single, tightly worded sentence with no filler. However, it may be too sparse, missing important context that would make it more useful.

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

  Completeness2/5

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

  No output schema, so the description should clarify the exact return format (e.g., array of strings vs. single string). The phrase 'matching label(s)' is ambiguous about multiple matches and error behavior.

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

  Parameters3/5

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

  Schema description coverage is 100% for all parameters, so the description adds little beyond what the schema already provides. It does not introduce new parameter semantics.

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

  Purpose5/5

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

  Clearly states it classifies text against a set of rules and returns matching labels. This distinguishes it from sibling tools, none of which perform classification.

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

  Usage Guidelines2/5

  Does 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 (e.g., LLM-based classification or other extraction tools). Lacks any context or exclusions.

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

• lyzr_create_moduleB
  3.1/5.0
  Behavior2/5

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

  The description merely restates the action ('Create a new sidebar module') without adding behavioral context beyond the annotations. It does not disclose side effects, required permissions, return value, or consequences of creation. Since annotations already indicate non-read-only and non-destructive, the description contributes nothing extra.

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

  Conciseness4/5

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

  The description is a single short sentence with no unnecessary words or repetition. It is concise and front-loaded, clearly stating the action and object. However, given the tool's complexity (25 parameters), a bit more actionable detail would be beneficial without compromising conciseness.

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

  Completeness2/5

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

  For a creation tool with 25 parameters and no output schema, the description is too minimal. It does not explain what a sidebar module is, what happens after creation (e.g., visibility, persistence), error conditions, or typical return values. The rich schema is helpful, but the description fails to tie the operation into the broader module management context (e.g., relationships with update/get/delete module tools).

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

  Parameters3/5

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

  All 25 parameters have schema descriptions with 100% coverage, so the schema carries the parameter semantics. The tool description itself adds no parameter information. Baseline is 3 because the schema fully documents parameters; the description neither enhances nor harms the understanding of parameters.

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

  Purpose5/5

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

  The description uses a specific verb ('Create') and identifies the resource ('new sidebar module'). This clearly distinguishes it from sibling tools like lyzr_update_module and lyzr_delete_module, and from other create tools like lyzr_create_agent or lyzr_create_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/5

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

  The description provides no guidance on when to use this tool versus alternatives. It does not mention related tools like lyzr_update_module or lyzr_list_modules_admin, nor any prerequisites or intended workflow. The only implied context is that it is for creating modules, but no explicit usage criteria are given.

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

• lyzr_extractB
  3.1/5.0
  Behavior2/5

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

  Annotations indicate readOnlyHint=false and destructiveHint=false, but the description adds no additional behavioral context such as potential side effects, rate limits, or resource requirements. It does not clarify what happens if multiple input sources are supplied or whether extraction is deterministic. Minimal value beyond the annotations.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that states the tool's purpose and primary input options in under 20 words. No filler, no repetition of schema details, and no unnecessary context.

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

  Completeness3/5

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

  For a tool with 13 parameters and no output schema, the description provides only a high-level overview. It clarifies the required extraction_schema and input alternatives, but does not mention what the return value looks like, how to structure the extraction schema, or the meaning of advanced options. It is minimally sufficient for basic use but leaves significant gaps for complex scenarios.

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

  Parameters3/5

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

  Schema description coverage is 100%, so all 13 parameters are individually documented. The description adds marginal value by summarizing the three input modes (file_content_base64, file_url, full_text) but does not explain settings like tier, annotate, chunk_size, or parser_config beyond what the schema already states. Baseline 3 is appropriate.

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

  Purpose4/5

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

  The description uses a specific verb ('Extract') and names the resource ('structured data from a file, file URL, or raw text'), and it mentions the key input modes. It does not explicitly distinguish from sibling parse tools like lyzr_parse_pdf or lyzr_parse_text, though the 'according to an extraction schema' clause hints at a different use case.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to choose this tool over alternatives such as lyzr_parse_text or lyzr_parse_pdf. It does not state exclusions, prerequisites, or typical use cases beyond the basic extraction action, leaving the agent to infer when this specific tool is appropriate.

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

• lyzr_get_contexts_countB
  3.1/5.0
  Behavior2/5

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

  The description adds no behavioral context beyond the annotations. Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description merely restates the action; it doesn't mention the response format (e.g., integer) or scope of the count, so transparency is minimal.

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

  Conciseness4/5

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

  The description is a single sentence of six words, making it highly concise and front-loaded. However, it's terse and close to a tautology of the title, providing little added value beyond the name.

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

  Completeness3/5

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

  For a zero-parameter read-only tool, the description is functionally complete: it states what it returns (total count). But it doesn't define the scope of 'contexts' or what the count represents, and there's no mention of output type. Given the simple nature, it's minimally sufficient but could be improved.

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

  Parameters4/5

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

  There are no parameters, and the schema covers 100% of them (i.e., none). With zero parameters, the baseline is 4; the description doesn't need to add parameter information. It correctly doesn't mention non-existent inputs.

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

  Purpose4/5

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

  The description clearly states the tool returns the total count of contexts, using a specific verb ('get') and resource ('contexts'). However, it doesn't differentiate from sibling context tools (e.g., lyzr_get_context_usage) or explain what 'contexts' refers to, so it's clear but not distinctive.

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

  Usage Guidelines2/5

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

  No usage guidance is provided. The description doesn't say when to use this instead of lyzr_list_contexts, lyzr_get_context, or lyzr_get_context_usage, nor does it mention any prerequisites. The agent is left to infer that 'count' is different from listing.

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

• lyzr_get_providerB
  3.1/5.0
  Behavior2/5

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

  Annotations (readOnlyHint=true, openWorldHint=true, idempotentHint=true) already declare safety and idempotency. The description adds no additional behavioral context such as return format, error behavior, or implications of fetching a provider. It simply restates the schema-level operation, providing no value beyond the annotations.

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

  Conciseness5/5

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

  A single, concise sentence that is perfectly sized for this trivial operation. No fluff, unnecessary qualifications, or repetition. It earns its place with immediate clarity.

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

  Completeness3/5

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

  For a low-complexity get-by-id tool with strong annotations and full schema coverage, the description is minimally adequate. However, it lacks any hint about what a 'provider' is, what the response contains, or potential error conditions (e.g., non-existent id). No output schema exists, so a brief note on return shape would have improved completeness.

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

  Parameters3/5

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

  The input schema has 100% coverage with a clear description for provider_id ('The provider id to fetch'). The description's 'by id' adds no new meaning beyond what the schema already states, so the baseline of 3 applies.

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

  Purpose4/5

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

  The description 'Fetch a provider by id' clearly states the verb (fetch), the resource (provider), and the identifier parameter (id). It distinguishes itself from sibling tools like lyzr_get_providers_by_type (by type) and lyzr_get_provider_credential (credentials), though it does not explicitly name these alternatives.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus the many related tools (e.g., lyzr_get_providers_by_type, lyzr_list_provider_credentials_by_user, lyzr_get_provider_credential). The description offers no exclusions, prerequisites, or contextual decision-making help.

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

• lyzr_git_create_prB
  3.1/5.0
  Behavior2/5

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

  The description only restates the obvious write operation ('Create'), which is already implied by readOnlyHint=false. It adds no behavioral context about side effects, failure conditions, permissions, or what happens on conflict. With annotations already declaring non-idempotence and not read-only, the description contributes little beyond the structured metadata.

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

  Conciseness4/5

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

  The description is a single, clean sentence with a front-loaded verb and no fluff. It is appropriately brief for a simple create operation, though its brevity limits the amount of useful context it could provide.

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

  Completeness2/5

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

  Given the tool has 6 parameters, no output schema, and sparse annotations, the description is under-specified. It does not mention prerequisites (e.g., git repo must be connected), what the function returns (PR URL or ID), or how failures are surfaced. For a mutation tool, this level of detail is insufficient.

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

  Parameters3/5

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

  Schema coverage is 100% with descriptive parameter names and brief descriptions, so the baseline is 3. The description adds a slight context that agent_id identifies the agent's repo, but it does not clarify branch name conventions, reviewer behavior, or the relationship between title and description beyond what the schema already provides.

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

  Purpose5/5

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

  The description clearly states the action (create), the resource (pull request), and the scope (between two branches of an agent's repo). This distinguishes it from sibling tools like lyzr_git_list_prs, lyzr_git_merge_branches, and lyzr_git_create_branch, making the purpose unambiguous.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives such as lyzr_git_merge_branches or lyzr_git_update_reviewers. It also omits prerequisites like needing an initialized repo or existing branches, leaving the agent without contextual decision support.

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

• lyzr_infer_a2a_agentB
  3.1/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint=false and openWorldHint=true, but the description adds no additional behavioral context. It does not disclose side effects (e.g., the agent might trigger actions), authentication needs, or rate limits. It is not contradictory, but it is essentially a restatement of the basic action.

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

  Conciseness5/5

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

  The description is a single, efficient sentence with no filler. It is front-loaded with the key action and resource.

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

  Completeness3/5

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

  For a simple send-and-respond tool, the description is minimally adequate. It does not explain return format or behavior in error cases, and there is no output schema to supplement this. The tool is not complex, but more context could help given the large sibling set and absence of output schema.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents agent_id, message, and context_id. The description adds nothing beyond the schema, but the baseline of 3 applies since the schema carries the heavy lifting.

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

  Purpose4/5

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

  The description uses a specific verb+resource structure: 'Send a message to a registered A2A agent and get its response.' This clearly states the action and target. It does not explicitly distinguish from sibling tools like lyzr_send_a2a_jsonrpc or lyzr_chat, but the 'registered A2A agent' qualifier provides reasonable differentiation.

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

  Usage Guidelines2/5

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

  The description gives no guidance on when to use this tool versus alternatives. It does not mention alternatives, exclusions, or prerequisites. With sibling tools like lyzr_send_a2a_jsonrpc and lyzr_chat, the lack of any usage context leaves the agent uncertain about selection.

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

• lyzr_kb_queryB
  3.1/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint as true, so the agent knows this is a safe read operation. However, the description adds no additional behavioral context such as pagination, result ordering, default values for top_k, or whether rag_id must reference a specific resource type. With no output schema, the description also does not clarify the exact structure of the returned chunks, leaving a transparency gap beyond what annotations provide.

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

  Conciseness5/5

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

  The description is a single, clear sentence: 'Retrieve relevant chunks from a knowledge base.' It is front-loaded with the action and resource, contains no filler words, and is appropriately sized for a simple read-only tool. It gives just enough information without unnecessary elaboration, making it efficient and easy to parse.

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

  Completeness3/5

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

  Given the tool's low complexity (3 simple parameters, no nested objects) and strong annotations (readOnly, idempotent, openWorld), the description is minimally adequate. However, without an output schema, the description should hint at what the response contains. 'Relevant chunks' is a vague return description and does not clarify whether the response includes scores, metadata, or just text. It also lacks any context about how this relates to other KB tools, making it less complete for selection purposes.

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

  Parameters3/5

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

  Schema description coverage is 100%, so all three parameters (query, top_k, rag_id) have meaningful descriptions in the schema. The tool description itself adds no additional parameter semantics, but since the schema already documents each parameter clearly, the baseline of 3 is appropriate. The parameter descriptions are concise and self-explanatory, so no further clarification is needed.

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

  Purpose4/5

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

  The description uses a specific verb ('Retrieve') and resource ('relevant chunks from a knowledge base'), clearly indicating a retrieval/search operation. It is distinct from sibling KB tools like create, list, or get, though it does not explicitly name alternatives. The name 'lyzr_kb_query' plus 'relevant chunks' suggests semantic search rather than simple metadata fetching, giving it enough clarity without being fully 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/5

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

  The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or mention any sibling tools like lyzr_kb_list, lyzr_kb_get, or lyzr_rag_get_doc_content. The only signal is the verb 'retrieve' implying search, but there is no explicit usage context or selection criteria.

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

• lyzr_list_resource_audit_logsB
  3.1/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds no behavioral context beyond what the schema and annotations provide, such as pagination behavior, ordering, or what fields are returned. It does not contradict the annotations, but it fails to disclose any additional behavioral 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/5

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

  The description is a single sentence that is front-loaded with the core action and scope. It contains no unnecessary words and communicates the essential information efficiently.

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

  Completeness3/5

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

  The tool is relatively straightforward and the schema is comprehensive, but the description does not mention response format or ordering, and the lack of output schema means the agent has no idea what will be returned. With the large sibling toolset, more guidance on when to use this vs. other audit log tools would improve completeness.

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

  Parameters3/5

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

  Schema coverage is 100%, so each parameter already has a description. The description only adds the generic phrase 'with optional filters', which does not deepen understanding of the parameters. Therefore, baseline score of 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states the tool retrieves audit logs for a specific resource type and ID, distinguishing it from sibling audit log tools that operate at org, user, or session scope. The verb 'Get' is slightly less precise than 'List', but the resource type and ID qualifier provides adequate differentiation from 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/5

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

  No guidance is given on when to use this tool versus alternatives. There is no mention of when to choose this over lyzr_list_org_audit_logs, lyzr_list_my_audit_logs, or lyzr_list_session_audit_logs. The description simply states what it does without context for selection.

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

• lyzr_memprovider_supermemory_statusB
  3.1/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description does not need to restate those. However, it adds no additional behavioral context beyond what annotations provide; it does not clarify what 'status' means, whether the credential must already exist, or what errors may occur. The description is a bare restatement of the tool's function.

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

  Conciseness5/5

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

  The description is a single clear sentence that is front-loaded and contains no unnecessary words. It efficiently communicates the tool's purpose without redundancy, making it ideal for quick parsing.

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

  Completeness3/5

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

  This is a very simple tool with one parameter and no output schema. The description and schema together are minimally sufficient for a basic status check, but the description does not explain what the returned status looks like or any edge cases (e.g., credential not found). It is adequate but leaves some gaps.

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

  Parameters3/5

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

  The input schema covers the single parameter with a description: 'The Supermemory credential id.' Since schema description coverage is 100%, the baseline is 3. The tool description adds no further semantic detail about how the credential ID is used or formatted, so a middle score is appropriate.

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

  Purpose4/5

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

  The description uses a specific verb and resource: 'Get the status of a Supermemory memory provider credential.' It clearly identifies the tool's action and object. However, it does not explicitly distinguish itself from sibling status tools like lyzr_memprovider_validate_supermemory or lyzr_memprovider_mem0_status, though the 'Supermemory' qualifier helps narrow the scope.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or recommend this over sibling tools like lyzr_memprovider_validate_supermemory. Usage context is only implied by the tool name and description, which is not sufficient for effective decision-making.

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

• lyzr_refresh_tool_credential_statusB
  3.1/5.0
  Behavior2/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false, so safety is covered. The description adds little beyond the title; it does not mention whether the refresh triggers an external network call, modifies stored status, or requires specific 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/5

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

  The description is a single, front-loaded sentence without any filler or redundant content. It efficiently conveys the core action and resource in minimal space.

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

  Completeness3/5

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

  Given the tool's low complexity, one required parameter, and helpful annotations, the description is minimally viable. However, it omits any detail about return values or behavioral side effects, which would be especially useful since no output schema is provided.

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

  Parameters3/5

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

  Schema coverage is 100% with a single documented credential_id parameter, so the schema carries the full semantic weight. The description adds no additional parameter-level meaning beyond what the schema already provides.

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

  Purpose4/5

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

  The description uses a specific verb ('Refresh/recheck') and identifies the resource ('status of a tool credential'), clearly conveying the action. However, it does not explicitly differentiate this from similar sibling tools like lyzr_test_tool_credential or lyzr_credential_get.

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

  Usage Guidelines2/5

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

  No guidance is provided regarding when to use this tool versus alternatives, nor any prerequisites or contextual triggers. The description simply states what the tool does, leaving the agent to infer usage entirely.

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

• lyzr_resolve_asset_by_sourceB
  3.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the agent knows this is a safe, idempotent read operation. The description adds the resolution behavior but does not disclose return format, error conditions, or whether it accesses local storage, adding minimal context beyond what annotations provide.

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

  Conciseness4/5

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

  The description is a single, front-loaded sentence with no redundant or filler content. It is easy to parse and appropriately sized for a tool of this simplicity, though it is terse.

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

  Completeness2/5

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

  For a simple read-only tool with full schema coverage and safety annotations, this is minimally adequate, but it leaves key gaps: what 'resolve' returns (e.g., asset ID versus asset metadata), and when to use it over sibling asset lookup tools. Without output schema or more descriptive context, the agent may not know the expected result or invocation context.

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

  Parameters3/5

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

  Both parameters have descriptions in the schema, giving 100% schema coverage. The description does not add further meaning beyond the schema, so it appropriately relies on the schema for parameter semantics.

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

  Purpose4/5

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

  The description uses a specific verb and resource: 'resolve an asset' from a knowledge base document's source path, indicating a lookup operation. It is clear enough, though 'resolve' is somewhat domain-specific and it doesn't explicitly differentiate from sibling asset tools like get_asset or search_user_assets.

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

  Usage Guidelines2/5

  Does 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 such as get_asset or search_user_assets. It does not mention prerequisite conditions, such as the need for a valid rag_id or a properly formatted source path, or what to do if the asset is not found.

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

• lyzr_resolve_llm_credentialB
  3.1/5.0
  Behavior2/5

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

  The description is minimal and relies heavily on the readOnlyHint and idempotentHint annotations. It does not disclose behavioral details such as what 'resolve' returns (e.g., plaintext secret), potential errors, or any side effects beyond what the annotations already imply.

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

  Conciseness5/5

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

  The description is a single, concise sentence that directly states the tool's function without any unnecessary words or fluff. It is appropriately front-loaded and efficient.

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

  Completeness3/5

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

  The tool is simple, and the schema plus annotations cover most needs. However, with no output schema, the description could have explained what the resolved credential looks like or clarified the distinction between the two parameters, which it does not.

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

  Parameters3/5

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

  Schema description coverage is 100%, with both provider_id and credential_id already well-described. The description adds no additional semantic meaning beyond referencing 'by credential or provider id,' which is already captured in the schema.

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

  Purpose4/5

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

  The description clearly states the tool resolves an LLM credential by credential or provider id, using a specific verb and resource. However, it does not explicitly distinguish this from similar credential-related sibling tools like lyzr_credential_get or lyzr_get_provider_credential.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. With many credential-related sibling tools available, there is no indication of what makes resolve_llm_credential the right choice or any exclusions.

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

• lyzr_schedule_triggerB
  3.1/5.0
  Behavior2/5

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

  Annotations already indicate this is a non-read-only, non-idempotent operation with potential external effects (openWorldHint=true). The description adds only the 'out of band' context, which suggests a manual trigger but does not explain what executing the schedule entails (e.g., whether it runs associated tasks, any side effects on subsequent scheduled runs, or required schedule state).

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence with no redundant words. It earns its place by stating the core action clearly, making it highly concise and well-structured.

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

  Completeness2/5

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

  With only one parameter and no output schema, the tool is relatively simple, but the description omits crucial context such as what happens when a schedule is triggered, whether it requires an existing schedule, or what the return value indicates. This is incomplete for a triggering operation, especially given the absence of an output schema.

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

  Parameters1/5

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

  The input schema has a single required parameter, schedule_id, with no description. Schema description coverage is 0%, and the description does not mention this parameter or its purpose. The agent must rely solely on the parameter name, which is underspecified.

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

  Purpose5/5

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

  The description uses a specific verb 'Run' with resource 'a schedule', and the parenthetical '(out of band)' clarifies it executes immediately rather than through normal scheduling. This clearly distinguishes it from sibling tools like lyzr_schedule_create, lyzr_schedule_pause, and lyzr_schedule_resume.

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

  Usage Guidelines3/5

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

  The description implies the use case (trigger a schedule right now) but does not mention when to use it relative to alternatives such as lyzr_schedule_pause or lyzr_schedule_resume. No prerequisites or conditions are stated, leaving the agent to infer from the tool name and context.

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

• lyzr_session_conversationB
  3.1/5.0
  Behavior3/5

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

  The annotations already declare readOnlyHint, idempotentHint, and openWorldHint, establishing the safe read-only nature of the operation. The description adds no additional behavioral details such as error handling or return format, but it does not contradict the annotations either. With the lower bar set by annotations, this is adequate 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/5

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

  The description is a single, concise sentence that front-loads the primary purpose without any filler. It is appropriately sized for a simple read tool, though it could have included contextual alternatives without becoming verbose.

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

  Completeness2/5

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

  While the tool is simple with one parameter and no output schema, the description fails to provide enough context to distinguish it from numerous sibling session tools. It neither clarifies the return format nor explains the difference between session, session3, and history tools, leaving the agent without full situational awareness.

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

  Parameters3/5

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

  The schema provides 100% coverage for the single parameter session_id with a clear description ('Session id'). The tool description does not add further parameter semantics, but given the high schema coverage, the parameter is well-documented and the baseline score of 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states the action ('Fetch') and the resource ('a session's conversation'), making the tool's purpose immediately apparent. However, it does not differentiate it from sibling tools like lyzr_session_get or lyzr_session_history, which could also be interpreted as fetching session 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/5

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

  There is no guidance on when to use this tool over alternatives. Given the extensive list of session-related sibling tools (lyzr_session_get, lyzr_session_history, lyzr_session_summary, etc.), the absence of usage context is a notable gap that could lead to incorrect tool selection.

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

• lyzr_set_agent_statusB
  3.1/5.0
  Behavior2/5

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

  Annotations already declare this as a non-read-only, idempotent, and non-destructive operation. The description adds no behavioral context beyond restating the core action, such as what 'deactivate' affects or any side effects. It doesn't contradict annotations, but it also doesn't supplement them.

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

  Conciseness5/5

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

  The description is a single, efficient sentence with no wasted words. It is front-loaded and immediately understandable, though it sacrifices depth for brevity.

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

  Completeness3/5

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

  For a simple two-parameter toggle, the description is adequate but lacks guidance on distinguishing from similar sibling tools (e.g., lyzr_set_agent_lock, lyzr_update_agent) or on expected response behavior (no output schema). With good annotations and full schema coverage, it reaches a minimally viable completeness.

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

  Parameters3/5

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

  Schema coverage is 100%, with both parameters described ('agent_id' and 'is_active'). The description adds minimal meaning by implying that setting is_active to true/false activates/deactivates, but this is already clear from the schema field description. It meets the baseline for well-covered params.

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

  Purpose4/5

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

  The description clearly states the tool's function with a specific verb ('Activate or deactivate') and resource ('an agent'), matching the title. It is distinguishable from siblings like lyzr_set_agent_lock and lyzr_update_agent by its action, though it doesn't explicitly contrast with them.

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

  Usage Guidelines2/5

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

  No guidance is provided about when to use this tool versus alternatives such as lyzr_update_agent or lyzr_set_agent_lock. The description only states what the tool does, leaving the agent to infer usage context from the name and sibling list.

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

• lyzr_world_model_list_scenariosB
  3.1/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint=true and idempotentHint=true, and the description does not contradict them. However, it adds no additional behavioral context beyond what annotations imply (e.g., return format, error behavior, or whether the world model must exist). The description is consistent but minimally informative.

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

  Conciseness5/5

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

  The description is a single, concise sentence that contains no extraneous words. It is appropriately front-loaded, stating the verb and resource directly.

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

  Completeness3/5

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

  The tool is simple (1 parameter, no output schema) and annotations are strong, but the description still lacks detail about return values, pagination, or ordering of scenarios. It is adequate but leaves clear gaps, especially since no output schema exists.

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

  Parameters3/5

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

  Schema description coverage is 100% and the parameter 'world_model_id' is documented as 'The world model id'. The tool description adds no further semantic meaning beyond the schema, so the baseline score of 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states the action ('List') and the resource ('scenarios defined on a world model'), making the purpose unambiguous. However, it does not explicitly differentiate from sibling list tools like lyzr_world_model_list_personas, though the resource type is specific enough.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool vs alternatives, no prerequisites, and no context. It is a bare statement of functionality with no usage context.

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

• lyzr_world_model_update_personaB
  3.1/5.0
  Behavior2/5

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

  The description adds no behavioral context beyond what annotations already state. It does not explain that updating will overwrite existing name/description values, the idempotent behavior, or any side effects. No contradiction with annotations, but no added value either.

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

  Conciseness5/5

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

  The description is a single concise sentence with no fluff. It is appropriately sized for a simple update operation and is immediately understandable.

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

  Completeness3/5

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

  Given the full schema coverage and annotations, the description is minimally viable but lacks context about return values, error conditions, or relationship to other world model operations. It does not mention what happens if the persona or world model does not exist.

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

  Parameters3/5

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

  The schema covers all four parameters with individual descriptions (100% coverage), so the description does not need to explain them. The description itself adds no extra meaning beyond the schema fields.

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

  Purpose4/5

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

  The description clearly states the action (update) and the target resource (a persona on a world model), which distinguishes it from sibling tools like add_personas or delete_persona. However, it does not list updatable fields or explicitly differentiate from alternatives, relying on the schema for those details.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternative persona tools (e.g., lyzr_world_model_add_personas, lyzr_world_model_delete_persona). There is no mention of prerequisites, use cases, or exclusions.

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

• lyzr_world_model_update_test_caseB
  3.1/5.0
  Behavior2/5

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

  Annotations already indicate this is a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false), but the description adds no additional behavioral context. It does not explain whether the update is partial or full replacement, what happens to unspecified fields, or whether the test case must already exist. The description essentially repeats the tool's title without depth.

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

  Conciseness4/5

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

  The description is a single, grammatical sentence that conveys the core action without filler. It is concise in length, though it under-specifies, but it is not as minimal as a tautology. It earns points for being efficiently structured.

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

  Completeness2/5

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

  For a tool with seven parameters and no output schema, the description does not provide enough contextual completeness. It omits critical information such as whether the update requires all fields (required fields suggest a full replacement), whether the test case must already exist, and what the response/return value is. The agent is left to infer too much.

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

  Parameters3/5

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

  Schema coverage is 100%, so all seven parameters have individual descriptions, which meets the baseline. The tool description itself adds no parameter-level meaning, but no compensation is needed given the high schema coverage.

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

  Purpose5/5

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

  The description clearly states the verb ('Update') and the resource ('a test case on a world model'). It distinguishes this tool from sibling test-case tools (add, list, delete) by its update action, which is explicit in the name and title.

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

  Usage Guidelines2/5

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

  The description gives no guidance on when to use this tool versus alternatives. It does not mention prerequisites like the test case needing to exist, how to obtain the test_case_id, or that this should be used instead of add/delete. No contextual usage cues are provided.

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

• lyzr_create_aci_configurationB
  3.2/5.0
  Behavior2/5

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

  Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description adds no behavioral context beyond what is structurally provided. It does not disclose whether the operation overwrites existing configurations, requires prior app creation, or has side effects such as triggering auth flows. No annotation contradiction exists, but the description does not enrich the agent's understanding.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence with no fluff. Every word contributes to the core purpose. It is concise and easy to parse, fitting the minimal scope of the tool.

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

  Completeness2/5

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

  Despite having a clear action and schema with 100% coverage, the description omits important context such as return values (no output schema), default behavior of security_scheme, whether the app must already exist, and relationship to 'ACI custom app' or 'ACI tool' siblings. This leaves the agent guessing about post-conditions and verification steps for a write operation.

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

  Parameters3/5

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

  Schema coverage is 100%, meaning all three parameters are described in the schema. The description only reiterates the app_id concept ('for a given app id') and does not add nuances about security_scheme defaults or overrides. Since the schema carries the full parameter detail, the baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description uses a specific verb ('Create'), names the resource ('ACI app configuration'), and scopes it ('for a given app id'). It clearly distinguishes from sibling list/delete configuration tools, so the agent knows what action this tool performs.

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

  Usage Guidelines2/5

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

  The description gives no guidance on when to use this tool versus alternatives such as lyzr_create_aci_custom_app or lyzr_create_lyzr_aci_tool. It does not mention prerequisites, exclusions, or related tools, leaving the agent to infer usage solely from the tool name.

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

• lyzr_create_toolB
  3.2/5.0
  Behavior2/5

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

  The description adds only the return value and the OpenAPI source, but does not disclose side effects, validation behavior, or the conditional requirement for openai_api_key when enhance_descriptions is true. It does not contradict annotations, but the annotations (readOnlyHint=false, idempotentHint=false) leave operational details unexplained.

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

  Conciseness5/5

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

  The description is a single front-loaded sentence with no filler. It conveys the action, the input type, and the return value efficiently.

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

  Completeness2/5

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

  For a creation tool with 9 parameters, no output schema, and a complex OpenAPI input, the description is too thin. It omits important context like the enhance_descriptions behavior, default header/parameter handling, and how this tool relates to sibling tool-creation endpoints.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the input schema already documents all 9 parameters with field descriptions. The tool description adds no extra parameter-level meaning beyond restating the schema input, so the baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states a specific action ('Create a new OpenAPI-based tool from an OpenAPI schema') and names the input format, distinguishing it from agent/session creation tools. It also adds the return value ('Returns the created tool'), making the purpose unambiguous.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like lyzr_create_tool_request, lyzr_update_tool, or lyzr_create_agent. There is no mention of prerequisites, exclusions, or conditions such as when enhance_descriptions requires an API key.

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

• lyzr_credential_createB
  3.2/5.0
  Behavior3/5

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

  Annotations already indicate a write operation (readOnlyHint=false), non-idempotent, and non-destructive. The description adds only that it 'returns the created credential,' which is useful given the absence of an output schema, but it does not disclose validation behavior, uniqueness constraints, or provider requirements. No contradiction with annotations.

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

  Conciseness5/5

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

  The description is two succinct sentences with no filler; the first states the action and the second the return behavior. It is well front-loaded and every word contributes value.

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

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 7 parameters, nested objects, and no output schema, a two-sentence description is insufficient for robust agent use. It omits usage context, how this relates to other credential tools, and critical details about the return payload, relying heavily on the schema and annotations to fill the gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, and the schema already documents all parameters with descriptions. The tool description adds no parameter-level meaning beyond what is in the schema, so the baseline score of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a clear action ('Create a new credential') and resource, so the core purpose is unambiguous. However, it does not differentiate from several sibling credential-creation tools such as lyzr_create_provider_credential or lyzr_create_static_tool_credential, making it clear but not distinctive.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives, nor does it mention related operations or prerequisites. It offers no context to help an agent choose between this and the many other credential-focused or creation tools in the sibling list.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_delete_feature_flagB
  3.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description explicitly notes 'Permanently delete', adding the irreversible nature beyond the annotations' destructiveHint. Annotations already convey destructive and idempotent hints, so the description adds some value but doesn't cover consequences like impact on dependent features or if deletion fails. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One simple sentence, completely front-loaded with the action and resource. No waste.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with one parameter and no output schema, but as a destructive operation it could benefit from noting side effects (e.g., permanent loss, cascading effects on agents using the flag). The description is minimal and lacks context about safe usage, especially given the destructive nature.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description covers 100% of the parameter ('Feature flag key'), so the description doesn't need to add much. It adds the notion of 'by key' in the description, which aligns with the schema. Baseline 3 applies due to high schema coverage, and the description adds minimal extra meaning.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool permanently deletes a feature flag by key, using the specific verb 'delete' and identifying the resource. It doesn't explicitly distinguish from sibling tools like lyzr_update_feature_flag or lyzr_delete_module, but the resource and action are 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/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance on when to use this vs. other feature flag tools (e.g., lyzr_get_feature_flag_admin, lyzr_update_feature_flag). It does not mention prerequisites such as needing to verify the flag exists or that deletion is irreversible, which would be useful context for an agent deciding between tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_execute_mcp_toolB
  3.2/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide limited safety information (readOnlyHint=false, destructiveHint=false, openWorldHint=true), but the description adds no behavioral context such as potential side effects, required permissions, or error behavior. It does not contradict annotations but also fails to enrich them with 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, compact sentence that conveys the core purpose without redundancy. It is appropriately sized and front-loaded with the action verb.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a dynamic tool that can invoke arbitrary MCP tools, the description lacks critical context: how to obtain valid server_id/tool_name combinations, what arguments should look like, and what side effects may occur. There is no output schema, so the description must compensate but does not.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the schema already describes all three parameters (server_id, tool_name, arguments). The description adds no extra parameter semantics, such as how to structure the arguments object for the target tool, but the baseline of 3 is appropriate given full schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (invoke) and the resource (a tool exposed by a registered MCP server), using a specific verb+resource structure. This distinguishes it from sibling tools like listing or managing MCP servers, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives, nor are prerequisites mentioned (e.g., needing a registered server or discovering available tools via lyzr_list_mcp_server_tools). The description is silent on context and exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_git_get_commit_snapshotB
  3.2/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds only that it retrieves a snapshot at a commit, without explaining what the snapshot contains (e.g., file tree, file contents, archive format) or whether it affects the working directory. This is minimal added 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no wasted words. It clearly states the verb and object, making it easy to parse quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  There is no output schema, so the description should clarify what a 'snapshot' returns (e.g., a file tree, a zip archive, a list of changed files), but it does not. Combined with the lack of usage guidance, the description leaves important context underspecified for a tool with no structured return type.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both agent_id and commit_sha described. The description adds no further parameter semantics, so it neither helps nor hurts; baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('snapshot of the repo state at a specific commit'), clearly distinguishing it from sibling tools like list_commits, get_status, or get_file_content. It conveys a point-in-time read of the full repository state, which 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 Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives such as lyzr_git_get_status or lyzr_git_get_file_content. No exclusions, alternatives, or prerequisites are mentioned; the use case is only implied by the phrase 'at a specific commit'.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_git_merge_branchesB
  3.2/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds no behavioral detail beyond what the annotations already convey. It does not mention conflict handling, whether a merge commit is created, whether the source branch is left intact, or any side effects. With annotations present, the bar is lower, but no additional context is provided to help the agent anticipate outcomes.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence of 11 words, front-loaded with the action 'Merge'. It is free of fluff and every word contributes to the core purpose. No unnecessary details are included.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the complexity of git merge operations (conflicts, fast-forward behavior, commit creation, etc.), the description is too sparse. It does not explain what happens to the repository state, whether the merge is pushed, or what the return value indicates. With no output schema, the agent is left without sufficient context to use the tool reliably.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter already documented (e.g., 'Branch to merge from', 'Branch to merge into'). The tool description itself adds no further parameter semantics, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Merge' and clearly identifies the resource ('one branch into another') and scope ('in an agent's git repo'). It unambiguously distinguishes this tool from the many other git operations in the sibling list, such as creating or switching branches.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention alternatives like creating a pull request or switching branches, nor does it specify any preconditions (e.g., clean working tree) or situations where merging is not appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kb_sync_browse_drivesB
  3.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark the tool as readOnly, openWorld, and idempotent. The description adds the deprecation status, which is valuable behavioral context beyond the annotations. However, it does not elaborate on return format or auth requirements.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is exceptionally concise, using one short sentence plus a deprecation marker. Every word serves a purpose, and the key information is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite the simple interface, the description lacks important context: it is deprecated but offers no alternative, and it does not describe what the tool returns (e.g., a list of drive IDs/names). Given the presence of sibling browse tools, the description is minimally adequate but has clear gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Both parameters (site_url and credential_id) are fully described in the schema with 100% coverage. The description adds no additional parameter semantics, so baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool browses drives within a SharePoint site, using a specific verb and resource. It distinguishes from sibling tools like browse_sites and browse_children. The deprecated marker adds context without confusion.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. The deprecated status is noted but no replacement tool is suggested, leaving agents to guess. This 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.

• lyzr_kb_sync_browse_sitesB
  3.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, which cover the safety profile. The description adds no extra behavioral context beyond the deprecation notice, which is also present in the title. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that directly conveys the tool's purpose and deprecation status. It is free of fluff, though it borders on under-specification. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple, read-only browse tool with annotations and a well-documented single parameter, the description is minimally adequate. However, it lacks details about the return format and does not state when to use this over the sibling browse tools, which is a notable gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides 100% coverage for the single parameter credential_id with a meaningful description ('ACI credential_id for SharePoint auth'). The tool description does not add any additional parameter detail beyond what the schema already supplies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Browse') and the resource ('available SharePoint sites'). It is specific enough to distinguish from sibling tools like browse_drives and browse_children, and the 'deprecated' tag adds necessary status context.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention any alternative (e.g., lyzr_livesource_ext_browse_sites) or exclusion criteria, leaving the agent without context for tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kb_sync_webhook_validationB
  3.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, which cover the safety profile. The description adds the deprecated status, which is useful context, but it does not explain additional behavioral details such as what the handshake validates, expected request/response patterns, or authentication requirements.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence prefixed with a clear deprecated marker. It is concise and front-loaded, with no wasted words. It could be slightly more informative, but for a deprecated, parameterless endpoint, this level of brevity is acceptable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has no output schema, so the description must convey what the endpoint returns or does during the handshake. It only says "Webhook validation handshake endpoint," which gives no details about the handshake protocol, expected inputs, or response. Even though it is deprecated, the description does not adequately cover what happens when the tool is invoked.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has zero parameters, so the baseline is 4. The description does not need to explain parameter meaning since there are none. The schema coverage is 100%, and the description does not complicate parameter understanding.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states "Webhook validation handshake endpoint," which identifies the tool's function as validating webhooks, but it is vague about what a "handshake" entails or what this endpoint specifically does. It partially distinguishes from the sibling `lyzr_kb_sync_webhook_notification` by focusing on validation, but the term "handshake" is ambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description starts with "[deprecated]", which clearly signals that the tool should not be used. However, it does not provide an explicit alternative or specify when to use it versus other webhook-related tools. The deprecation flag is a strong usage signal but the lack of an alternative is a gap.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kb_train_docxB
  3.2/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate a mutating operation (readOnlyHint false), and the description merely repeats that action without adding context about side effects, processing time, or reversibility. No extra behavioral disclosure beyond what annotations already state.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single clear sentence with no wasted words. It is perfectly concise and front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 9 parameters, a mutation, and no output schema, this description is too thin. It omits mention of prerequisites (e.g., the rag_id), what happens after training, or how the response is structured, making it incomplete for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the description is not required to explain parameters. The description adds no additional parameter semantics, resulting in the baseline score of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb ('Upload and train'), a resource ('DOCX file'), and a target ('a knowledge base'). It distinguishes from sibling tools by naming the DOCX format explicitly.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool vs alternatives like kb_train_pdf or kb_train_txt_file. The format is implied by the name but there are no explicit conditions or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kg_ext_train_text_neo4jB
  3.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=false and destructiveHint=false, indicating a write operation that is not destructive. The description adds the 'namespaced endpoint' context but does not disclose additional behavioral details such as side effects, deduplication, or asynchronicity. It does not contradict annotations, so a baseline 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, front-loaded sentence with zero filler. It directly states the verb and target, making it extremely concise and efficiently structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 6 parameters, 3 required, nested objects, and a clear sibling task-based variant (lyzr_kg_ext_train_text_task_neo4j), this description is too sparse. It doesn't clarify whether training is synchronous, how rag_id is used, or when to prefer this over the task variant, making the context incomplete for safe and correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with all six parameters individually documented in the input schema (text, rag_id, source, extra_info, extra_fields, schema_prompt). The description adds no parameter-specific semantics, but the schema already carries the full load, so baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description states a specific action ('Ingest text') and resource ('Neo4j knowledge graph'), clearly identifying the tool's purpose. The mention of 'namespaced endpoint' and 'Neo4j' helps differentiate it from sibling tools like lyzr_kg_train_text and lyzr_kg_ext_train_text, though it doesn't explicitly contrast them.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does 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. The description is purely definitional and does not mention any conditions, prerequisites, or exclusions. Given the large set of sibling KG training tools (e.g., lyzr_kg_ext_train_text_task_neo4j, lyzr_kg_train_website), this lack of direction is a clear gap.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_list_toolsB
  3.2/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds only the scoping phrase 'caller's registered tools' but does not disclose behavioral details such as pagination, sorting, or what counts as 'registered.' No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence with no filler or redundant content. It is front-loaded and immediately conveys the tool's purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only listing tool with strong annotations, the description is minimally sufficient. However, there is no output schema and the description does not mention return format or filtering behavior, leaving some gaps for an agent deciding whether to invoke it.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool accepts zero parameters, so the schema fully covers the parameter space. The description doesn't need to explain parameter semantics; the baseline for zero-parameter tools is 4.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and clearly identifies the resource ('the caller's registered tools'), effectively distinguishing it from broader listing tools like lyzr_get_all_tools. However, it doesn't explicitly contrast with similar siblings such as lyzr_list_all_user_tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives, no prerequisites are mentioned, and there are no exclusions or alternative tool references. The context of 'caller's registered tools' is implied but not elaborated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_livesource_getB
  3.2/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, so the read-only nature is covered. However, the description adds no additional behavioral context beyond that, such as error handling, return format, or prerequisites, leaving the agent with only the basic function statement.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, terse sentence that is easy to parse and front-loaded with the action. It is appropriately concise, though it largely restates the tool title and could be slightly more informative.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple getter tool with only two parameters and no output schema, the description is minimally sufficient. It states the core operation but omits details about return values or when a live source might not be found. Given the low complexity, the lack of extra context is acceptable but not ideal.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides 100% description coverage for both parameters (rag_id and live_source_id), so the description does not need to compensate. It adds no extra meaning beyond the schema, but this is acceptable given the high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Fetch' with the resource 'live source' and the 'by id' qualifier, which clearly identifies the tool as a single-resource retrieval operation. This distinguishes it from sibling operations like lyzr_livesource_list or lyzr_livesource_remove.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided about when to use this tool versus alternatives such as list, add, or remove. The description simply states what the tool does without any contextual or conditional instructions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_livesource_syncB
  3.2/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate non-read-only, non-idempotent, non-destructive, open-world behavior. Description adds no further context about whether sync is asynchronous, how to monitor status, what side effects occur, or failure behavior. It is too vague for a side-effectful operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Description is a single short sentence with zero wasted words. It is front-loaded and retains full clarity for the core action.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  No output schema and minimal annotation enrichment. The description omits crucial context such as async behavior, return value, prerequisites (e.g., live source must exist), or how to check sync status. This is insufficient for a tool that triggers a potentially long-running operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers both parameters with clear descriptions ('Knowledge base id', 'Live source id'), achieving 100% coverage. Description does not add new parameter meaning, so baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description uses specific verb 'trigger' and resource 'live source', clearly identifying the action. It distinguishes from sibling tools like add, remove, pause, resume, and repoint by focusing on the sync action.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does 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. The description does not mention preconditions, scheduling alternatives, or how it differs from related tools like lyzr_livesource_ext_sync_permissions or lyzr_livesource_pause/resume.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_memory_searchB
  3.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description's 'semantic' adds a useful nuance about natural language matching. However, it doesn't disclose ranking, scope, or result limitations. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single six-word sentence, exceptionally concise and front-loaded with the key verb and resource. It contains zero fluff or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 6 parameters, multiple scoping filters, and no output schema, this description is under-specified. It doesn't explain how to scope the search, what semantic match means, or how results are ordered/limited, leaving an agent guessing about critical behavioral details.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema descriptions cover 5 of 6 parameters (83%), leaving only limit undocumented. The description itself adds no parameter-specific meaning beyond the word 'semantic', which is insufficient to compensate for limit's lack of description.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a semantic search operation over memories, with a specific verb and resource. It distinguishes from memory_add/get/update/delete, but doesn't explicitly differentiate from memory_list, which could overlap in 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/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to use this tool versus memory_search alternatives like memory_list or memory_get. It doesn't mention scoping by session, agent, or cross-session behavior, which the schema parameters suggest.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_memprovider_provision_aws_agentcore_memoryB
  3.2/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a write operation (readOnlyHint: false) and not idempotent, but the description adds no behavioral context beyond those annotations. It doesn't disclose side effects, required credentials (beyond schema), or what the tool returns. Since there is no output schema, the agent is left unaware of what a successful provisioning produces.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that directly states the purpose. It is concise, front-loaded, and contains no filler, earning a high score for structure.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has no output schema and sits among many related memory provider tools. The description only restates the title without explaining what provisioning entails, what the return value is, or how it relates to sibling tools like list/use_existing/delete. This is insufficient for an agent to fully understand the tool's role and outcome.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with all four parameters described in the schema. The description adds no parameter-level detail, but the baseline of 3 is appropriate because the schema already carries the semantic load for parameter understanding.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('Provision') and specific resource ('AWS AgentCore memory resource'), and the word 'new' differentiates it from sibling tools like use_existing_aws_agentcore_memory. This clearly tells the agent what the tool does and distinguishes it from related memory provisioning tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention when to choose provisioning over using an existing resource, or any prerequisites such as needing a validated credential. This leaves the agent without context for tool selection among the many memory provider tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_ops_export_report_csvB
  3.2/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate the tool is not read-only (readOnlyHint=false) and may have side effects (openWorldHint=true), matching the 'export' action. However, the description adds no additional behavioral context, such as what happens to the generated CSV (returned as content, saved to storage, or provided via a link), whether it is synchronous, or any permission requirements.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with zero fluff. Every word contributes to meaning: action, object, output format, and temporal scope. That is an ideal level of conciseness for its length.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  While the tool is simple, the absence of an output schema means the description should clarify what the agent receives when calling it (CSV content, file identifier, etc.). It also does not mention whether this is an asynchronous operation or how the result is retrieved. Given the large number of sibling tools, more context is needed for reliable selection and invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides full coverage of both parameters (start_date and end_date) with format descriptions (YYYY-MM-DD). The phrase 'date range' in the description aligns with these parameters but adds no extra meaning beyond the schema. Baseline 3 applies given high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific action: 'Export an operations report as CSV' and scopes it to 'a date range'. This distinguishes it from sibling tools like lyzr_ops_generate_report or lyzr_ops_get_dashboard, which would generate or display reports in other ways.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit when-to-use or alternative guidance is provided. The description implies usage when a CSV export of an ops report is needed, but it does not contrast with the many sibling report and ops tools. An agent would have to infer use cases from the name.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_schedule_deleteB
  3.2/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already indicate destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description adds no additional behavioral context such as whether deletion is permanent, recoverable, or how it interacts with dependent resources. It merely restates the destructive nature already captured by annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence of five words, front-loaded with the verb. Every word earns its place, and there is no redundant or filler content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter delete tool with annotations covering safety/destructive profile, the description is minimally viable. However, it does not mention that deletion is permanent or note any side effects, and given the presence of sibling pause/resume tools, a brief note distinguishing delete from those would improve completeness. Overall, adequate but with a clear gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The single parameter schedule_id is documented only as a string in the schema with 0% description coverage. The description's phrase 'by id' minimally clarifies that the parameter is the identifier of the schedule to delete, but this is almost tautological given the parameter name. It does not add substantial semantic value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Delete a schedule by id' uses a specific verb ('delete') and resource ('schedule'), clearly distinguishing it from sibling scheduling tools like create, list, pause, or resume. It also names the key operand (id), making the tool's function 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/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No usage guidance is provided beyond the purpose itself. There is no mention of when to use delete versus alternatives such as pause/resume, nor any indication of prerequisites or consequences. The description simply states what it does, offering no explicit context for selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_share_workflowB
  3.2/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description merely restates the action without disclosing behavioral details beyond what annotations already indicate. It does not mention whether sharing is additive or replaces existing shares, whether it sends notifications, or if specific permissions are required. Annotations indicate the tool is not read-only, but the description adds no extra 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear, and front-loaded sentence of eight words. Every word adds value, and there is no redundant or filler content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has no output schema and multiple required parameters, the description is too sparse. It does not explain the effects of sharing, any prerequisites (e.g., ownership or admin rights), or what the result of a successful share looks like. This leaves the agent with limited understanding of the tool's full behavior.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides descriptions for all four parameters, so the description adds little beyond reinforcing that the action involves email addresses. The phrase 'with one or more email addresses' does clarify the email_ids parameter but does not explain relationships or constraints among the parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Share') and clearly identifies the resource ('a workflow') and the target ('with one or more email addresses'). This effectively distinguishes it from sibling tools like get_workflow, update_workflow, or delete_workflow.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives such as lyzr_update_workflow or the sharing group tools. There are no prerequisites, exclusions, or context about when sharing is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_sharing_get_resource_groupsB
  3.2/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, and the description simply repeats the 'list' nature without adding behavioral context such as return format, pagination, or side effects. It adds no value beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that efficiently communicates the tool's purpose with no unnecessary words or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple list nature, the description is adequate. It lacks output format details, but with no output schema and clear annotations, the core information is sufficient for an agent to understand the tool's role, though some return expectations would be helpful.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the parameters are fully documented in the schema. The description adds no further semantic detail about the parameters, only vaguely referencing 'a given resource' without elaborating on resource_type or resource_id.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists sharing groups for a given resource, using a specific verb and resource. It distinguishes itself from related sharing tools by focusing on resource membership rather than listing all groups or retrieving a specific group, though it could be more explicit about this 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/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives like lyzr_sharing_list_groups or lyzr_sharing_check_access. The description implies a use case but does not state when to prefer it or exclude other tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_agent_id_by_nameB
  3.3/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already cover read-only, idempotent, and open-world behavior. The description adds no behavioral details beyond the title, such as behavior when the name is not found, case sensitivity, or whether it returns the first match. Since it merely restates the tool's purpose without disclosing edge-case behavior, it scores low.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence with no wasted words, which is concise. However, it is essentially a restatement of the tool name and title, lacking any additional structure or context that would justify its existence. It is adequate but minimal.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple lookup tool with good annotations, the description is mostly sufficient. However, no output schema exists, and the description does not specify the return value type, error behavior, or uniqueness guarantees. Gaps remain, making this only minimally viable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers 100% of the parameter with a clear description ('Agent name'). The tool description does not add extra meaning or context for the parameter, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Resolve an agent id by its name' clearly states the verb (resolve), the resource (agent id), and the scope (by name). It distinguishes this from sibling tools like lyzr_get_agent (which fetches details by id) and lyzr_list_agents (which lists all agents), making its purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage (when you need the ID from a name) but does not explicitly state when to use this tool over alternatives, nor does it mention that other agent APIs might require this ID. No exclusions or alternative tool references are provided, so it earns a mid-range score.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_agent_published_sessionsB
  3.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint, openWorldHint, and idempotentHint, establishing this as a safe read operation. The description adds the 'published' qualifier, which narrows the scope, but provides no additional behavioral details such as pagination, ordering, or what 'published' means in this 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence with no filler. It is front-loaded with the verb and resource, making it immediately actionable and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with one parameter and safe annotations, but the description omits clarification of 'published sessions' and any indication of the return format. Given no output schema, the description could be more informative, though the basics are present.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already fully documents agent_id with a description ('Agent id'), and the schema coverage is 100%. The description's phrase 'for an agent' adds no additional semantic detail beyond the schema, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'List' and identifies the resource as 'published sessions for an agent', clearly stating the tool's function. It does not explicitly contrast with sibling tools like 'lyzr_agent_sessions', which could also list sessions, but the scope is narrowed by the 'published' qualifier.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternative session-listing tools such as lyzr_agent_sessions or lyzr_session_history_by_agent. The description only states what the tool does, not when it should be selected.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_create_agent_evalB
  3.3/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already set readOnlyHint=false and idempotentHint=false, indicating this is a non-read-only, non-idempotent operation. The description adds only the purpose ('create an eval config') and doesn't disclose additional behavioral traits such as whether existing configs are overwritten, whether a fresh config is generated each call, or any authentication requirements. This adds minimal value beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is one short sentence with no redundancy, front-loading the action and key resource. All words earn their place, so 5.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema and a 4-parameter input that includes a nested array, the description is very sparse. It doesn't mention prerequisites (e.g., agent/session must already exist) or behavior on duplicate eval_name. However, the schema detailedly documents all parameters and their semantics, so the tool is somewhat self-contained; still, a 3 reflects the missing contextual guidance.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description's mention of 'set of eval cases' aligns with agent_eval_list and 'for an agent' with agent_id, but it doesn't add meaning beyond the schema, so 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Create') and identifies the resource ('agent evaluation config') and its payload ('set of eval cases for an agent'). This clearly distinguishes it from sibling tools like lyzr_get_agent_eval (retrieval) and lyzr_create_agent_eval_result (creating results), earning a 5.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. There is no mention of setting up an evaluation before running it or alternative tools for similar purposes, so it scores 2.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_create_inference_v4B
  3.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare non-read-only, non-idempotent, and non-destructive behavior. The description adds the OpenAI Responses-API style context but no additional behavioral details such as streaming behavior, output format, or auth requirements. No contradictions with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One short sentence, front-loaded with the verb and resource. No wasted words, and every part of the sentence contributes to understanding the tool's purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 16 parameters and several close siblings, but the description gives no guidance on selecting among them and no return-value context. It is minimally viable because the schema and annotations fill many gaps, but an agent is left guessing about usage boundaries.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and every parameter has a description. The description names the three primary parameters (model, input, tools), but this adds minimal value beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names the operation ('Create'), the resource ('v4 inference response'), and the API style ('OpenAI Responses-API'), making the core purpose clear. However, it does not distinguish this from the close sibling lyzr_create_response_v4, so it stops short of full differentiation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No when-to-use guidance, comparison to alternatives, or exclusions are provided. The description only restates the tool's purpose; an agent cannot tell when to choose this over lyzr_create_response_v4, lyzr_chat_completions_v4, or lyzr_chat.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_connected_accountsB
  3.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark this as readOnly, idempotent, and non-destructive, and the description does not contradict them. The phrase 'connected tool accounts/credentials' adds some context about the resource scope, but it doesn't mention additional behavioral details like authentication, pagination, or response format.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is one short sentence that immediately conveys the tool's purpose. It is appropriately sized with no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only listing tool with full schema coverage and safety annotations, the description is minimally adequate. However, it lacks details about what 'connected tool accounts' includes, and no alternatives are mentioned, which could matter given the large number of sibling tools.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers 100% of parameter descriptions (user_id is described as 'User id'), so the baseline of 3 applies. The description's use of 'a user's' corresponds to user_id but adds no additional semantic detail.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (list) and resource (user's connected tool accounts/credentials). It does not distinguish from sibling tools like lyzr_credential_list or lyzr_list_provider_credentials_by_type, so it falls short of a 5.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to use this tool versus other credential-listing tools. It simply states what it does, leaving the agent to infer when it should be called.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_context_value_internalB
  3.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that it is an internal endpoint requiring an internal api_key, which is useful context, but it does not disclose the return format or any restrictions beyond what annotations and schema already convey.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, well-structured sentence that front-loads 'Internal endpoint' and conveys the essential action. There is no redundant wording, making it maximally concise for the information provided.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple (2 params, no output schema), and annotations are rich, so the brief description covers the basics. However, it lacks any mention of what the return value looks like, how to obtain the internal api_key, or any context about the nature of 'context value', leaving some gaps for broader understanding.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with api_key and context_name already described (e.g., 'API key for internal access'). The description merely repeats these concepts in prose without adding deeper semantics or usage details, so it meets the baseline but does not exceed it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool fetches a context's value by its name using an internal api_key, which is a specific verb and resource. However, it does not differentiate from the sibling tool lyzr_get_context_by_name_internal, which likely serves a very similar purpose, so some ambiguity remains.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'Internal endpoint' implies restricted usage, but there is no explicit guidance on when to choose this tool over the many sibling context-related tools, nor any exclusions or alternatives mentioned. It leaves the agent without clear decision criteria.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_tools_actionsB
  3.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety and side-effect transparency. The description adds the provider scoping but does not disclose return format, pagination, or any operational behavior, so it contributes little beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, well-structured sentence that front-loads the action and resource. There is zero redundancy, making it extremely concise and efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  While the tool is simple, the description omits what a 'tool action' consists of and does not explain the return value or how provider_identifier is resolved. With no output schema, a bit more context would help, but the minimal description may be sufficient for a trivial listing operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with all three parameters (app_id, tool_source, provider_identifier) described in the schema. The description does not add any extra parameter semantics or validate the meaning of 'provider_identifier' beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'List available tool actions for a provider' clearly identifies the verb (List), resource (tool actions), and scope (for a provider). It distinguishes from generic tool-listing siblings by specifying the provider scope, though it does not explicitly name alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to choose this tool over siblings like lyzr_list_tools or lyzr_get_all_tools. There are no exclusions or preconditions mentioned, 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.

• lyzr_kb_bulk_deleteB
  3.3/5.0
  Behavior1/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description states 'Permanently delete' (destructive), but the annotation destructiveHint=false. This is a direct contradiction, and the description provides no additional behavioral context like error handling or partial failures.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single concise sentence conveying action, target, scope, and permanence. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter bulk delete operation, the description is minimally sufficient but lacks details on return values, partial failure behavior, and prerequisites. The contradiction with annotations further reduces completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% and the only parameter 'config_ids' is fully described in the schema. The description adds no meaningful parameter detail beyond restating the operation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the verb 'delete' with resource 'knowledge base configs' and specifies 'multiple' and 'by id', clearly distinguishing it from single-delete siblings like lyzr_kb_delete.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The word 'multiple' implies use for batch operations vs singular delete, but no explicit guidance on when to use vs alternatives or when not to use. It relies on the title and context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kb_listB
  3.3/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so safety aspects are covered. However, the description adds no additional behavioral context beyond what the annotations and parameter schema already provide. It does not mention pagination, sorting, response format, or any other 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that clearly states the action and object. It is front-loaded and free of unnecessary words. While it is minimal, it is appropriately sized for a straightforward list operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (one parameter, clear annotations, no output schema), the description is sufficiently complete. It identifies the user scope and the resource being listed. No critical information is missing for correct invocation, though it could benefit from a note about the return type or any pagination behavior.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema description covers 100% of parameters, with user_id adequately described as 'User id whose knowledge bases to list'. The tool description does not add extra meaning beyond this; it reiterates the user scoping, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the operation: 'List' with the resource 'knowledge bases' scoped to 'a user'. This distinguishes it from related tools like lyzr_kb_get (single KB) and lyzr_kb_list_documents (documents within a KB), making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives, such as distinguishing it from lyzr_kb_get for retrieving details of a single knowledge base or lyzr_kb_list_documents for listing documents. It simply states what it does without any exclusions or alternative suggestions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kb_list_documentsB
  3.3/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. However, the description adds no behavioral context beyond the one-line statement – no mention of return format, pagination, or scope limitations. With a good annotation set, a score of 2 is appropriate because the description adds minimal value over annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that is front-loaded with the verb 'List'. No filler words; it earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple (1 param, no output schema), but the description is minimal. It does not explain what fields are returned (e.g., document IDs, names) or mention pagination. Since the output schema is absent, the description should carry more weight; for a list operation, this is a gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema documents the single parameter raq_id with a clear description 'Knowledge base id', covering 100% of parameters. The description doesn't add any additional meaning, but since schema coverage is complete, the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'List the documents indexed in a knowledge base' clearly states the action (list) and the resource (documents in a KB), with a specific scope. It distinguishes from sibling tools like lyzr_kb_list (which likely lists KBs) by focusing on documents within a KB.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no explicit guidance on when to use this tool versus alternatives like lyzr_kb_list or lyzr_kb_get. It doesn't mention any exclusions or context. Given the large sibling set, this lack of guidance makes it hard for an agent to decide which tool to invoke.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kb_train_pptxB
  3.3/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate a mutating, non-destructive operation; the description adds little beyond restating 'train.' It does not disclose whether content is appended/replaced, whether the operation is synchronous, or any authentication or side-effect 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The one-sentence description is front-loaded and economical, with no wasted words, but it is slightly too terse given the tool's 8 parameters and lack of output schema; a single additional sentence on usage or outcomes would not compromise conciseness.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema and a moderately complex 8-parameter input, the description leaves significant gaps: no return value, no async indication, no prerequisite knowledge (e.g., existing rag_id), and no differentiation from closely related training tools.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% and all eight parameters have individual descriptions, so a baseline score of 3 is appropriate. The tool description itself contributes no additional parameter-level meaning (e.g., base64 encoding or chunking behavior).

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'train' with a concrete resource ('PPTX presentation') and target ('knowledge base'), directly distinguishing it from sibling parse-only tools like lyzr_parse_pptx and other lyzr_kb_train_* formats.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The use case is implied by the name and description (training a KB from PPTX), but there are no explicit when-to-use instructions, exclusions, or references to alternatives such as lyzr_kb_train_documents or lyzr_parse_pptx.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kb_train_txt_fileB
  3.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows this is a non-destructive write operation. The description adds the 'train' semantics (adding to a knowledge base) but does not disclose potential side effects like whether it appends or replaces existing content, or any rate limits. This is adequate but not rich beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is 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 target resource type.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the moderate complexity (8 parameters, multiple sibling training tools) and absence of an output schema, the description is somewhat minimal. It does not explain how this file-based training differs from text-based training, nor does it provide guidance on obtaining the 'rag_id' or interpreting the result. Yet the annotations and schema cover safety and parameter details, making it functional but not complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, meaning every parameter has a description. The tool description itself does not add parameter-specific meaning, but the baseline of 3 is appropriate since the schema already fully documents parameters like 'rag_id', 'chunk_size', and 'file_content_base64'.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Upload and train' and the resource 'a plain-text (.txt) file into a knowledge base', which is specific and distinguishes it from website or other file-type training tools. However, it does not explicitly differentiate from the closely named sibling 'lyzr_kb_train_text', which may handle raw text input rather than a file upload.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives like lyzr_kb_train_text or lyzr_kb_train_documents. It does not mention prerequisites such as creating a knowledge base first or how to obtain the required 'rag_id'. The usage context is only implied by the verb 'train' and the file type.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kg_ext_deduplicate_neo4jB
  3.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already signal that this is a non-readonly, idempotent, non-destructive operation. The description adds the contextual detail that it operates on a namespaced Neo4j endpoint for a RAG system, but it doesn't explain side effects or merge behavior. This adds some value beyond annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence with no redundant content. It front-loads the action and resource, making it easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has a simple signature and annotations, but the description is minimal. It omits when to use it, what result to expect, and any caution about long-running or side effects. It is minimally viable but lacks richer context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the single parameter 'rag_id' is already described as 'The ID of the RAG system'. The description's mention of 'namespaced endpoint' aligns with the parameter but doesn't add material new meaning beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Deduplicate') and resource ('entities in the Neo4j knowledge graph'), clearly indicating the operation. It adds 'for a RAG system (namespaced endpoint)' which hints at the context and distinguishes it from the sibling lyzr_kg_deduplicate, though not explicitly naming alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives like lyzr_kg_deduplicate or other KG tools. It lacks any 'when to use' or 'when not to use' instructions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kg_ext_train_text_task_neo4jB
  3.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly=false, idempotent=false, and destructive=false. The description adds the async behavior, which is not covered by annotations, but it doesn't elaborate on implications like returning a task ID or needing to poll status. It adds some value but is thin.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler. It efficiently communicates the core action and a key differentiator ('async task'), though it is quite brief. It earns a 4 for being appropriately sized without wasting words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  There is no output schema, and the description does not explain the return value, how to monitor the async task, or what 'namespaced endpoint' means. It also doesn't mention related status-checking tools (e.g., lyzr_kg_task_status). Given the tool's async nature, this leaves significant gaps for the agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage for all 6 parameters, so the schema already handles parameter semantics. The description adds no additional parameter context, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (Ingest text) and resource (Neo4j knowledge graph), and differentiates itself with 'async task' and 'namespaced endpoint'. However, it doesn't explicitly contrast with the synchronous variant (lyzr_kg_ext_train_text_neo4j) beyond the async aspect, so it's not a perfect 5.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'as an async task' implies when to use this tool (when non-blocking execution is desired) but does not explicitly name alternatives or state when not to use it. It lacks clear exclusion criteria or comparison to sibling tools like lyzr_kg_train_text or lyzr_kg_ext_train_text_neo4j.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kg_get_graphB
  3.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint, openWorldHint, and idempotentHint, providing a clear safety profile. The description does not add any behavioral context beyond that, such as return format, pagination, or error behavior, but it does not contradict the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence with no filler words. It communicates the essential function efficiently and would fit well in an agent context.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only fetch tool, the description and schema cover the basics, but there is no output schema and no explanation of the graph structure or return format. Additionally, the lack of differentiation from the Neo4j sibling tool leaves some ambiguity, making the description adequate but not complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with both 'limit' and 'rag_id' having detailed descriptions. The description adds no extra meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Fetch') and resource ('knowledge graph for a knowledge base'), clearly stating what the tool does. It is unambiguous about the operation, though it does not explicitly distinguish itself from the sibling tool lyzr_kg_ext_get_graph_neo4j.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives such as lyzr_kg_ext_get_graph_neo4j. The description does not offer context about preferred scenarios or exclusions, leaving the agent to infer usage solely from the tool name.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_list_artifactsB
  3.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the fact that pagination and filters are optional, implying a broad list, but does not disclose behavior like ordering, default scope, or anything beyond the schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that conveys the essential action and optional parameters with no unnecessary words. It is well front-loaded and earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with 5 optional parameters, full schema coverage, and safe-read annotations. However, the description does not mention the existence of a more specific sibling (list_artifacts_by_session) or clarify the general-purpose nature, leaving a small but clear gap in context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3. The description groups parameters as 'pagination and filters' which adds minimal conceptual clustering, but does not add detail beyond what the schema already provides for each parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists artifacts, which is a specific verb+resource. It mentions optional pagination and filters, but does not distinguish it from the sibling tool 'lyzr_list_artifacts_by_session', so it lacks sibling differentiation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives like lyzr_list_artifacts_by_session or other list tools. The description does not state any exclusions or preferred use cases.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_list_org_audit_logsB
  3.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already disclose readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds the org-wide scope, which is helpful, but does not disclose other behavioral aspects like pagination or return format. No contradictions with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence of 11 words, front-loaded with the action and resource, and contains no filler. It is concise and scannable, earning a perfect score.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a list tool with 11 parameters and no output schema, the description is adequate but minimal. The schema covers parameters, and annotations cover safety, but the description lacks usage guidance or a hint at the response structure, making it incomplete for an agent to fully contextualize the tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with descriptive text for all 11 parameters and enums for 4 of them. The description's mention of 'optional filters' adds no meaning beyond what the schema already provides, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the verb ('Get') and resource ('audit logs') with a clear scope ('for the whole organization'). This differentiates from sibling audit log tools that are scoped to 'my', 'user', 'resource', or 'session', though it does not explicitly name those alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus the many sibling audit log tools (e.g., lyzr_list_my_audit_logs, lyzr_list_user_audit_logs, lyzr_list_resource_audit_logs). The description does not mention exclusions or alternatives, making tool selection ambiguous for an agent.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_memory_deleteB
  3.3/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and idempotentHint=true, so the destructive nature is known. The description adds no behavioral context beyond restating the delete action—no mention of irreversibility, ownership scoping, or effects on associated data.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence with no wasted words. It front-loads the action and object, and every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite simple inputs (2 params, no output schema), the description leaves key contextual gaps: the role of owner_id, return behavior (or absence thereof), and semantics of deleting an already-deleted or non-existent memory (idempotency). The bare description is insufficient for confident invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 50%: memory_id is documented but owner_id is not. The description does not compensate, merely saying 'by id', which adds no meaning beyond memory_id's existing schema description. owner_id remains completely unexplained.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses specific verb 'Delete' and resource 'memory record by id', clearly distinguishing it from sibling memory tools like memory_get, memory_update, and memory_list. It unambiguously states the operation and target.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage (deleting a memory record) but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It doesn't mention when not to use it or how it relates to other memory operations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_memory_updateB
  3.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description aligns with the readOnlyHint=false annotation (it is a write operation) and does not contradict idempotentHint=true. However, it adds little beyond annotations: it does not disclose whether updates are partial or full replacements, what happens to unspecified fields, or the return value. The phrase 'and/or' hints at partial updates 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence with no filler. The verb and object are front-loaded, making it immediately clear what the tool does. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple three-parameter update tool with annotations, the description gives a basic purpose but lacks important context: it does not state whether the update is additive/partial, describe the output/return behavior, or clarify the owner_id parameter. Given no output schema, more detail would help the agent understand the full behavior.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 67%: content and memory_id are described, but owner_id is not. The description's reference to 'metadata' may implicitly cover owner_id, but this is vague and does not clarify the exact meaning or expected format. It adds some semantic value but does not fully compensate for the owner_id gap.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the action ('Update') and the resource ('a memory record'), and specifies the scope as 'content and/or metadata'. This distinguishes it from sibling memory tools like add, get, list, and delete. However, it does not explicitly differentiate it from other update tools among the many siblings, though the 'memory record' context makes it clear enough.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description offers no explicit usage guidance, such as when to use this tool versus alternatives like lyzr_memory_add or lyzr_memory_delete. It neither mentions prerequisites (e.g., existing record) nor exclusions. Usage is only implied by the verb 'update', which is not enough for an agent to decide confidently.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_memprovider_list_aws_agentcore_resourcesB
  3.3/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description adds no new behavioral context. It does not mention return format, error handling, or credential validation, providing no transparency beyond what annotations and the schema already convey.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no wasted words. It immediately communicates the action, resource type, and scope.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simplicity of the tool and the presence of annotations, the description is adequate but lacks detail about the return value or what constitutes a 'memory resource.' Since there is no output schema, the description could have clarified the response structure, but the tool is still minimally complete for a straightforward list operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides a full description for credential_id ('The AWS AgentCore credential id') with 100% coverage. The description's reference to 'for a credential' adds no additional meaning beyond restating the parameter's purpose.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('List') and the specific resource type ('AWS AgentCore memory resources') scoped to a credential. This distinguishes it from sibling tools like lyzr_memory_list (general memory list) and lyzr_memprovider_list_providers (providers list).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or related tools such as lyzr_memprovider_provision_aws_agentcore_memory or lyzr_memprovider_delete_aws_agentcore_resource, leaving usage context entirely implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_memprovider_mem0_statusB
  3.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, and the description's 'Get' is consistent with read-only behavior. However, the description adds no extra behavioral context such as whether status includes connectivity checks or what credential states exist.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that front-loads the action and target. There is no waste or unnecessary elaboration, which is ideal for this simple tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is extremely simple with one parameter, and the schema and annotations cover most essential context. However, there is no output schema and the description doesn't clarify what 'status' returns or what status values are possible, leaving a minor but notable gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with the parameter 'credential_id' described as 'The Mem0 credential id'. The description adds no additional semantic detail beyond the schema, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does 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 'status of a Mem0 memory provider credential', making the tool's basic purpose unambiguous. It distinguishes from validation tools by focusing on status, though it does not explicitly differentiate from get_provider or validate_mem0.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No usage guidance is provided. The description doesn't indicate when to use this tool instead of lyzr_memprovider_validate_mem0 or lyzr_memprovider_get_provider, nor any exclusions or prerequisites.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_memprovider_use_existing_aws_agentcore_memoryB
  3.3/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds no behavioral context beyond the annotations. It doesn't explain side effects of attaching, whether the resource must already exist, or what happens to the credential. The annotations indicate a non-read-only, non-idempotent mutation, but the description provides no further transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that is front-loaded with the action and easy to parse. Every word contributes meaning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter attach operation, the description is adequate but lacks details about the outcome, prerequisites, or error behavior. Without an output schema, agents don't know what a successful call returns or what conditions must hold.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already fully describes both parameters (memory_id and credential_id) with clear descriptions, so baseline is 3. The description adds no additional semantic meaning beyond what the schema provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Attach an existing AWS AgentCore memory resource to a credential.' It uses a specific verb (attach) and specifies the object and target, effectively distinguishing it from sibling tools like provision_aws_agentcore_memory.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives no guidance on when to use this tool versus alternatives such as provisioning a new memory resource or other memory provider operations. No prerequisites, use cases, or exclusions are mentioned, leaving the agent to infer 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.

• lyzr_ops_get_traceB
  3.3/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and idempotentHint=true, so safety is covered. The description adds no extra behavioral context such as what happens if the trace is not found, what data is returned, or any prerequisites beyond the required id. Thus the description contributes little beyond the structured annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single short sentence that is efficient and front-loaded. It contains no fluff and communicates the core action directly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simplicity of the tool (one required parameter, no output schema), the description is mostly adequate. However, it does not explain what an execution trace is or what the response will contain, which could leave an agent uncertain about how the result differs from other trace-related tools like lyzr_ops_get_trace_run or lyzr_get_trace_details.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with a single trace_id parameter described as 'Trace id'. The description's phrase 'by id' adds no new meaning beyond the schema. Baseline of 3 is appropriate since the schema already documents the parameter fully.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (Fetch), resource (execution trace), and scope (single, by id). It distinguishes itself from list/get-traces tools by specifying 'single', but it doesn't name any alternatives or mention related tools like lyzr_get_trace_details.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied: the agent needs a trace_id to fetch a single trace. However, no explicit guidance is given on when to use this tool versus the many related trace tools (e.g., lyzr_list_traces, lyzr_get_trace_summary, lyzr_ops_get_trace_run), so the decision is left to inference.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_parse_csvB
  3.3/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide minimal safety context (readOnlyHint=false, destructiveHint=false), but the description adds no behavioral detail beyond 'text chunks'. It does not disclose chunking behavior, size limits, how rows or columns are handled, or whether parsing has any side effects. No contradiction with annotations, but the description carries little additional transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence with no filler. It front-loads the action and result, making it easy for an agent to quickly understand the tool's core function. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple parse tool with a fully described schema, the description is adequate but has gaps. It lacks details about what 'text chunks' means, how source_column influences the output, and what the return value looks like. The absence of an output schema makes these details more relevant, but the tool is simple enough that the description is minimally viable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage for all five parameters, including source_column ('Name of the column to use as the source text'). The description does not add parameter-specific meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Parse'), a specific resource ('CSV file'), and an outcome ('text chunks'), clearly distinguishing it from sibling parse tools for PDF, DOCX, TXT, XLSX, PPTX, and images. The title and description align, leaving no ambiguity about what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given on when to use this tool versus alternatives. The sibling list contains many parse_* tools, but the description does not mention why one would choose CSV over XLSX, or how source_column affects usage. There are no prerequisites, exclusions, or alternative tool references.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_parse_pdfB
  3.3/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Although annotations include readOnlyHint=false and destructiveHint=false, the description adds no behavioral context beyond 'text chunks'. It does not disclose whether the operation has side effects, whether results are stored, what the chunking output looks like, or any limitations (e.g., scanned PDFs). The description is purely declarative and does not enhance the annotation-provided safety profile.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no fluff. It is concise and easy to scan, but it is somewhat under-specified for a tool with 10 parameters. Nonetheless, every word is useful, and it is not verbose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the 10 parameters and lack of an output schema, the description is too sparse. It does not explain the structure of the returned chunks, how to choose between file_content_base64 versus S3 source, default chunking behavior, or how this tool relates to KB training tools. An agent would need to infer or inspect the schema to use it effectively.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3. The description itself does not mention any parameters or their semantics, but the schema already documents all 10 parameters with their descriptions. Thus, the description adds no extra value beyond the structured definitions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Parse a PDF file into text chunks' uses a specific verb and resource, clearly indicating the tool's function. It distinguishes itself from sibling parse tools for other formats like docx, csv, xlsx, and image by naming 'PDF file' explicitly.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied by the tool name and description: it is for parsing PDFs. However, there is no explicit guidance on when to use it versus the many other parse tools, nor any mention of prerequisites, such as how to provide the file (base64 vs S3) or when to set parser_config. The description does not prevent misuse but offers minimal direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_rag_source_auth_aci_handoffB
  3.3/5.0
  Behavior1/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation declares readOnlyHint=true, but completing a source-auth handoff callback is an auth-finalizing action that plausibly mutates connection state. The description does not disclose side effects, prerequisites, or what completing the callback entails, and it contradicts the read-only annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, tightly written sentence with no filler. It front-loads the action and resource, making it easy to scan and immediately actionable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with one well-documented parameter, but the description omits critical context such as when to call it in the auth flow, what happens after the callback, and expected return values. The read-only annotation conflict also undermines overall completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides 100% coverage for the single 'state' parameter, describing it as an 'Opaque state token from the auth redirect'. The description merely repeats 'returned state token' without adding extra meaning, format details, or lifecycle context.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Complete') and names the exact resource ('ACI source-auth hand-off callback'), clearly distinguishing this from sibling auth tools like lyzr_rag_source_auth_status and lyzr_rag_source_auth_sharepoint_authorize. It also identifies the key input ('returned state token').

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context: it should be called after an auth redirect returns a state token. However, it does not explicitly state when to use this tool versus the sibling authorize/status tools, nor does it provide exclusions or alternative guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_rai_delete_policyB
  3.3/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already disclose that this tool is destructive (destructiveHint=true) and not read-only (readOnlyHint=false). The description adds no extra behavioral detail, such as irreversibility, effect on dependent resources, permissions needed, or error behavior. It simply restates the destructive action.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence that conveys the action, object, and mechanism without any filler words. It is perfectly concise and front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple delete tool with one parameter and annotations covering its destructive nature. The description is adequate for basic understanding, but it lacks context about the outcome (e.g., success/failure response), prerequisite that the policy must exist, or any consequences of deletion. Given the low complexity, this is acceptable but not fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema coverage, the description's 'by id' clarifies that the sole parameter `policy_id` is the identifier of the guardrail policy. However, it does not elaborate on the format, source, or how to obtain the ID, providing only minimal compensation for the missing schema description.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (Delete), the resource (guardrail policy), and the method (by id). It distinguishes from sibling tools like lyzr_rai_create_policy or lyzr_rai_list_policies by explicitly indicating deletion.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives no explicit guidance on when to use this tool vs alternatives. It does not mention prerequisites, such as obtaining the policy ID from a list/get call, or when to prefer deletion over other operations. The usage is only implied by the verb 'Delete'.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_semantic_model_remove_documentationB
  3.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and readOnlyHint=false, which the description aligns with. The description adds minimal context beyond annotations, such as implying that only documentation is removed and not the table itself, but it does not elaborate on side effects or irreversibility.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise and front-loaded, consisting of a single sentence that directly states the action and target. Every word earns its place, and there is no filler or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple deletion tool with schema and annotations, the description is adequate but leaves gaps. There is no output schema, and the description does not mention whether the operation is synchronous or asynchronous, nor does it clarify that the table itself is not deleted. The async sibling tool further highlights the missing context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with both parameters ('table_name' and 'rag_config_id') already described. The tool description adds no additional meaning or usage details beyond the schema, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('Remove') and resource ('saved documentation for a table'), making its primary purpose clear. It distinguishes from save/get sibling tools but does not differentiate between the synchronous remove and the async 'remove_documentation_task' sibling.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. There is a sibling 'lyzr_semantic_model_remove_documentation_task' that likely handles asynchronous removal, but the description does not mention it or any use-case caveats.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_session_deleteB
  3.3/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and readOnlyHint=false. The description's 'permanently' adds no new behavioral information beyond what the annotations already convey. It does not mention side effects, permissions, or return behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single concise sentence that is front-loaded with the key action and resource. No filler words or redundant details.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter delete with good annotations, the description is minimally adequate. However, it lacks any caveats (e.g., side effects on associated messages/history, required permissions, or return values). The absence of an output schema and a generic sibling set means a bit more context would be helpful.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the single parameter session_id is already described. The description's 'by id' simply echoes the schema. No additional meaning is added.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('delete') and the resource ('session') with scope ('by id'). It also includes 'permanently,' which clarifies the nature of the deletion. This distinguishes it from update/get/stop 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/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No usage context is provided. The description does not mention when to choose this over other session tools (e.g., lyzr_session_update, lyzr_stop_session, or lyzr_session3_delete). There are no alternative recommendations or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_session_historyB
  3.3/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds no behavioral details beyond what the annotations already provide. It says 'Fetch' which is consistent with readOnlyHint and idempotentHint, but it doesn't disclose return format, ordering, pagination, or any other runtime behavior. No contradiction exists, but there is no additional transparency value.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence with no redundant words. It is front-loaded with the verb and object, and every word contributes to the meaning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only fetch with two parameters, the description is minimally adequate. However, it does not specify whether the full message history is returned, if there is any pagination or ordering, or what the response structure looks like, and no output schema is provided.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides 100% coverage with descriptions for both session_id and unix. The tool description adds no parameter-specific meaning beyond what is in the schema, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Fetch') and the resource ('a session's message history'), which is specific and distinct from session management tools like lyzr_session_get or lyzr_session_update. Even among session-history-related siblings, this wording identifies exactly what is returned.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives no guidance on when to use this tool over alternatives such as lyzr_session_history_by_agent or lyzr_session_conversation. There is no mention of preconditions, differences, or exclusions, 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.

• lyzr_session_summaryB
  3.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true and idempotentHint=true, so the agent already knows this is a safe read operation. The description adds no further behavioral traits beyond the action itself, such as what the summary contains or any dependencies. It is consistent with annotations, so no contradiction. With annotations covering the safety profile, this is adequate but adds minimal 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence with no unnecessary words. It is front-loaded and immediately conveys the action and target. This is appropriately concise for such a simple read operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple (1 parameter, no output schema), but the description lacks clarity on what a 'session summary' actually contains or how it differs from other session tools. Without an output schema, the agent is left unaware of the return value's structure or content. This is adequate for a trivial fetch, but the ambiguity among many sibling tools reduces completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides 100% coverage for the single parameter, session_id, described as 'Session id'. The description repeats the concept of a session but doesn't add meaning beyond the schema. Per the baseline rule for high schema coverage, a score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb and resource: 'Fetch a session's summary.' This clearly states what the tool does. However, it doesn't explicitly distinguish it from sibling tools like lyzr_session_conversation or lyzr_session_history, which are also session-related retrievals. The name and title help, but the description alone doesn't disambiguate.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to use this tool versus alternatives. The description only states the action without indicating context, prerequisites, or when a different session tool would be more appropriate. Given the large number of session-related sibling tools, this is a significant omission.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_sharing_share_groupB
  3.3/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description indicates a write operation, consistent with readOnlyHint=false, but adds no information about whether the shared_with list replaces or merges with existing shares, nor about any side effects like removing users not listed. Given annotations already signal mutation, this adds minimal extra 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence of ten words, with no redundant content. It is appropriately brief for the tool's simplicity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple, schema covers all parameters, and annotations cover safety, but the description lacks usage alternatives and behavioral details such as whether the operation is additive or replace-all. This leaves an agent with some uncertainty about exact semantics.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides complete descriptions for both parameters (100% coverage), so the description adds no new parameter semantics. The baseline of 3 applies because the schema carries the burden.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb phrase 'Add or update' with a clear resource ('the users a sharing group is shared with'). This clearly distinguishes it from sibling tools like lyzr_sharing_update_group (which likely updates group metadata) and lyzr_sharing_create_group.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternative sharing tools. It does not mention that this is the tool for modifying the user list specifically, nor does it contrast with update_group or other sharing operations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_start_sessionB
  3.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already indicate this is a non-read-only, non-destructive, idempotent operation. The description adds the nuance of 'resume,' implying it works on existing sessions, but does not disclose what happens if the session_id is invalid, whether a new session is created if none exists, or what the response contains. Minimal added value beyond annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that front-loads the action and includes a useful parenthetical clarification ('or resume'). No wasted words, appropriately sized for a simple tool with one parameter.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with one parameter and has annotations covering safety, but the description leaves key context gaps: whether the session must already exist, how this relates to session creation, and what the return value is. Given the large number of sibling session tools, more clarity on when to use this tool would improve completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 100% coverage, fully describing session_id as 'The session id to start.' The description adds no additional parameter meaning beyond this. Baseline of 3 is appropriate since the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Start (or resume) an inference session.' It uses a specific verb and resource. However, it does not explicitly distinguish this from the many sibling session tools (e.g., lyzr_session_create), leaving slight ambiguity about whether 'start' implies creating a new session or activating an existing one.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given on when to use this tool versus alternatives. The description does not mention that this is for resuming an existing session or when to prefer lyzr_session_create, lyzr_session_get, or lyzr_chat. The user must 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.

• lyzr_stop_sessionB
  3.3/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the structured annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true), the description adds no additional behavioral context. It does not disclose what happens to the session after stopping, whether it can be restarted, whether resources are released, or what the return value is. The 'active' qualifier is a mild pointer but not explicit about behavior for already-stopped sessions.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence, 'Stop an active inference session.', which is concise, front-loaded with the action, and contains zero wasted words. This is appropriately sized for a simple tool with one parameter.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter mutation tool with no output schema, the description is minimally sufficient but lacks details about return values, post-stop state, or any side effects. Given the subject matter complexity and the presence of annotations, a score of 3 is appropriate, as there is a slight gap in fully characterizing the tool's behavior.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully describes the sole parameter session_id as 'The session id to stop', providing 100% schema description coverage. The tool description adds no additional parameter semantics, such as format, example, or further explanation, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action 'Stop' and the target 'active inference session', which is a specific resource. It distinguishes from sibling tools like lyzr_session_delete by the 'active' qualifier and the verb 'Stop', indicating termination of an ongoing process rather than deletion of session 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/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no explicit guidance on when to use this tool versus alternatives such as lyzr_session_delete, lyzr_session_update, or lyzr_start_session. There are no prerequisites, no exclusions, and no mention of when not to use it. The only implied context is that it applies to 'active inference sessions'.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_test_tool_credentialB
  3.3/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=false, openWorldHint=true, and destructiveHint=false, but the description adds minimal behavioral context beyond 'live test.' It does not disclose potential side effects, network interactions, or whether the test modifies credential state. The description does not contradict annotations but also does not meaningfully extend them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, direct sentence that immediately conveys the action and resource. It contains no filler or superfluous details, making it optimally concise.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple (one parameter, no output schema), but the description lacks detail about what a 'live test' returns or whether it has side effects. Given the openWorldHint and lack of output schema, some additional context about expected outcomes would be helpful, though the description is adequate for very basic usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already describes credential_id as 'Tool credential id' with 100% coverage. The description adds no parameter-specific meaning beyond that baseline, so a score of 3 is appropriate per the high schema coverage baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Run a live test of a tool credential' uses a specific action ('Run a live test') and resource ('tool credential'), clearly distinguishing it from CRUD credential tools and status-check tools among the siblings. It is unambiguous about what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does 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 vs alternatives like lyzr_credential_create, lyzr_refresh_tool_credential_status, or lyzr_is_tool_credential_test_supported. It does not mention prerequisites, typical workflow placement, or exclusions, leaving the agent to infer usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_trigger_workflow_with_fileB
  3.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already cover read-only/idempotent/destructive hints, and the description adds the multipart/form-data detail. However, it does not disclose asynchronous behavior, response expectations, or side effects beyond what the annotations imply. No contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, focused sentence that communicates the core purpose without any fluff or redundancy. It is front-loaded with the verb and resource, making it easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has a well-documented schema and useful annotations, but the description does not mention what the API returns or whether the workflow executes synchronously. With no output schema, this missing behavioral information leaves some ambiguity for the agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides 100% coverage with descriptions for all five parameters, so the baseline is 3. The description's mention of 'uploading a file' adds slight context for file_content and file_name, but does not elaborate on parameters like additional_fields beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Trigger a workflow run') and the specific method (uploading a file via multipart/form-data). This distinguishes it from generic execution tools like lyzr_execute_workflow, though it does not explicitly name alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No usage guidance is provided. There is no mention of when to choose this tool over other workflow-triggering siblings, nor any prerequisites or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_update_moduleB
  3.3/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=false and destructiveHint=false, telling the agent this is a mutating but not destructive operation. The description adds no extra behavioral context: it doesn't explain partial-update semantics, whether nulls clear fields, or any side effects. With no additional disclosure, the description falls short of adding value beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single sentence with no filler words. It is appropriately sized for a simple update operation, front-loads the action ('Update existing'), and every word contributes to understanding.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having 24 parameters, no output schema, and minimal schema descriptions, the description provides only a basic purpose statement. It doesn't explain which fields are updatable, how null values are treated, or any required context like the module key. An agent would struggle to use this tool correctly beyond knowing it updates a module.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is only 17% (4 of 24 parameters have descriptions), so the description needed to compensate. It only says 'fields' generically and gives no insight into what any of the 24 parameters mean, how they interact, or which are frequently used. This is inadequate for a parameter-heavy update tool.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Update') and names the exact resource ('sidebar module') and scope ('fields'). This clearly distinguishes it from sibling tools like lyzr_create_module, lyzr_delete_module, and lyzr_get_module_admin.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The word 'existing' implies the module must already be present and that this is for modifications rather than creation. However, there is no explicit guidance about when to use this versus alternative module tools, and no mention of prerequisites like needing a module key or permission.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_world_model_add_personasB
  3.3/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a non-read-only, non-idempotent, non-destructive operation, but the description adds no further behavioral context. It does not explain what happens if a persona already exists, whether the operation is additive, or what side effects might occur despite openWorldHint=true.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence, concise and front-loaded, with no superfluous words. It effectively communicates the core action in a compact form.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple, but the description does not mention return values (no output schema) or potential edge cases such as duplicate names or invalid world_model_id. This is acceptable for a minimal viable description but leaves gaps for an agent expecting more context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage for both parameters (world_model_id and personas). The description itself does not provide additional parameter meaning, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool adds one or more personas to a world model, using the specific verb 'Add' and a direct object. It distinguishes itself from sibling tools like lyzr_world_model_update_persona and lyzr_world_model_delete_persona.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives (e.g., update or delete personas), nor any prerequisites like requiring an existing world model. It lacks contextual recommendations for tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_world_model_add_scenariosB
  3.3/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint=false and destructiveHint=false, but the description adds no additional behavioral context, such as whether scenarios are appended, if duplicates are allowed, or any side effects. The description is minimal and does not go beyond what annotations already convey.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that is concise and front-loaded, stating the core action without unnecessary verbiage. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with two parameters and no output schema. The description plus schema is adequate for basic invocation, but it lacks contextual information about what constitutes a scenario or any constraints. It is minimally complete but does not go beyond the basics.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with descriptions already provided for both 'world_model_id' and 'scenarios'. The tool description adds no extra semantic detail about the parameters, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Add' and the resource 'scenarios to a world model', making the tool's purpose immediately understandable. It also distinguishes itself from sibling tools like lyzr_world_model_list_scenarios, lyzr_world_model_update_scenario, and lyzr_world_model_delete_scenario.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives, such as when to add scenarios as opposed to test cases or personas. It lacks context about prerequisites like the existence of the world model or any exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_world_model_create_evaluation_runB
  3.3/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare the tool is non-read-only and non-idempotent, but the description adds no behavioral details such as whether the run starts immediately, whether it is asynchronous, or how progress is tracked. There is no contradiction with annotations, but no extra transparency value beyond them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that front-loads the verb and resource, contains no filler, and communicates the core purpose immediately.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a creation tool with 14 parameters and no output schema, the description only provides the core purpose and does not mention return values or post-creation monitoring via sibling tools like lyzr_world_model_get_evaluation_run. However, the schema fully documents parameters and annotations clarify the mutating nature, making it minimally adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already documents all 14 parameters and their meanings. The description adds no additional parameter-level context, defaults, or relationships, so the baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Create') and clear resource ('evaluation run') with context ('for an agent against a World Model's test cases'). It distinguishes this creation operation from sibling list/get evaluation run tools and other world model tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives no explicit guidance on when to use this tool versus alternatives like lyzr_create_agent_eval or lyzr_world_model_list_evaluation_runs. The 'for an agent against a World Model's test cases' phrasing implies the use case but does not explain exclusions or follow-up steps.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_world_model_delete_personaB
  3.3/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false. The description adds no additional behavioral context, such as whether the deletion is permanent, what associated data is affected, or how missing IDs are handled. It merely restates the action.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence with no filler or repetition. It conveys the essential action and target efficiently.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  While the tool is simple and annotations provide safety cues, the description omits return-value behavior and edge-case handling (e.g., what happens if the persona or world model does not exist). Without an output schema, this information would be valuable but is not critical for a straightforward deletion.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema documentation covers both parameters (persona_id, world_model_id) with descriptions, achieving 100% schema description coverage. The tool description does not add any extra parameter meaning, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Delete a persona from a world model' clearly states the action (delete) and the specific resource (persona within a world model). It distinguishes this tool from sibling tools like lyzr_world_model_delete (which removes an entire world model) and lyzr_world_model_delete_test_case/scenario.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No usage guidance is provided. The description does not mention when to use this tool versus alternatives (e.g., when to delete a persona versus deleting the entire world model), nor does it state any prerequisites or edge cases such as whether the world model must exist.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_world_model_delete_scenarioB
  3.3/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description provides no behavioral transparency beyond what is already declared in the annotations. While annotations indicate destructiveHint=true and idempotentHint=true, the description does not add any context such as irreversibility, potential cascading effects on related data, permission requirements, or whether the deletion is permanent. It adds nothing beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with zero filler words. It efficiently communicates the core action and target resource. This is appropriately concise for the tool's simplicity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is adequate for a straightforward delete operation with well-specified parameters, but it lacks any mention of expected return values or behavior (e.g., confirmation, error handling). The absence of an output schema makes it unclear what the agent should expect. Additionally, annotations like openWorldHint=true are not explained, leaving some contextual gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% parameter description coverage, with clear descriptions like 'The scenario id to delete' and 'The world model id'. The description does not add any additional semantic meaning to the parameters, but since the schema fully documents them, a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Delete a scenario from a world model' uses a specific verb (delete) and resource (scenario) with clear container (world model). It clearly distinguishes from sibling tools like lyzr_world_model_delete_persona, lyzr_world_model_delete_test_case, and lyzr_world_model_delete by specifying the exact object type being deleted.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No usage guidance is provided. The description only states what the tool does without indicating when to use it, when not to use it, or any prerequisites. It does not reference alternatives such as deleting the entire world model versus a single scenario, nor does it mention that the scenario must exist or belong to the specified world model.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_chatB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already indicate this is a state-changing, non-idempotent call (readOnlyHint=false, idempotentHint=false). The description adds no additional behavioral context, such as the fact that it will persist conversation history or that it is a blocking call expecting a single response. This is acceptable because annotations cover the safety profile, but the description itself contributes little.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single 10-word sentence that is front-loaded with the action and outcome. Every word earns its place with no wasted content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple request/response chat tool with 4 well-described parameters and clear annotations, the description is largely complete. It could be slightly enhanced by noting non-streaming behavior or referencing session_id for multi-turn continuity, but these are already captured in the schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All four parameters (message, user_id, agent_id, session_id) are fully described in the input schema with clear descriptions, so the schema handles parameter semantics. The tool description contributes no additional parameter context, meeting the baseline for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Send' with the resource 'Lyzr agent' and outcome 'get its response,' making the core function clear. However, it does not differentiate from sibling chat tools like lyzr_stream_chat or lyzr_chat_with_file, so it stops short of a 5.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to choose this tool over alternatives such as lyzr_stream_chat (streaming) or lyzr_chat_with_file. There are no exclusions, prerequisites, or use-case hints, leaving the agent to infer appropriateness.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_create_mcp_serverB
  3.4/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already cover readOnlyHint=true (write operation), destructiveHint=false, and idempotentHint=false. The description adds minimal behavioral context beyond that—only the auth type list, which is already in the schema. It does not mention side effects, required permissions, or post-registration steps.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence containing no filler. Every word contributes to understanding the tool's purpose and scope.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a create tool with a nested config object and no output schema, yet the description does not explain what happens on success (e.g., returned server ID), whether OAuth requires a follow-up flow, or how standard_server_id fits. For an agent to use this tool correctly, more context is needed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so parameters are well-documented. The description only restates the auth_type options and provides no extra meaning beyond what the schema already says. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb (Register) and resource (MCP server), and even enumerates supported auth types (no-auth, api_key, oauth). This clearly distinguishes it from sibling create tools like lyzr_create_agent or lyzr_create_workflow.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage (when you need to add a new MCP server) but provides no explicit when-to-use guidance or alternatives. It does not mention related lifecycle steps like OAuth initiation or listing/deleting servers, so context is clear but exclusions are absent.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_delete_composio_auth_configB
  3.4/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate destructive (destructiveHint: true), not read-only (readOnlyHint: false), and idempotent (idempotentHint: true). The description adds no additional behavioral context such as side effects, irreversibility, or dependency impacts. It simply restates the action.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence that conveys the operation without any redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter delete tool with strong annotations (destructive, idempotent), the description and schema together provide adequate information. However, no mention of consequences for dependent connections or return values slightly limits completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The single parameter provider_id is already fully described in the schema ('Composio provider id') with 100% coverage. The description does not add extra meaning, but the basic meaning is sufficiently clear.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Delete'), identifies the resource ('Composio auth config'), and scopes it 'for a provider'. This clearly distinguishes it from sibling tools like lyzr_delete_composio_connection or lyzr_create_composio_auth_config.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives no guidance on when to use this tool versus alternatives such as lyzr_delete_composio_connection or lyzr_get_composio_auth_config. It does not mention any exclusions, prerequisites, or preferred contexts.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_delete_tool_credentialB
  3.4/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already convey destructive and idempotent behavior; the description adds no additional context such as permanence, side effects, or permissions. It merely restates the action.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence with no fluff, earning the highest score for conciseness.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple single-parameter delete operation with strong annotations, the description is largely sufficient, but it omits any details about return values or consequences (e.g., whether it rejects in-use credentials). Slightly more context would improve completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already fully describes the only parameter (credential_id) with 100% coverage. The description's 'by id' adds no new semantic information beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (delete), the resource (tool credential), and the unique identifier (by id), which distinguishes it from bulk or other credential 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/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives like bulk_delete_tool_credentials or when a credential id is required. It implies the use case but does not explicitly state prerequisites or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_agent_eval_result_by_agentB
  3.4/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. However, the description adds no behavioral context beyond that, such as what the returned results look like, whether they are aggregated, or error behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is one short sentence that front-loads the action and resource. No unnecessary words or repetition exist; it is appropriately concise for a single-parameter read operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity, the schema's full param coverage, and strong annotations (read-only, idempotent, non-destructive), the description is largely complete. It could benefit from clarifying what 'evaluation results' includes or how this relates to sibling eval tools, but it is sufficient for basic invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage with a single parameter (agent_id) described as 'Agent id whose eval results to fetch'. The description's 'given agent id' merely echoes the schema without adding any additional semantic detail, so the baseline score of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get'), resource ('agent evaluation results'), and scope ('for a given agent id'), making the tool's function immediately clear. It distinguishes itself from generic eval tools by explicitly keying on agent id.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives such as lyzr_get_agent_eval_result or lyzr_get_agent_eval. No mention of prerequisites, context, or exclusions is given.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_agent_versionB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds no additional behavioral context, such as what happens if the version is not found, whether authorization is needed, or what the response contains. With annotations covering the core safety traits, a baseline score of 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence, 'Fetch a specific version of an agent,' with no unnecessary words. Every word contributes to the meaning. It is appropriately concise for a simple retrieval operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with two well-documented parameters and strong annotations (read-only, idempotent, non-destructive), the description is nearly complete. It could mention that the tool returns version data or that the version must belong to the given agent, but the operation is straightforward and the schema covers parameters. The lack of an output schema is compensated by the clarity of the operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage: both agent_id and version_id have descriptions ('The agent_id' and 'The version_id to fetch'). The description adds no extra meaning beyond what the schema provides. Baseline is 3 when schema coverage is high, so no additional credit is warranted.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Fetch a specific version of an agent' clearly states a fetch operation and distinguishes it from sibling tools like lyzr_get_agent (fetch the agent itself) and lyzr_list_agent_versions (list versions). The verb 'fetch' and the noun 'specific version' are precise, though it could be slightly more explicit about returning version 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/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to use this tool versus alternatives. The description does not mention that to list all versions one should use lyzr_list_agent_versions, or that this tool is meant for retrieving a single version by ID. No prerequisites, exclusions, or alternative tool references are provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_all_toolsB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, and the description's 'List' is consistent. It adds the 'across providers' scope, but doesn't disclose return format, pagination, or any other behavioral traits; this is adequate but not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence, 'List all tools available across providers,' which is front-loaded and contains no unnecessary words. It earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter read-only operation, the description is minimally adequate, but the lack of output schema and the existence of many sibling list tools create ambiguity about the exact return value and scope. It doesn't fully clarify how 'all tools' differs from lyzr_list_tools or lyzr_list_all_user_tools.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has zero properties, so parameter semantics are trivially covered by the schema. Per the rubric, 0 parameters yields a baseline of 4, and the description doesn't need to add parameter details.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'List all tools available across providers' uses a specific verb ('List') and identifies the resource and scope ('all tools across providers'). It is clear but doesn't explicitly distinguish from sibling tools like lyzr_list_tools or lyzr_list_all_user_tools, so it falls short of a 5.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No usage guidance is provided. The description doesn't mention when to choose this tool over alternative listing tools such as lyzr_list_tools, lyzr_list_org_agents, or lyzr_list_all_user_tools, which is a significant gap given the large sibling list.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_provider_credentialB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, covering the safety and side-effect profile. The description adds no additional behavioral context beyond 'fetch by id' (e.g., error behavior, return format, decryption), but the bar is lower given the strong annotation coverage and the simplicity of a read-only get.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that is immediately understandable and front-loaded with the verb. No wasted words, and for a simple get-by-id tool, this length is appropriate.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is extremely simple, with one well-documented parameter and annotations that convey read-only, idempotent behavior. The description sufficiently communicates the core operation, though it could optionally mention that this specifically targets provider credentials (as opposed to other credential types) given the large sibling tool list. No output schema exists, but for a basic fetch, the contract is adequately complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% because the only parameter 'credential_id' has a clear description. The description's 'by id' phrase adds no new information beyond the schema's 'The credential id to fetch', so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (Fetch) and the resource (provider credential) with the key qualifier 'by id'. This distinguishes it from list-type siblings like lyzr_list_provider_credentials_by_type, but it doesn't explicitly differentiate from similar getters like lyzr_credential_get, leaving slight ambiguity about the credential resource type.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided about when to use this tool versus alternatives such as lyzr_credential_get or list functions. It does not mention any exclusions, prerequisites, or preferred context, so the agent must infer usage solely from the name and description.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_trace_ganttB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds a small amount of context by explaining that the Gantt chart is a 'span tree with timings,' but it does not disclose additional behavioral details such as pagination, response structure, or error conditions. This is adequate but not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that front-loads the core purpose. It contains no filler or redundant phrasing, making every word count.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with one parameter and no output schema, the description provides enough context about what is returned ('span tree with timings') and the target resource ('a trace'). It is not overly verbose but could benefit from a brief note on why/when to use it, though this is not critical given the simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% since trace_id is described as 'Trace id.' The description references 'a trace' but adds no new meaning beyond the schema parameter. The baseline of 3 is appropriate when the schema handles parameter documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Fetch') and a specific resource ('Gantt chart (span tree with timings) for a trace'), clearly conveying what the tool does. It does not explicitly contrast with sibling tools like lyzr_get_trace_details or lyzr_get_trace_summary, so it falls short of full differentiation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives such as lyzr_get_trace_details, lyzr_get_trace_summary, or lyzr_ops_get_trace. The description simply states what it does without any context, exclusions, or alternative recommendations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_git_get_statusB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) already cover the safety profile, lowering the burden on the description. However, the description adds no extra behavioral context such as what information the status includes (e.g., branch, staged/unstaged changes) or the return format. It is not contradictory, so a 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that is front-loaded and contains no filler. It is appropriately sized for the simplicity of the tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple (one required parameter, no output schema, strong annotations). The description is adequate for a well-known git operation, but since no output schema exists, the description could have explained what the returned status contains. Still, the overall context is sufficient 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.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% for the only parameter, agent_id, which is sufficiently documented in the schema. The description adds no additional parameter information, so the baseline of 3 per the rubric applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does 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 ('current git status for an agent's repo'), which is specific and distinguishes it from sibling git tools like list commits or list branches. However, it does not explicitly name any alternative tools, so it falls short of the 5-point bar.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives, nor any context about prerequisites or typical scenarios. The sibling list includes many git-related tools, but the description gives no hints on how to choose among them.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_is_tool_credential_test_supportedB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing this as a safe read operation. The description adds the specific behavior that it checks whether test invocation is supported, which is consistent with the read-only nature. No additional behavioral details are given, but none are contradicted.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that immediately conveys the function. It contains no filler words or redundancy, making it highly efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only check with one well-documented parameter, the description covers the essential purpose. However, since there is no output schema, the description could have clarified the return value (e.g., a boolean) but the title and wording strongly imply a yes/no result, so the gap is minor.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides a description for the single parameter 'credential_id' (100% coverage), so the baseline is 3. The tool description does not add any extra semantics about the parameter, such as how to obtain the ID or any format constraints.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Check whether' with the resource 'tool credential' and the aspect 'supports test invocation'. It clearly states the tool's function and is distinct from the sibling 'lyzr_test_tool_credential' by implying a capability check rather than an execution, but it does not explicitly name the alternative, so it falls short of full sibling differentiation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives such as 'lyzr_test_tool_credential'. There is no mention of prerequisites, context, or exclusions. The only hint is the tool name itself, which is insufficient.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kb_resetB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description adds the scope of the destructive action ('all documents'), but does not provide extra behavioral context such as irreversibility, whether the knowledge base remains, or any side effects. No contradiction with annotations 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence, front-loaded with the action, and contains no filler or redundant information. It earns its place without being verbose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple, one-parameter destructive tool with complete schema coverage and annotations indicating destructive behavior, the description is largely sufficient for an agent to select and invoke it. A short note about permanence or that the KB itself is not deleted would make it fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage for the single parameter rag_id, described as 'Knowledge base id'. The description adds no additional parameter-level meaning, but also does not need to compensate for schema gaps.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb and resource: 'Clear all documents from a knowledge base.' This clearly indicates the action and scope, distinguishing it from sibling tools like deleting individual documents or deleting the whole knowledge base. However, it does not explicitly name alternatives, so it falls short of a 5.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives like lyzr_kb_delete_docs, lyzr_kb_bulk_delete, or lyzr_kb_delete. There is no mention of prerequisites, context, or warnings about destructive consequences.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kb_sync_cc_pairs_list_attemptsB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. The description adds minor clarity by defining 'attempts' as 'sync runs', but does not disclose additional behavior such as pagination order or default response format.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One concise sentence that is front-loaded with the action and resource. No filler words or redundancy; every part contributes to defining the tool's function.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple list operation, 3 parameters, and read-only annotations, the description is adequate. It does not explain what data is returned or ordering, but the schema covers limit/offset and the tool name clarifies the resource. Minor gap: no note on attempt status or typical usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage for all parameters with descriptions. The tool description adds nothing beyond the schema, so the baseline of 3 applies as the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('List') and resource ('index attempts (sync runs)') for a connector-credential pair. It distinguishes from sibling list tools like 'lyzr_kb_sync_cc_pairs_list' by specifying 'index attempts', though it could more explicitly contrast with 'get_attempt'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives like 'lyzr_kb_sync_cc_pairs_get_attempt' or when to set limit/offset. The description simply restates the action without context on filtering or use cases.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kb_sync_cc_pairs_statusB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already establish this as a safe read operation (readOnlyHint=true, idempotentHint=true), so the bar is lower. The description adds value by disclosing that the response includes both the active and last completed index attempts, which is beyond the schema. However, it doesn't detail status fields, error behavior, or edge cases like missing attempts, so it adds only modest 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence with no filler, front-loaded with the verb 'Get' followed immediately by the resource and scope. Every word contributes meaning, and it doesn't repeat the title or the annotations.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter, read-only status tool with strong annotations and full schema coverage, the description is largely sufficient: it states the purpose and previews the return content (active and last completed attempts). Without an output schema, a bit more detail about the returned status structure would strengthen it, but the essential semantics are covered.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage for the single parameter is 100% — cc_pair_id is already described as 'The connector-credential pair id'. With high schema coverage, the baseline is 3, and the description's mention of 'connector-credential pair' merely mirrors the schema without adding format details, constraints, or guidance on how to obtain the ID (e.g., via the list tool).

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') with a clear resource ('current sync status for a connector-credential pair') and specifies the scope ('including its active and last completed index attempts'). It distinguishes from siblings like lyzr_kb_sync_cc_pairs_get and lyzr_kb_sync_cc_pairs_list_attempts by focusing on the aggregated status view, though it doesn't explicitly name those alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus closely related siblings such as lyzr_kb_sync_cc_pairs_get, lyzr_kb_sync_cc_pairs_list_attempts, or lyzr_kb_sync_cc_pairs_list. It states what the tool does but offers no context for selection, no exclusions, and no prerequisites.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kb_sync_cc_pairs_syncB
  3.4/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate readOnlyHint=false and idempotentHint=false, so the tool is known to be a non-idempotent, mutating operation. The description adds no new behavioral context, such as that the sync may run asynchronously or that it returns a run identifier; it only restates the core action without disclosing side effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence that directly states the purpose. It is appropriately sized, with no filler or unnecessary detail, and is easy to parse quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is a simple trigger with one parameter and no output schema. However, the description does not explain what the caller should expect after triggering, such as whether a sync attempt ID is returned or how to monitor progress. This missing return/outcome information leaves the agent without critical contextual completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema has 100% coverage with a single required parameter cc_pair_id, fully described as 'The connector-credential pair id'. The description adds no additional parameter meaning, but baseline 3 applies since the schema handles parameter documentation completely.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Trigger a sync run for a connector-credential pair' clearly states the action (trigger) and the resource (a sync run for a connector-credential pair). It distinguishes itself from sibling tools like pause, resume, and status by emphasizing the sync trigger action.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is used to start a sync for a given pair, but it does not explicitly state when to use this tool versus alternatives like checking status or listing attempts. No exclusions or alternative pointers are provided beyond the basic action.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kbsync_connector_createB
  3.4/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds no behavioral context beyond what annotations already provide—it does not mention required credentials, response format, or side effects. The non-readonly and non-destructive traits are already captured by annotations, so the description contributes little additional transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence, front-loaded with the action and resource, with no filler or redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a create tool with a heterogeneous connector_specific_config and no output schema, the description is too sparse. It omits critical context like prerequisite credentials, source-specific configuration requirements, and expected return value, leaving the agent under-informed for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all three parameters (name, source, connector_specific_config) are already documented. The description adds no extra semantics, which is acceptable given the schema coverage, but it does not clarify the dynamic nature of connector_specific_config.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('Create a new KB Sync connector') and resource ('KB Sync connector') with a clear scope ('for a document source'). This clearly distinguishes it from sibling operations like get/update/delete/list for the same resource.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied by the verb 'Create' and the resource type, but there is no explicit guidance on when to use this tool vs alternatives like lyzr_livesource_add, or on prerequisites such as creating credentials first. No exclusions or alternative tool mentions are included.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kb_sync_validate_site_accessB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide idempotent and non-destructive hints, but the readOnlyHint is false, which is ambiguous for a validation tool. The description adds the deprecation flag but does not disclose return values, side effects, or error behavior, leaving gaps beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence with the deprecation warning front-loaded. It is appropriately sized and every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the tool description must explain what the agent can expect in return, but it does not. It also lacks any note about what to use instead (given deprecation) and does not clarify whether validation is per-URL or overall, making the description incomplete for practical invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Both parameters are described in the schema with 100% coverage, so a baseline of 3 is appropriate. The description only paraphrases 'credential' and 'site/drive URLs' and adds no additional format, constraints, or parameter-specific guidance.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose with a specific verb ('Validate'), a resource ('SharePoint site/drive URLs'), and a credential scope. It also flags the tool as deprecated, which helps an agent distinguish it from current alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives no guidance on when to use this tool versus the many related sibling tools (e.g., lyzr_kb_sync_browse_sites, lyzr_livesource_ext_validate_access). Despite deprecation, no alternative tool is suggested; the agent is left without usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kb_train_documentsB
  3.4/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds no behavioral detail beyond the annotations. It does not mention whether training appends/overwrites, whether processing is synchronous or asynchronous, or any prerequisites or side effects. Given readOnlyHint is false, the write nature is already annotated, but the description fails to provide additional context for this 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise, consisting of two short sentences that front-load the action and resource. There is no wasted text or redundant repetition of schema information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool appears among a large family of KB training tools, but the description does not explain how this fits or when to choose it over others. It also lacks information about return values or processing behavior, and the absence of an output schema leaves a significant gap for a write operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides 100% coverage for both parameters. The description adds modest value by stating documents are 'free-form objects', which clarifies the flexible structure of the array items beyond the schema's empty object definition. No extra semantics for rag_id are provided.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool ingests an array of document objects into a knowledge base, using a specific verb ('Ingest') and resource ('knowledge base'). The mention of 'each document is a free-form object' distinguishes it from sibling tools that handle specific formats like text, website, or PDFs.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for general document arrays but does not explicitly state when to prefer this over siblings like lyzr_kb_train_text or lyzr_kb_train_pdf. No exclusions or alternative tool references are provided, making the guidance implicit rather than explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kb_train_imageB
  3.4/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate this is a write operation (readOnlyHint=false). The description adds no additional behavioral context, such as side effects, processing specifics (e.g., OCR), or constraints. It essentially restates the title without new information.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no redundant or irrelevant content. It communicates the core purpose efficiently.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having 8 parameters and no output schema, the description provides minimal operational context. It does not mention prerequisites (e.g., an existing RAG ID), expected return values, or how image training behaves differently from other training tools, leaving significant gaps for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema descriptions cover 100% of the 8 parameters, clearly explaining each field. The tool description adds no parameter-level semantics beyond what the schema already provides, so the baseline score of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('upload and train') and the resource ('image file into a knowledge base'). The qualifier 'image' distinguishes it from sibling training tools for other file types (PDF, DOCX, text, etc.).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The usage is implied by the name and description (for image files), but there is no explicit guidance on when to use this tool versus alternatives like lyzr_kb_train_text or lyzr_kb_train_documents. No exclusions or alternative recommendations are provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_list_agentsB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds the API key scope constraint, which is useful, but it does not disclose return format, pagination, or other behavioral details. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence with no filler. It is appropriately front-loaded and every word contributes to the meaning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (no params, no output schema) and strong annotations, the description is adequate but leaves gaps: it does not clarify differences from lyzr_list_org_agents or describe the response shape. It is usable but not fully self-sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and the schema is empty, so there is nothing for the description to explain. The description correctly focuses on the operation rather than parameter details, earning a baseline score of 4 for a parameterless tool.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'List' and resource 'agents available to your Lyzr API key', clearly indicating a read operation. However, it does not distinguish from the sibling tool lyzr_list_org_agents, which may list org-wide agents, leaving potential ambiguity about scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to use this tool versus alternatives like lyzr_list_org_agents or lyzr_get_agent. The phrase 'available to your API key' implies personal scope, but no explicit exclusions or comparisons are provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_list_all_channelsB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the scope ('every channel configuration') but no additional behavioral details such as pagination, return format, or whether filtering is available. The bar is lower due to annotations, and the description adds a bit of value.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence, front-loaded with the verb, and contains no filler or redundant content. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter read-only tool, the description is mostly adequate, but the existence of the sibling lyzr_list_channels creates ambiguity that the description does not resolve. There is no output schema, so the return format is undisclosed, which slightly reduces completeness for an agent needing to know what to expect.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, and schema description coverage is trivially 100%. With no parameters to explain, the baseline for parameter semantics is 4, and the description rightly stays silent on them.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'List' with the resource 'channel configuration' and the qualifier 'every' to indicate an all-encompassing operation. It is clear and distinct from create/delete channel tools, though it doesn't explicitly differentiate from the similarly named sibling lyzr_list_channels.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. A sibling tool named lyzr_list_channels exists, and the description gives no context for choosing between 'list all channels' and 'list channels', nor any exclusions or prerequisites.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_list_my_audit_logsB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds the scope constraint 'current authenticated user' and mentions optional filters, which provides some behavioral context beyond the annotations. However, it does not disclose return format, pagination, or other limitations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that front-loads the verb and resource. Every word earns its place, with no redundant or filler content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description could have explained the return format or typical usage. It also fails to provide context for choosing this tool among the many audit-related siblings. Despite having well-documented parameters, the overall description leaves the agent without crucial context for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3. The description's mention of 'optional filters' adds no specific meaning beyond the schema, as each parameter already has a clear description. There is no additional semantic augmentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does 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 'audit logs', with a specific scope 'for the current authenticated user'. This distinguishes it from sibling audit tools like lyzr_list_org_audit_logs, which operate at the org level, and lyzr_list_user_audit_logs, which may refer to other users.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus the many audit-related siblings (e.g., lyzr_list_org_audit_logs, lyzr_list_resource_audit_logs, lyzr_get_audit_log). The description lacks any mention of alternatives or exclusions, leaving the agent to guess which scope is intended.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_list_provider_credentials_by_typeB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds only the 'all credentials' and provider-type scoping, which is partially purpose rather than behavioral disclosure; no details on response format or filtering behavior beyond that.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single sentence of nine words conveys the complete operation. It is front-loaded with the verb and resource, and there is no filler or redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list tool with one well-described parameter and strong annotations, the description is adequate for selection and invocation. It lacks a description of the return shape, which is a minor gap since no output schema is present, but it does not impede basic usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the provider_type parameter already has a description. The tool description merely restates the same meaning without adding value about parameter format, allowed values, or examples.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists all credentials filtered by provider type, using a specific verb and resource. It is almost a restatement of the title, but the 'given provider type' scope helps distinguish it from siblings like lyzr_list_provider_credentials_by_user, though no sibling is explicitly named.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to choose this tool over alternatives such as lyzr_credential_list or lyzr_list_provider_credentials_by_user. It does not state prerequisites, exclusions, or when-not-to-use conditions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_livesource_ext_webhook_getB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds the 'validation handshake' context, clarifying this is a verification step rather than a data operation. It does not contradict annotations, but adds limited detail beyond what annotations provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no wasted words. It directly states the tool's function in a compact and efficient manner.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a no-parameter tool with no output schema, the description provides the essential purpose, but it lacks context about how this relates to sibling webhook tools and what the handshake involves. It could be improved by noting when this is called or how it differs from the POST counterpart.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and schema coverage is 100%, so the description has no parameter burden. Baseline 4 applies because there are no parameters to explain; the schema and lack of inputs are sufficient.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('validation handshake') and resource ('webhook subscription'), clearly identifying the tool's purpose. It distinguishes from the sibling 'lyzr_livesource_ext_webhook_post' by implying a setup/verification role, though it does not explicitly name the alternative.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives no guidance on when to use this tool versus alternatives such as 'lyzr_livesource_ext_webhook_post' or 'lyzr_kb_sync_webhook_validation'. It lacks context about prerequisites, invocation order, or typical scenarios.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_ops_get_trace_runB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. The description adds minimal context beyond the annotations, such as that it fetches a specific run, but does not disclose return format, pagination, or other behavioral details. With annotations present, a score of 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence with no redundant words, front-loaded with the verb 'Fetch'. It is highly concise and efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with two well-described parameters and no output schema, the description is mostly complete. However, it could benefit from explaining what a 'run' is or how trace_id and run_id relate, especially given the large number of trace-related sibling tools. Slight gap but generally adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides 100% coverage of the two parameters with descriptions 'Run id' and 'Trace id'. The description does not add additional meaning about parameter relationships, formats, or constraints. Baseline 3 is appropriate since the schema already documents the parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Fetch') and identifies the resource ('a specific run within a trace'), making the action clear. It is somewhat distinguishable from sibling tools like lyzr_get_trace_summary or lyzr_get_trace_details, but it does not explicitly compare against these alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided about when to use this tool versus other trace-related tools. There is no mention of use cases, prerequisites, or when to prefer an alternative like lyzr_ops_get_trace or lyzr_get_trace_details.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_parse_textB
  3.4/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate readOnlyHint=false, meaning the tool may have side effects, but the description does not clarify what side effects occur or whether the chunks are simply returned. It adds only the 'no knowledge base required' qualifier, which is a prerequisite hint rather than a behavioral disclosure. Output structure and state changes are unaddressed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence, front-loaded with the primary action and outcome, and efficiently communicates that no knowledge base is required. No redundant or verbose content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Although the schema fully documents parameters, there is no output schema and the description fails to specify the return structure or any side effects. An agent selecting this tool would know it parses text but not whether the result is a list, string, or objects, nor whether it writes anything. Given the annotations leave side effects ambiguous (readOnlyHint=false), this is a notable gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage, so the baseline is 3. The description adds minimal parameter insight; 'raw text' aligns with the 'text' parameter but does not elaborate on chunk_size, extra_info, or extra_fields. No additional semantic value beyond the schema is provided.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states a specific verb ('Parse'), resource ('raw text'), and outcome ('into chunks'), and adds a discriminative qualifier ('no knowledge base required') that distinguishes it from KB-based operations. Among sibling parse tools for files and websites, 'raw text' implies a direct text input, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage guidance is only implied via the qualifier 'no knowledge base required', which suggests use for one-off or lightweight parsing without needing a KB. However, it does not explicitly name alternatives like lyzr_parse_txt or lyzr_kb_train_text, nor does it state when not to use it, so the guidance remains suggestive rather than explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_parse_xlsxB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds the behavioral detail that the output consists of 'text chunks', which complements the annotations. However, it does not disclose other traits such as handling of multiple sheets, formula evaluation, or potential side effects. Annotations (readOnlyHint: false, openWorldHint: true) already signal uncertainty, but the description does not provide additional clarity, so it meets the baseline for annotation-backed definitions.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that immediately conveys the tool's purpose. It has no filler or redundant details, making it highly efficient for an agent to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given there is no output schema and moderate complexity from chunking parameters, the description is inadequate. It does not clarify how Excel files are converted (e.g., per-sheet, per-row), what 'text chunks' means in practice, or how chunk_size/chunk_overlap affect results. The tool's behavior remains underspecified for an agent to invoke it confidently without guesswork.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter (e.g., file_content_base64, filename, chunk_size, chunk_overlap) already documented. The description adds minimal meaning beyond what the schema provides, only implying that file content is parsed into chunks. This aligns with the baseline of 3 for high-coverage schemas.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool's function: parsing an XLSX (Excel) file into text chunks. It uses a specific verb ('Parse') and resource ('XLSX file'), and the output format ('text chunks') is explicitly stated. This distinguishes it from sibling parsing tools like lyzr_parse_pdf or lyzr_parse_csv by file type.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance is provided on when to use this tool versus alternative parsers. While the name and description imply it is for XLSX files, there is no mention of exclusions (e.g., 'for other formats, use lyzr_parse_csv') or prerequisites. An agent must infer usage from the file extension, which is weak guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_rag_source_auth_statusB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds context about external sources configured for a knowledge base but does not disclose status values, failure behavior, or prerequisites beyond that. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, front-loaded sentence with no extraneous detail. Every word contributes to identifying the action and target.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with one parameter and safe annotations, the description adequately conveys the core function. It does not explain return values, but no output schema exists and the complexity is low, making this acceptable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for rag_id, which is described as 'Knowledge base id'. The description adds no additional parameter meaning, but the schema already provides sufficient semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Get' and the specific resource: connection/auth status of external data sources for a knowledge base. It does not explicitly compare with sibling auth tools, but the status-vs-action distinction is implicit.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives such as lyzr_rag_source_auth_sharepoint_authorize or lyzr_rag_get_doc_content. There is no when-to-use context or exclusionary information.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_run_usage_alertsB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already establish this as a non-read-only, non-idempotent, open-world action. The description adds context about running server-side and requiring an optional server token, which is useful auth information. However, it does not disclose side effects, asynchronicity, or response behavior beyond annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is exactly two sentences, front-loaded with the primary action and a single parameter note. No filler or redundant phrasing; each sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description should explain what the agent can expect after triggering the pass—whether it returns results, runs asynchronously, or produces side effects. This is missing, making the tool's runtime behavior unclear.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3. The description restates the optional server token header but adds little beyond the schema's own parameter description. No format, source, or examples are given to enrich the parameter's meaning.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Trigger') and the specific resource ('a usage alert evaluation pass on the server'), making the tool's purpose unambiguous. It is distinct from the many sibling usage/report tools, even though it does not name them explicitly.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives like lyzr_report_usage_by_model or lyzr_ops_get_dashboard. It only mentions an optional header, not selection criteria or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_schedule_pauseB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=false, openWorldHint=true, and idempotentHint=true, and the description does not contradict them. However, the description adds no extra context about what pausing entails (e.g., whether in-flight runs are stopped, whether the schedule can be resumed). Given annotation coverage, 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The entire description is a single short sentence with no wasted words. It is perfectly concise and front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple (one parameter, no output schema) and annotations cover key behavioral traits, so the minimal description is not completely inadequate. However, it omits useful context like how to resume a paused schedule and what happens to scheduled executions, making it only minimally viable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has one parameter, schedule_id, with 0% description coverage. The description doesn't explain what schedule_id refers to, how to obtain it, or its format. Since schema coverage is low, the description should compensate but doesn't, leaving the parameter's semantics solely to its name.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Pause a schedule.' clearly states the action (pause) and the resource (schedule) with a specific verb, and it differentiates from siblings like 'lyzr_schedule_resume' and 'lyzr_schedule_delete'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. It doesn't mention that resuming requires lyzr_schedule_resume, nor does it describe scenarios or effects. This is purely a statement of the action.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_session3_createB
  3.4/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate a write operation (readOnlyHint false) and openWorldHint true, but the description adds no additional behavioral context. It does not mention side effects, persistence, response behavior, or any requirements beyond the schema, and does not clarify the implications of openWorldHint.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no redundant wording. It communicates the essential purpose efficiently, earning a 5 for conciseness.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the absence of an output schema and the presence of openWorldHint true, the description should clarify what the tool returns or what side effects occur, but it does not. It also fails to guide an agent in choosing among the many session-related sibling tools, leaving important gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema descriptions cover 100% of parameters, including the optionality of agent_id. The description's phrase 'optionally tied to an agent' merely reiterates schema information without adding new meaning, so the baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Create') and identifies the resource ('a new v3 session'), clearly distinguishing it from the sibling tool lyzr_session_create_by_agent by noting the optional agent association. The 'v3' designation also separates it from lyzr_session_create.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for creating v3 sessions, optionally tied to an agent, but does not explicitly state when to choose this over lyzr_session_create or lyzr_session_create_for_agent. No exclusions or alternative recommendations are provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_session_getB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds no extra behavioral context (e.g., not-found behavior, timeout semantics, return format) beyond the basic fetch operation, which is consistent with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, short sentence that is immediately understandable. No filler or redundancy; every word is necessary. It is appropriately sized for a simple get operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple get-by-id tool with strong annotations and fully described parameters, the description is mostly complete. However, it does not explicitly mention what a 'session' refers to in this context (e.g., legacy vs. session3) or describe the return value, but the output schema is absent, so the agent must infer the response shape from the operation name.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both session_id and timeout having descriptions in the schema. The description itself adds no parameter-level meaning, so it relies on the schema to convey semantics. This matches the baseline for good schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Fetch a session by id' clearly states the verb (fetch), resource (session), and scope (by id). It does not explicitly differentiate from sibling tools like lyzr_session3_get or lyzr_session_history, but the name and 'by id' make the intended operation clear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives such as lyzr_session_history or lyzr_session3_get. There is no mention of when to use or when not to use, 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.

• lyzr_session_history_by_agentB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description only needs to add context. It adds that this returns message history, which is useful, but does not disclose details such as ordering, pagination, or exact return format. The description is consistent with annotations, with no contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler or unnecessary words. Every word contributes meaning, making it highly concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple read-only tool, full parameter documentation, and strong annotations, the description is largely complete. It states what is returned (message history) and the scope (specific agent), though it could have clarified differences from sibling session history tools given the large sibling set and absence of an output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with all three parameters (unix, agent_id, session_id) already described in the schema. The description adds no extra semantic meaning beyond the schema, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Fetch' and clearly identifies the resource as 'a session's message history for a specific agent.' This distinguishes it from the generic sibling lyzr_session_history by adding the agent qualifier, though it does not explicitly name that alternative.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus similar siblings like lyzr_session_history, lyzr_session_conversation, or lyzr_session_get. It does not state prerequisites, exclusions, or suggest alternatives, leaving the agent to infer context from the name alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_sharing_get_groupB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds no extra behavioral context (e.g., what happens if the group is not found, whether partial results are returned). It aligns with the annotations and is adequate for a simple fetch.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that wastes no words. It is appropriately sized for a minimal read operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter, read-only fetch tool with full schema coverage, the description is essentially complete. No output schema exists, but the tool's purpose is self-evident from name and description. Minor gaps like return format or not-found behavior are not critical for this simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with the parameter 'group_id' described as 'Sharing group id'. The description's 'by id' adds no additional meaning beyond the schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Fetch a sharing group by id' clearly states the action (fetch) and resource (sharing group) with a specific lookup method (by id). It is distinct from list-type siblings, though it does not explicitly differentiate itself from similar get operations like lyzr_sharing_get_resource_groups.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives such as lyzr_sharing_list_groups or lyzr_sharing_get_resource_groups. The only implied context is that a group_id is needed, which is already evident from the schema.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_update_a2a_agentB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare this as non-read-only, non-destructive, and idempotent, which covers basic behavioral traits. The description itself adds no additional context about partial vs. full updates, handling of unspecified fields, or external side effects, but it does not contradict the annotations either.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence with no fluff. It is front-loaded and concise, which is appropriate for an action-oriented tool even with many parameters.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 16 parameters, two required fields, and no output schema, the one-line description is insufficient. It does not explain what fields can be updated, whether the operation merges or replaces existing values, expected return values, or error conditions. The annotations cover safety but not functional semantics.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides descriptions for all 16 parameters, so the description does not need to add parameter details (100% coverage). The baseline of 3 applies because the description offers no extra semantic meaning beyond the schema, such as update merge behavior or relationships between props like credential_id and auth_type.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Update' and identifies the resource as 'existing A2A agent record,' which clearly distinguishes it from create/delete/get A2A tools. It is slightly generic with 'record,' but the A2A qualifier helps differentiate from the general lyzr_update_agent sibling.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The word 'existing' and the required agent_id parameter imply the tool is for modifying an already-created A2A agent, which is a clear but unstated contrast to lyzr_create_a2a_agent. No explicit alternatives or preconditions are mentioned, so usage guidance is only implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_update_asset_parsing_statusB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, establishing a safe non-read-only mutation. The description adds that it updates status/metadata by id but does not mention merge semantics, validation, or potential side effects like re-triggering parsing. However, no contradiction exists, so a mid-range score is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single concise sentence, front-loaded with the verb and target. No filler or redundancy, making it easily parseable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having annotations and a schema, the tool is under-specified. No output schema is provided, and the description omits expected return value, allowed/metadata update fields, or consequences of the update (e.g., does it re-parse the asset?). The free-form 'update' object leaves significant ambiguity for an agent to act on.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for both parameters, so the schema already documents them. The 'update' parameter is loosely defined as an object with additionalProperties, and the description adds no extra meaning or examples beyond the schema, meriting the baseline 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses specific verb 'Update' and target 'parsing status/metadata of an asset by id', clearly distinguishing it from sibling tools like lyzr_get_asset_parse_status and other asset 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/5

  Does 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 lyzr_get_asset_parse_status or other update tools. The description lacks explicit usage context or exclusions, leaving the agent to infer applicability 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.

• lyzr_update_providerB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare this as a non-read-only, idempotent, non-destructive write operation. The description adds that it updates 'form/metadata' but does not disclose additional behavioral traits like partial update semantics, error conditions, or effects on unspecified fields. With annotations covering the safety profile, a baseline 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence, immediately conveying the action and target. It is front-loaded and contains no redundant words, making it highly efficient for an update operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  While the annotations provide safety context, the description is extremely brief. It does not explain whether the update is full or partial, what the return value is, or how errors are reported. With four required parameters including nested objects, the description is insufficient for complete operational context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides 100% coverage for all four parameters, each with a description. The description's mention of 'form/metadata' maps to the 'form' and 'meta_data' fields but adds little beyond the schema. The schema already does the heavy lifting, so the baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Update') and the target resource ('existing provider's form/metadata'), which distinguishes it from sibling tools like lyzr_create_provider, lyzr_delete_provider, and lyzr_get_provider. It 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/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. There are no prerequisites, exclusions, or comparisons to sibling tools such as lyzr_create_provider or lyzr_get_provider, leaving the agent without context for selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_update_provider_credentialB
  3.4/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds no behavioral context beyond the annotations. It does not mention whether the update is a full replacement (all fields required) or a partial update, nor does it describe the return value or side effects. The schema's required fields hint that all values must be supplied, but the description fails to disclose this important behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that directly states the tool's purpose. It is front-loaded and contains no redundant words. While brief, it is not padded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 7 parameters, nested objects, and no output schema, the description is too sparse. It fails to explain the full-replacement semantic, any required preconditions, or what the response will contain. The agent would need to infer too much for a reliable update operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers 100% of the parameters with descriptions, so the baseline is 3. The description adds no extra meaning beyond 'by id', which is already captured by the credential_id parameter. No additional value is provided.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Update'), the resource ('provider credential'), and the selection method ('by id'). This distinguishes it from sibling tools like lyzr_create_provider_credential and lyzr_delete_provider_credential.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: when you want to modify an existing provider credential. However, it does not provide explicit when-to-use vs alternatives, nor does it mention any prerequisites or exclusions. The guidance is minimal but not misleading.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_update_workflowB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=true, so the agent knows this is a non-destructive, idempotent write operation. The description adds a small behavioral hint by saying 'fields', which implies a partial update, but does not disclose details like whether it performs a merge or full replacement, or what happens if the workflow does not exist. This does not contradict the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no redundant words. It adds useful qualifiers ('fields', 'existing') beyond the title. It is not under-specified to the point of being a tautology, though it is minimal.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is a moderately complex update operation with four fully documented parameters and helpful annotations. The description is adequate for basic use, but lacks guidance on when to use it vs. alternatives and does not clearly indicate whether the update is partial or full. Since the schema covers parameters and annotations cover safety, the description is acceptable but not rich enough for a higher score.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, as each parameter (api_key, flow_id, flow_data, flow_name) has a clear description in the input schema. The description itself does not mention parameters, but the schema carries the full burden. According to the rubric, a baseline of 3 is appropriate when schema coverage is high and the description adds nothing extra.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Update fields on an existing workflow.' It uses a specific verb ('Update') and resource ('workflow'), and the qualifier 'existing' distinguishes it from create or delete operations. This is distinct from sibling tools like create_workflow or delete_workflow.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention that it should be used for modifying an existing workflow, nor does it reference related tools like create_workflow or delete_workflow. The usage context is only implied by the tool's name.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_world_model_list_personasB
  3.4/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint, openWorldHint, and idempotentHint, covering safety. The description adds no additional behavioral context such as pagination, ordering, empty-list behavior, or error cases; it merely restates the title.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that directly states the verb and resource. No filler or unnecessary details.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with one parameter and strong annotations, the description is adequate. It could mention return value or handle edge cases like missing world model, but overall it suffices for the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for the single parameter `world_model_id`, though the description is minimal ('The world model id'). The tool description adds no further param meaning, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action 'List' and the resource 'personas defined on a world model'. This distinguishes it from sibling tools like lyzr_world_model_list_scenarios (scenarios, not personas) and lyzr_world_model_create/get/delete.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit or implicit guidance is given about when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or relationships to other world model tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_agent_chat_completionsA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide the basic safety profile (non-read-only, non-destructive). The description adds that it is OpenAI-compatible and requires a specific agent ID, giving some context about the API behavior, but it doesn't disclose details like streaming behavior, rate limits, or potential side effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, information-dense sentence that immediately conveys the endpoint type and scope. No superfluous words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description gives the core idea and the schema covers the parameters, but given the large set of sibling chat tools, a bit more context about when this endpoint is preferred or how it differs from other completions endpoints would improve completeness. The lack of output schema info isn't critical for a chat endpoint.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides clear descriptions for all three parameters (agent_id, messages, stream), so the description doesn't need to add much. The baseline of 3 applies since the schema already covers parameter meaning.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies it as an OpenAI-compatible chat/completions endpoint scoped to a specific agent, distinguishing from general chat tools. It names the resource (agent) and the operation (chat completions), so the agent knows what it does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit when-to-use or alternative recommendations are provided. The description simply states what the tool is, leaving the agent to infer when to use it among many chat-related siblings like lyzr_chat or lyzr_simple_chat_completions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_clone_agentA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate a mutating, non-idempotent operation (readOnlyHint=false, idempotentHint=false), so the description does not need to restate that. However, it adds no additional behavioral context—such as whether the clone copies all agent settings, whether it is deep or shallow, or what resource is returned. The core action is clear, but beyond that, the description is silent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no wasted words. It states the action and object clearly, earning its place in exactly one line.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter clone tool, the description conveys the essential action. However, with no output schema, it omits what the caller should expect back (e.g., new agent ID) and whether the copy is fully independent. This makes it minimally viable but not richly informative.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with a single property 'agent_id' that includes its own description ('The agent_id to clone'). The description adds no extra parameter semantics beyond the schema, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'Create a copy of an existing agent.' This clearly distinguishes it from sibling tools like lyzr_create_agent (create new from scratch) and lyzr_update_agent, as it explicitly targets duplication of an existing 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/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit when-to-use or alternative guidance is provided. The description only implies usage via the phrase 'existing agent,' but does not mention exclusions or compare with lyzr_create_agent/lyzr_update_agent. This leaves the agent to infer the appropriate context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_create_artifactA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=false, so the description's 'Create' is consistent. It adds the behavioral detail that the created artifact is returned, but does not disclose potential behaviors like overwrite semantics, error conditions, or required permissions. This is adequate 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the action, and contains no wasted words. It is appropriately sized for a straightforward create operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the schema and annotations, the description is minimally complete: it states the purpose and return value, but lacks usage guidance and does not detail the structure of the returned artifact (which is not covered by an output schema). This is adequate for a simple tool but leaves typical gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with every parameter having a description in the input schema. The description itself adds no parameter-level detail, so the baseline of 3 applies because the schema carries the full burden.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool creates a new artifact, scoped to a user/session, and returns the created artifact. This distinguishes it from sibling tools like update_artifact, delete_artifact, and list_artifacts, which have different verbs and resources.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives such as update_artifact or list_artifacts. It only states the action itself, leaving the agent to infer usage from the tool name, which is not sufficient.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_create_provider_credentialA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint=false and destructiveHint=false, and the description adds the return value (credential_id) and that it targets Lyzr providers. It does not disclose any security implications, uniqueness behavior, or side effects beyond creation, but with annotations present, the added context is adequate though not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence that covers the action, target resource, and return value. It is concise and efficiently structured with no wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description's mention of 'Returns the new credential_id' is helpful. However, it does not explain how to obtain the required provider_id, what formats the credentials object should take, or any relationships to other tools. Given the schema covers parameters, the description is minimally adequate but leaves operational gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3. The description does not add extra meaning beyond the schema; it only mentions 'credential' generically while the schema provides clear descriptions for each parameter. No additional value is provided.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Create a credential for a Lyzr provider' with a specific resource type (provider credential) and provides an example (database or SaaS integration). It also mentions the return value (credential_id), making the purpose distinct from generic credential tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given on when to use this tool versus the many sibling credential tools (e.g., lyzr_create_credential, lyzr_create_static_tool_credential). It does not specify prerequisites like creating a provider first, nor exclude contexts where other credential types should be used.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_create_webrtc_sessionA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already convey the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), and the description is consistent with them ('Create' implies mutation). However, the description adds no additional behavioral context such as return payload, persistence semantics, authentication needs, or side effects beyond what annotations state.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single sentence that front-loads the action and resource, with zero filler or redundancy. Every word contributes to understanding the tool's purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple (2 well-documented string params, annotations present), so a short description is mostly adequate. However, the absence of an output schema means the agent receives no hint about what a successful creation returns (e.g., connection details), and the description does not differentiate from the large set of sibling session tools beyond the WebRTC qualifier.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both agent_id and voice_id clearly documented. The description's mention of 'agent + voice id' merely restates the schema and adds no extra meaning, format, or usage details.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Create') and names a distinct resource ('WebRTC voice session') along with the two key inputs (agent + voice id). The 'WebRTC voice' qualifier clearly distinguishes this from sibling session tools like lyzr_session_create, lyzr_session3_create, and lyzr_start_session.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description offers no guidance on when to choose this tool over alternatives, no prerequisites, and no exclusions. It merely restates the action without contextualizing when a WebRTC voice session is the right choice versus sibling session/chat tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_delete_toolA
  3.5/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare this as destructive (destructiveHint=true), and the description adds no extra behavioral context. It does not mention whether deletion is permanent, cascades to associated resources, or requires specific permissions. The openWorldHint is also left unexplained, which is a gap for a destructive operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence with no extraneous words. It directly states the action and target, perfectly sized for a simple one-parameter tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple single-parameter delete tool, the description is adequate but not fully complete. It does not address potential side effects, return values, or the meaning of openWorldHint, which could be relevant for an agent deciding whether to invoke it. The annotations cover destructiveness, but the broader impact remains unclear.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers the parameter completely with a description 'The tool id to delete' (100% coverage). The description's 'by id' merely repeats what is already in the schema, adding no new semantic meaning. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Delete' with the resource 'tool' and identifies the method 'by id'. This clearly differentiates it from sibling CRUD tools like create, update, get, and bulk_delete_tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for deleting a single tool when its id is known, but it does not explicitly mention alternatives like lyzr_bulk_delete_tools or conditions where deletion should not be performed. No exclusions are provided, but the usage context is reasonably clear from the verb and parameter.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_audit_statsA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds that the output is aggregated, but says nothing about output format, pagination, or what 'statistics' means, so it provides only marginal additional 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that efficiently communicates the core action without waste.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with two optional parameters, the description is adequate but lacks detail on what statistics are returned. Without an output schema, it would benefit from mentioning the type of aggregates (e.g., counts, unique users), leaving some ambiguity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with both start_time and end_time described as ISO 8601 date-times. The description merely restates that the time range is optional, which is already evident from the schema's lack of required fields, adding little semantic value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves aggregated audit log statistics, with a specific verb ('Get') and resource ('aggregated audit log statistics'), distinguishing it from raw audit log listing tools in the sibling set.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to use this tool versus alternatives like list_*_audit_logs or get_activity_metrics. The description does not specify whether this should be preferred for summary views or provide any selection criteria.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_contextA
  3.5/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds no behavioral information beyond what the schema and annotations provide, such as error behavior or return payload. No contradiction 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, front-loaded sentence 'Fetch a context by id.' is minimally sized with no wasted words. It is easy to parse at a glance.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple, but the description does not clarify what a 'context' is, what the response looks like, or how this differs from similar get_context_* siblings. Given no output schema, some additional disambiguation would help, though the basic operation is clear.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides 100% coverage of the single parameter context_id with a clear description. The tool description only repeats 'by id' without adding new semantic meaning, meeting the baseline for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Fetch' with the resource 'context' and the lookup mechanism 'by id'. This clearly distinguishes it from sibling tools like lyzr_list_contexts and lyzr_get_context_by_name_internal.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance is given on when to use this tool versus alternatives. It is implied that fetching by ID is the intended use, but the description does not mention exclusions or alternative tools, leaving the agent to infer from the name and schema.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_feature_flag_adminA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds no extra behavioral context beyond what annotations and schema provide, such as return format, error handling, or admin permission requirements. It does not contradict the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that conveys the essential operation without any fluff. It is appropriately sized for a simple get tool and every word is relevant.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple single-fetch tool with complete schema and safety annotations, the description is adequate but has gaps: it does not describe the return value (no output schema exists), behavior on missing keys, or any admin-specific implications beyond the title. These gaps make it minimal but not fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with the single required parameter 'key' described as 'Feature flag key'. The description's mention of 'by key' adds no new meaning. Baseline 3 is appropriate since the schema fully documents the parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Fetch a single feature flag by key' clearly states the action (fetch), the resource (feature flag), and the scope (single by key). It distinguishes itself from sibling list/get tools like lyzr_list_feature_flags_admin and lyzr_get_feature_flags by indicating a single-item retrieval.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. While 'by key' implies a single lookup, it does not explicitly say to use this instead of list_feature_flags_admin or note any prerequisites or admin permissions implied by the title.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_git_create_branchA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate a non-read-only, non-destructive operation, and the description does not contradict them. However, the description adds minimal behavioral context beyond annotations—it doesn't explain what happens if the branch already exists, whether from_branch defaults to the current branch, or whether the new branch becomes active after creation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence with no wasted words. It front-loads the action and includes the key scope ('agent's git repo'), making it easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple creation tool with full schema coverage and annotations, the description is adequate but sparse. It doesn't cover important behavioral nuances like whether the tool switches to the new branch, how from_branch behaves when omitted, or error conditions. Given the large set of related git sibling tools, a bit more context would improve completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all parameters (agent_id, branch_name, from_branch) are already documented in the schema. The description adds no additional parameter semantics beyond reinforcing that a 'new branch' is created, which maps to branch_name. This meets the baseline for full schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the specific action ('Create'), the resource ('a new branch'), and the scope ('in an agent's git repo'). This distinguishes it from sibling tools like git_switch_branch (switch to existing branch) and git_list_branches (list branches).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no explicit when-to-use or when-not-to-use guidance relative to sibling tools. It does not mention prerequisites (e.g., repo already initialized) or clarify that this only creates a branch and does not switch to it, which is important given the existence of git_switch_branch.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_git_pullA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=false, so the mutating nature is already known. The description adds no extra context beyond the fact that it pulls changes. It does not mention potential merge conflicts, stashing, or failure modes, but this is not a contradiction. A middle score is appropriate because the description adds minimal behavioral info beyond annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, direct sentence with no filler. It is front-loaded with the verb and clearly identifies the target. Perfectly concise for the tool's simplicity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with two parameters and no output schema. The description is adequate for a basic pull operation, but it omits any caveats like merge conflicts, local changes preservation, or what the return value represents. Since openWorldHint=true indicates external interaction, a bit more context would be helpful.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptions for both agent_id and branch. The tool description adds nothing new about parameters, so the baseline of 3 is correct since the schema carries the semantic burden.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Pull') and the resource ('the latest changes from git for an agent's repo'). It distinguishes from sibling git tools by identifying the exact operation (pull vs status, commits, branches, etc.).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given on when to use this tool vs alternatives. With many sibling git tools (merge, switch, list, etc.), the description does not explain scenarios (e.g., 'use to sync before editing') or call out alternatives/conflicts.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_git_save_configA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate this is a write operation (readOnlyHint false, idempotentHint false). The description adds that it saves/updates provider, repo, and credentials, which is useful but does not disclose side effects, auth requirements, or whether it overwrites existing config. It provides some added context beyond annotations without rich behavioral 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that front-loads the action and includes the key object. It avoids redundancy and is appropriately sized for the tool's simplicity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is adequate but leaves out the full scope of configurable parameters (e.g., branch, environments, base_url) and does not explain what happens on success/failure. With no output schema, the description could more fully explain the effect of saving config, but the schema covers parameter details.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage for all 8 parameters with meaningful descriptions. The tool description mentions only provider, repo, and credentials, but this does not add significant meaning beyond what the schema already provides. The baseline of 3 applies because schema handles parameter documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb phrase 'Save or update' and clearly identifies the resource as 'git connection (provider, repo, credentials)' for an agent. This distinguishes it from sibling git tools like lyzr_git_init_repo or lyzr_git_get_status.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides minimal context ('for an agent') but offers no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or why one might choose this over related tools like lyzr_git_validate_config or lyzr_git_disconnect.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_git_save_governanceA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate this is a write operation (readOnlyHint=false) and not idempotent or destructive. The description adds the upsert semantics ('Save or update') and clarifies that 'governance' means 'approval pipeline'. However, it does not disclose whether the entire policy is replaced or merged, or any side effects beyond what annotations imply. Some value is added beyond annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence of 14 words. It is front-loaded with the verb and resource, and every word contributes. No extraneous information or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 4 parameters including a complex 'gates' array (though no nested object schema), no output schema, and moderate annotations. The description gives the core purpose but does not explain when to use it relative to sibling governance tools or how the gates parameter should be structured. It is adequate for a simple definition but lacks workflow context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema coverage is 100% with descriptive parameter names and descriptions (agent_id, name, gates, entity_type). The description does not add extra meaning about parameters; it only repeats 'governance' which is already implied. Baseline of 3 is appropriate since the schema carries the semantic load.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Save or update') and clearly identifies the resource ('governance (approval pipeline) policy for an agent's git repo'). It distinguishes from sibling tools like get_governance, delete_governance, and sync_governance by indicating this is the write/update operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention that this should be used to create or modify governance policies, nor does it reference related tools or contexts like 'use get_governance to read, delete_governance to remove'. There is no exclusion or explicit usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_git_switch_branchA
  3.5/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate that the operation is not read-only (readOnlyHint=false). The description adds no additional behavioral context such as side effects on the working directory, whether changes are persistent, or how failures are handled (e.g., branch not found). It does not contradict the annotations, but it does not enrich them either.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that states the action and scope without any redundant information. Every word contributes to clarity, making it highly concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter operation, the description is adequate, but it lacks context about expected outcomes (e.g., success message), prerequisites (branch existence), or error conditions. Given the absence of an output schema and the availability of sibling git tools, a bit more guidance would improve completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both 'agent_id' and 'branch' having descriptive names and descriptions. The description adds no extra meaning to the parameters, so the baseline of 3 applies because the schema fully documents them.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Switch' and clearly identifies the resource: 'the active branch for an agent's git repo.' This distinguishes it from sibling tools like lyzr_git_create_branch, lyzr_git_merge_branches, and lyzr_git_deploy_branch, which serve different purposes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is used when you need to change the active branch, but it provides no explicit guidance on prerequisites (e.g., the branch must already exist), alternatives, or when not to use it. There is no mention of how this differs from creating a branch or handling uncommitted changes, leaving room for misinterpretation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_initiate_mcp_oauthA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate non-read-only, open-world, non-idempotent behavior. The description adds that it returns an auth URL but does not disclose potential external side effects or follow-up steps. It is consistent with annotations and provides minimal additional 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no unnecessary words. It conveys the essential action and output efficiently.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter tool, it conveys the core action and return value. However, it lacks guidance on what to do with the auth URL (e.g., open it, redirect the user) or any mention of subsequent OAuth completion steps. Since there is no output schema, more detail on the response would improve completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with server_id described as 'MCP server id'. The description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (start OAuth flow), the resource (MCP server), and the expected output (auth URL). This distinguishes it from related sibling tools like get_mcp_oauth_status, which would check the status, and credential creation tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no explicit guidance on when to use this tool versus alternatives, such as checking OAuth status first or using credential creation tools. Usage context is only implied by the action itself.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kb_sync_browse_childrenA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds the deprecation status, which is beyond annotations, but does not disclose return format or behavior on invalid paths. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with the deprecated flag. It is concise and contains no unnecessary words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with strong annotations and full schema coverage, but the description omits return value details and any alternative tool recommendation. This is a clear gap, especially for a deprecated tool, but the essential purpose is still communicated.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so each parameter has a description. The tool description adds minimal meaning beyond the schema, only restating the action. Baseline 3 is appropriate since the schema carries the parameter details.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Browse files/folders within a SharePoint drive path', providing a specific verb and resource. This distinguishes it from sibling tools like `lyzr_kb_sync_browse_sites` and `lyzr_kb_sync_browse_drives`, and the [deprecated] tag adds 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/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given on when to use this tool versus alternatives. The [deprecated] tag implies it should not be used, but no replacement tool is recommended. There is no mention of valid use cases or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kb_sync_cc_pairs_cancel_attemptA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and idempotentHint=true, so the agent knows it is a destructive but repeatable operation. The description adds the useful 'in-progress' qualifier but does not disclose what happens when cancelled, whether partial results are removed, or if any permissions are required. This is some added context but not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence of five words, front-loads the verb and object, and contains no filler or redundant information. Every word contributes to the meaning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a destructive operation with no output schema, the description is sparse. It does not mention the effects of cancellation, return value, or how it differs from the related 'pause' tool. However, the schema fully documents parameters and annotations provide safety hints, making it minimally viable but with clear gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Both parameters are fully documented in the schema with clear descriptions ('The index attempt id to cancel' and 'The connector-credential pair id'). The tool description itself adds no additional parameter semantics, so with 100% schema coverage, the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the specific action ('Cancel') and the target resource ('index attempt'), and qualifies it with 'in-progress' to distinguish it from other operations like pausing a connector-credential pair. This makes the purpose unambiguous and differentiates it from sibling tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives such as pausing a pair or deleting an attempt. The only implied condition is that the attempt must be in-progress, but there is no explicit statement of prerequisites, exclusions, or when not to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kb_sync_cc_pairs_get_attemptA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations (readOnlyHint, openWorldHint, idempotentHint) already communicate that this is a safe, read-only, idempotent operation. The description adds minimal behavioral context beyond 'fetch by id', such as no mention of return format, error semantics, or the composite key requirement. It does not contradict annotations, and the scoping is mildly useful, but it offers little additional transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, direct sentence with no fluff. It is front-loaded with the verb and object, and every word adds meaning. This is appropriately concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple fetch tool, the description is minimally viable, but it leaves gaps: no explanation of what an 'index attempt' is, no indication of what the response contains, and no mention of the need for cc_pair_id in addition to attempt_id. Since there is no output schema and annotations do not cover these aspects, a bit more context would be helpful for a well-rounded description.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so both parameters are fully documented in the schema. The description does not add meaning beyond the schema; in fact, 'by id' could slightly mislead by implying a single ID, while both attempt_id and cc_pair_id are required. However, the schema clarifies this, so the description does not actively harm beyond missing an opportunity to explain the composite key.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Fetch'), a clear resource ('single index attempt'), and a scoping qualifier ('by id'). It clearly distinguishes this from sibling tools like list_attempts (plural/list) and cancel_attempt (cancel action). Despite not naming alternatives, the 'single' qualifier inherently contrasts with the list tool.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention sibling tools like lyzr_kb_sync_cc_pairs_list_attempts, nor does it state prerequisites or exclusions. The only implied usage is that you need an attempt ID, but no context is given for choosing this over related tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_list_all_user_toolsA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare the tool as safe, read-only, idempotent, and non-destructive. The description adds the scope ('all tools', 'current user') but does not disclose other behavioral aspects such as what 'available' means, whether it includes MCP tools, or response format. Since annotations cover safety, this is adequate but not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single clear sentence that immediately conveys the action and scope. No filler words or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple zero-parameter list tool with strong annotations, the description covers the core behavior. However, with no output schema, it does not mention what the response contains (e.g., tool names, metadata). This is a minor gap but does not undermine usability.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the schema imposes no burden. The description does not need to explain parameter syntax; the empty schema is complete. Baseline of 4 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'List' and the resource 'all tools available to the current user', making the operation unambiguous. It does not explicitly differentiate from similar sibling tools like lyzr_list_tools or lyzr_get_all_tools, but the scope ('current user') provides some 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/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No information is provided about when to use this tool versus alternatives like lyzr_list_tools or lyzr_get_tools_actions. There is no mention of context, prerequisites, or exclusions, leaving the agent without guidance for tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_list_lyzr_aci_toolsA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. The description adds 'org-wide' scope, which is useful context, but does not disclose other behavioral details such as pagination or filtering. It is consistent with the annotations, so not contradictory.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence containing only necessary information. It is front-loaded with the action and resource, with no wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is a simple, parameterless list operation. With no output schema, the description could explain the returned format, but 'list' strongly implies a collection of tools. The org-wide scope adds clarity. Overall, it is reasonably complete for the tool's complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has zero parameters, giving the baseline a 4. The description adds minimal semantic meaning beyond 'org-wide', which is sufficient given the parameterless interface.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'List org-wide Lyzr ACI tools' uses a specific verb ('List') and identifies a resource type ('Lyzr ACI tools') with a scope ('org-wide'). It is clear but does not distinguish itself from many sibling listing tools such as 'lyzr_list_tools' or 'lyzr_get_all_tools'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It only states the basic action without naming competing list tools or giving exclusion criteria, leaving the agent to infer usage from the name.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_list_tracesA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds no further behavioral context such as response format, pagination behavior, or potential side effects, which is acceptable given the annotation coverage, but it does not go beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that is front-loaded with the main action and resource, and then enumerates the optional filters. Every word contributes, with no repetition or filler. This is an ideal length for such a tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has no output schema, and the description does not explain what the response will contain (e.g., a list of trace summaries, keys, ordering). However, for a simple list tool with comprehensive parameter schemas and annotations, the description is minimally sufficient, but there is room for improvement by stating the default pagination or the nature of the returned traces.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already documents all parameters. The description summarizes the filter types (time range, agent, session, user, customer) but does not add meaningful syntax or usage details beyond what the schema provides. It does not explain the pagination parameters fully, but those are already in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists agent execution traces and mentions optional filters, making the primary action and resource obvious. However, it does not explicitly differentiate from sibling trace-related tools like lyzr_ops_get_traces or lyzr_get_traces_dashboard, which could lead to ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when the user needs a filtered list of traces, but it does not provide explicit guidance on when to choose this tool over alternatives, nor does it mention when not to use it. No exclusions or alternative recommendations are given.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_livesource_ext_browse_drivesA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, so the agent knows this is a safe, non-mutating, repeatable operation. The description adds no additional behavioral context such as pagination, authentication requirements, or error behavior. It does not contradict the annotations, but it also does not go beyond them, so a mid-range score is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence with no unnecessary words or repetition. It efficiently conveys the tool's purpose without any fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  While the tool is simple and has complete parameter documentation plus annotations, the description does not explain the return value format or how this tool fits into the broader SharePoint browsing workflow. Since there is no output schema, the agent is left to guess what a 'drive' result looks like. This is a minimal but acceptable level of completeness for a straightforward list operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides descriptions for both parameters (site_url and credential_id), covering 100% of the parameters. The description does not add any further meaning beyond what the schema states, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('List') and the resource ('drives within a SharePoint site'), making it easy to understand what the tool does. The scope ('within a SharePoint site') helps differentiate it from sibling tools like browse_sites and browse_children, which target different levels of the SharePoint hierarchy.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention that it should be used after browsing sites and before browsing children, nor does it specify any prerequisites or exclusions. With similar sibling tools (browse_sites, browse_children), this lack of usage direction leaves the agent to infer the correct context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_livesource_ext_validate_accessA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already disclose read-only, idempotent, and open-world hints. The description does not contradict these and adds some value by specifying the validation semantics, but it does not detail behavior such as error handling, whether all URLs must pass, or return shape. With annotations present, this is acceptable but not enriching.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is one sentence, front-loaded with the verb, and contains no wasted words. It is appropriately concise for a simple validation operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple and has good annotations and schema, but there is no output schema and no mention of what the tool returns or how failures are reported (e.g., error vs. false). This leaves some ambiguity for the agent, so while adequate, it is not fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptive parameter names and descriptions for both credential_id and site_urls. The description adds no additional parameter meaning beyond what the schema already provides, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Validate') and clearly identifies the resource ('credential has access to given SharePoint site/drive URLs'). It is distinct from sibling tools like browse_sites or sync_permissions, and not a tautology.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given on when to use this tool versus alternatives (e.g., before adding a livesource, or versus browse_sites). There is no mention of prerequisites or context. The description only states what it does, not when to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_livesource_listA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. However, the description adds no behavioral context beyond the basic list operation—e.g., whether pagination applies, what a 'live source' contains, or if the list is ordered. It neither contradicts the annotations nor provides additional behavioral detail, resulting in a neutral 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no unnecessary words. It communicates the essential purpose efficiently, and the structure is highly scannable. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With only one parameter, no output schema, and useful annotations, the description is minimally adequate but lacks richness. It does not explain what live sources are, what the returned list contains, or any required credentials or setup, which would be helpful given the domain-specific terminology. The tool is simple though, so a score of 3 reflects the adequate-but-minimal nature.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already describes the only parameter (rag_id) as 'Knowledge base id' with 100% coverage, so the description adds no extra meaning. The baseline of 3 applies because the schema carries the full semantic weight; the description does not compensate with any additional parameter context.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('List') and the resource ('live sources') with a scope ('for a knowledge base'), which is specific and distinguishes it from sibling tools like lyzr_livesource_get (single source) or lyzr_livesource_list_credentials. The name and title align with the description, making the tool's purpose 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/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives, such as lyzr_kb_list_documents or lyzr_livesource_get. The description does not mention prerequisites like the need for an existing knowledge base or any exclusions. There is no explicit context for when this tool is the right choice beyond its name.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_memprovider_validate_supermemoryA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, and the description does not contradict them. It adds no further behavioral detail, such as whether this performs a live connectivity check or what error responses look like, but the annotations cover the safety profile.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler. It is appropriately sized for the tool's simplicity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter validation tool with strong annotations, the description is minimally adequate, but it omits what happens when validation succeeds or fails. Since there is no output schema, the description carries more responsibility for setting expectations, especially regarding the meaning of the returned validation result.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 100% coverage for the single required credential_id parameter, which already has a clear description. The tool description adds only the plural 'credentials' context and no new format or lookup details, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Validate' and a clear resource 'Supermemory memory provider credentials'. It is easily distinguished from siblings like validate_mem0, validate_aws_agentcore, and supermemory_status.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives such as supermemory_status, validate_mem0, or credential listing tools. The description states what it does but not when it should be preferred or what prerequisites exist.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_ops_get_grouped_logsA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations (readOnlyHint, openWorldHint, idempotentHint) already communicate the read-only and idempotent nature. The description adds the notion of 'grouped' logs and the required combination, but it doesn't disclose pagination behavior, output format, or error handling. It is consistent with the annotations, adding 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that immediately communicates the action and target. It contains no redundant or vague wording, making it highly efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a straightforward read tool with annotations and a fully documented schema, the description is adequate but minimal. It doesn't explain what 'grouped' means, the response structure, or any access prerequisites. Given five parameters and no output schema, a bit more detail would help, but it's not severely lacking.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with straightforward descriptions for all parameters (trace_id, run_id, log_id, page, limit). The description's phrase 'trace/run/log combination' reinforces that the three IDs must be used together, but it adds little beyond what the schema already conveys. The schema does the heavy lifting here.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Fetch') and the resource ('grouped activity logs') with a specific scope ('for a trace/run/log combination'). It provides enough specificity to understand what the tool does, though it doesn't explicitly differentiate from sibling logging tools like lyzr_ops_get_agent_tool_logs.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when a trace/run/log combination is needed, but it offers no explicit comparison to alternatives, no exclusions, and no mention of prerequisites. It's not misleading, but it relies on the agent to infer when to use this over other log/trace tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_parse_websiteA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds that parsing produces chunks and that no knowledge base is required, implying the result is returned directly rather than persisted. However, it does not disclose potential side effects, whether the operation is stateless, or any cost/rate implications. Since annotations cover the safety profile, a score of 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence: 'Parse a website URL into chunks (no knowledge base required).' It delivers the core purpose and a key differentiator in under 10 words, with no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's moderate complexity (6 params, no output schema), the description provides a minimal but sufficient overview. It lacks details about return format, error behavior, or how this differs from the sibling lyzr_parse_website_apify. The schema covers parameter semantics, but the description does not fully contextualize the tool within the broader parse/knowledge-base workflow.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all six parameters are described at least at a basic level. The description itself does not elaborate on parameter meanings, but the schema already explains url, chunk_size, extra_info, extra_fields, chunk_overlap, and parser_config. No additional benefit is provided by the description beyond what the schema offers.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Parse'), the resource ('website URL'), and the output ('chunks'). It also distinguishes itself from knowledge base training tools via the parenthetical '(no knowledge base required)', which helps differentiate it from siblings like lyzr_kb_train_website. However, it does not explicitly mention other parse variants (e.g., lyzr_parse_text) or provide details on the exact nature of the chunks.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'no knowledge base required' implies a usage context: use this tool when you want to parse a website without storing the results in a knowledge base. This is a useful hint but not a full guideline. It does not explicitly state when to prefer this over lyzr_parse_website_apify or other parse tools, nor does it mention any prerequisites or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_rai_create_policyA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate this is a mutating, non-idempotent operation, so the description does not need to restate that. It adds useful context about the types of checks a policy can include, but does not disclose side effects, overwrite behavior, or how the policy takes effect. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that names the action and object immediately. It is free of filler and every phrase contributes to understanding the tool's purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a create tool with 7 parameters and no output schema, the combination of description and schema covers how to invoke it. However, it does not explain what happens after creation (e.g., whether the policy is immediately active, how it binds to agents) or describe the return value. Adequate for basic invocation but not fully context-rich.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 71% and the schema already provides meaningful descriptions for most parameters (thresholds, booleans, topics). The description's parenthetical adds a high-level grouping of parameter families but no additional syntax or interaction details, so it stays at the baseline for good schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Create') and specific resource ('Responsible-AI guardrail policy'), and enumerates the guardrail categories (toxicity, prompt-injection, NSFW, banned topics). This distinguishes it from sibling tools like lyzr_rai_list_policies, lyzr_rai_get_policy, and lyzr_rai_delete_policy.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit when-to-use or when-not-to-use guidance is provided. It does not mention alternatives like listing, getting, or deleting policies, nor does it state preconditions such as whether an agent must exist first. Usage is only implied by the verb 'Create'.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_semantic_model_remove_documentation_taskA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and idempotentHint=true, so the description does not contradict them. It adds minor context by clarifying this removes a 'background' task, but does not disclose what happens to the task (e.g., whether it fails if already completed) or any other behavioral nuances. With annotations present, the bar is lower, but the description still provides limited additional transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, front-loaded sentence with no filler. It conveys the action, target, and scope efficiently, earning its place without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with two described parameters and clear annotations, so the brief description is mostly adequate. However, it lacks usage guidance and behavioral details that would help an agent understand when to invoke it and what to expect, making it minimally viable but not fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% with both parameters (table_name and rag_config_id) already documented. The description adds no further semantics about how these parameters relate or how they affect the removal, so it does not go beyond the structured schema. Baseline 3 is appropriate for full schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Remove') and resource ('background documentation-save task for a table'), clearly distinguishing this from sibling tools like lyzr_semantic_model_remove_documentation and lyzr_semantic_model_save_documentation_task. It precisely states the action and scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given on when to use this tool versus alternatives. It does not mention that this cancels a scheduled task or contrast it with direct documentation removal methods, leaving the agent to infer usage solely from the tool name and sibling context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_session3_getA
  3.5/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint and idempotentHint, but the description adds no behavioral context beyond restating the resource. It does not disclose what fields are returned, whether messages are included, or any error behavior, leaving the agent without additional safety or expectation-setting.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, brief sentence with no filler or redundant phrases. All words are purposeful and the structure places the essence ('fetch v3 session') at the front.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple getter with one parameter and favorable annotations, but no output schema exists. The description does not explain what the returned session contains or whether it differs from other session variants, leaving moderate ambiguity about the actual return payload.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the single parameter session_id is clearly described in the schema as 'Session id to fetch'. The description adds no new parameter-level meaning beyond what the schema already states, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Fetch a v3 session by id' uses a specific verb (fetch), names the resource (v3 session), and specifies the lookup method (by id). This clearly distinguishes it from sibling tools like lyzr_session_get and lyzr_session3_list.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implicitly signals use when you have a v3 session id and need the session object. However, it provides no explicit guidance on when to prefer this over lyzr_session_get or how to obtain the id via lyzr_session3_list, and it gives no exclusion criteria.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_session3_updateA
  3.5/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=false (write operation) and destructiveHint=false. The description adds no extra behavioral context—such as whether metadata is merged or replaced, or what the response looks like. It essentially repeats the 'update' intent without illuminating side effects or requirements.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single focused sentence with no wasted words. It is front-loaded and efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter update tool, the description is adequate, but it omits return value semantics and does not differentiate when to use this tool over lyzr_session_update. No output schema exists, so the description should provide a bit more closure, but the gap is not severe.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for both parameters, so the baseline is 3. The description does not add meaning beyond the schema; it simply refers to 'metadata' which is already described in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Update' and the specific resource 'v3 session's metadata'. The 'v3' qualifier distinguishes it from the sibling tool lyzr_session_update, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for v3 sessions via the 'v3' in the name, but it does not explicitly provide when/when-not guidance or mention alternatives like the non-v3 session update tool. Context is implied rather than stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_set_agent_lockA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already cover mutation (readOnlyHint=false), non-destructiveness (destructiveHint=false), and idempotency (idempotentHint=true). The description adds environment scoping context but does not explain what locking actually does (e.g., prevents modifications or invocations), so additional behavioral context 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Single concise sentence, front-loaded with action, no redundant words. Achieves maximum clarity per word.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple 3-parameter tool with good annotations, the description is adequate but lacks details about the lock's effect or when to use instead of lyzr_set_agent_status. Does not explain the outcome or significance of locking.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3. The description's mention of 'optionally scoped to an environment' reinforces the environment parameter but adds minimal meaning beyond the schema fields.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states it locks or unlocks an agent, with optional environment scoping. This is a specific verb+resource and distinguishes from most sibling tools, though it doesn't explicitly differentiate from the similarly named lyzr_set_agent_status.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when 'lock/unlock' is needed, but provides no explicit when-not or alternative guidance. With sibling tools like lyzr_set_agent_status, more explicit direction would help.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_world_model_delete_test_caseA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already disclose destructive and idempotent behavior, so the description adds no new context beyond the bare action. It does not contradict annotations, but it also does not elaborate on irreversibility, cascading effects, or confirmation, which would add value.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, compact sentence with no wasted words. It front-loads the action and resource, making it quickly parseable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete operation with two required parameters and rich annotations, the description is minimally sufficient. However, it omits potential consequences (e.g., permanent removal, whether the test case is detached from all scenarios) and does not describe return behavior, leaving some gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage for both parameters, so the description need not add much. The tool description does not add extra meaning beyond the schema, but the schema already provides adequate clarity, making this a baseline score.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Delete') and a clear resource ('test case') scoped to 'world model', which directly distinguishes it from sibling tools like add/update/list test cases. It fully captures the tool's function.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool vs alternatives such as updating or adding test cases. It does not mention any prerequisites, exclusions, or scenarios where deletion is appropriate, leaving the agent to infer usage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_world_model_list_test_casesA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations (readOnlyHint=true, idempotentHint=true) already communicate the safe, read-only nature of the operation. The description adds no additional behavioral context (e.g., pagination, ordering, or whether hidden test cases are included). Since it does not contradict annotations and adds the scope 'defined on a world model', it meets the baseline for simple list operations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, short sentence that directly conveys the action and target. Every word earns its place, with no filler or repetition. It is appropriately sized for a simple CRUD-style list operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple (one parameter), has no output schema, and relies on annotations for safety. The description adequately states the outcome ('List the test cases') but does not mention return format, pagination, or the relationship to sibling world-model tools (e.g., scenarios). While not incomplete for a basic list, it offers no extra context that would help an agent avoid confusion with similar tools.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema fully documents the single parameter 'world_model_id'. The description adds no extra meaning to the parameter—it does not mention that the ID must exist or that it refers to a specific world model resource. Thus, the description does not go beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and resource ('test cases defined on a world model'), clearly distinguishing it from sibling tools like lyzr_world_model_list_scenarios and lyzr_world_model_list_personas. The title reinforces the purpose, leaving no ambiguity about what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention that it is for read-only inspection, nor does it note any differences from similar list tools (e.g., lyzr_world_model_list_scenarios). For an agent, there is no explicit context about selection among siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_world_model_update_scenarioA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=true, providing basic safety context. The description adds no extra behavioral details, such as whether this is a partial update, what happens if the scenario doesn't exist, or any permission requirements. It is consistent with annotations but adds no value beyond them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single clear sentence with no superfluous words. It efficiently communicates the tool's purpose without redundancy, making it easy to parse quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple update operation with well-documented parameters and annotations, the description is minimally acceptable. However, it lacks contextual details such as whether the scenario must already exist, whether other fields are preserved, or what the return value looks like. These gaps are partially mitigated by the schema and annotations but leave room for improvement.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter clearly explained in the input schema. The description does not add any additional meaning or relationships between parameters, so it relies entirely on the schema. Baseline score of 3 is appropriate since the schema fully documents the parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Update a scenario on a world model' clearly identifies the verb (update) and resource (scenario on a world model), distinguishing it from sibling tools like lyzr_world_model_add_scenarios and lyzr_world_model_delete_scenario. However, it does not specify which fields are updated (e.g., name, description), which is slightly vague but acceptable given the schema.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The context implies this tool is used when an existing scenario needs modification, but there is no explicit guidance on when to use it versus alternatives like add or delete scenario. No preconditions (e.g., existence of the scenario_id) are mentioned, so usage is implied rather than clearly instructed.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_add_channel_agent_routeA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=false and destructiveHint=false, and the description adds minimal context ('existing channel') but no details on error behavior, idempotency, or side effects. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single clear sentence with no redundant words, effectively front-loading the essential purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple add operation with full schema coverage and annotations, the description is mostly complete. However, with no output schema, it doesn't mention return values or confirmation behavior, which would be useful for a mutation tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides descriptions for all three parameters with 100% coverage. The tool description adds no additional meaning beyond the schema, so baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'add' with a clear resource 'agent route to an existing channel', distinguishing it from channel creation/removal siblings like create_channel and remove_channel_agent_route.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives no explicit guidance on when to use this tool vs alternatives. It implies usage from the verb, but there are no prerequisites (e.g., channel must exist) or alternative tool references (e.g., remove_channel_agent_route).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_create_file_upload_credentialA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate this is a write operation (readOnlyHint: false) and non-idempotent, which aligns with 'Create'. The description adds the behavioral detail that this tool accepts file uploads rather than references, which is useful. It does not describe permissions, side effects, or response behavior, but with annotations present the additional burden is modest.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence of 14 words, front-loaded with the action and resource. No wasted words, and it clearly communicates the core function.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With only 2 parameters, both fully described in the schema, and annotations provided, the description is largely complete for a simple creation tool. The only gap is the absence of any mention of the return value or confirmation, but no output schema exists and the action is straightforward.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for both parameters (credential_data and files), so the schema already fully documents the meaning. The description adds only the example file types 'certificates, keys', which provides some semantic flavor but does not materially exceed the schema's own descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Create a provider credential by uploading one or more files.' It specifies the resource (provider credential) and the method (file upload). However, it does not explicitly distinguish this from sibling tools like 'lyzr_create_provider_credential' or 'lyzr_create_static_tool_credential', though the file-upload focus is implicit.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context by specifying 'uploading one or more files (e.g. certificates, keys)', which hints at scenarios involving certificate/key files. However, it provides no explicit guidance on when to choose this tool over alternatives, and no exclusions or alternative tool references.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_create_tool_requestA
  3.6/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate this is not read-only and not idempotent, but the description adds no behavioral context beyond the literal action. It does not clarify whether the request creates a persistent record, whether it requires approval, whether it is synchronous/asynchronous, or what the outcome of the request is. With minimal annotation coverage, the description carries a heavy burden and fails to disclose this.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that efficiently states the tool's purpose with no redundancy. It covers the four request types without unnecessary elaboration.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple request-submission tool, the description is largely complete: the schema documents all inputs, and the purpose is clear. However, with no output schema, the description does not indicate what the tool returns (e.g., a request ID or confirmation), and it omits any context about post-request behavior. Still, given the low complexity, this is a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage for all six parameters, so the schema fully documents each parameter. The description itself adds no additional parameter information, but the baseline for high coverage is 3, and no deficits exist.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: to request a new tool, MCP server, skill, or custom integration. It uses a specific verb ('Request') and identifies the exact resources, distinguishing it from sibling tools like lyzr_create_tool or lyzr_create_mcp_server which directly create entities.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is used when you want to request something rather than create it directly, but it does not explicitly state when to use it versus alternatives like create_tool or create_mcp_server. It provides no when-not-to-use guidance, so the usage context is only implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_delete_aci_configurationA
  3.6/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the agent knows this is a destructive, non-read-only operation. The description adds no extra behavioral context such as irreversibility, cascade effects, or required permissions, so it adds no value beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that clearly states the action, resource, and required parameter. No unnecessary words or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete operation with one parameter and no output schema, the description is largely sufficient. Annotations fill in the safety profile (destructive, idempotent). It could mention permanence or typical success response, but the simplicity and annotations make it fairly complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage with a clear description of app_id ('The ACI app id whose configuration to delete'). The tool description also mentions 'by app id', but adds no additional semantic detail beyond what the schema already states.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Delete') and identifies the resource ('ACI app configuration') plus the required identifier ('by app id'). It clearly distinguishes from sibling tools like create and list configurations, and from other delete tools like delete_aci_connection.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The usage is implied: the tool is for deleting an ACI app configuration, and sibling names (create/list) suggest the lifecycle. However, there is no explicit guidance on when to use this over other delete-related tools (e.g., delete_aci_connection) or what prerequisites or permanent consequences exist.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_delete_composio_connectionA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds no additional behavioral context beyond the delete action itself, such as irreversibility or effects on dependent resources, but it is consistent with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single short sentence that directly communicates the tool's function. There is no superfluous text or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter delete operation with strong annotations, the description covers the essential purpose. It does not mention edge cases like behavior on non-existent IDs, but given the low complexity, the description is sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with the single parameter 'connection_id' explicitly described as 'Composio connection id'. The description's 'by id' adds no new meaning beyond what the schema provides, so a baseline score is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Delete'), the resource ('Composio connection'), and the scope ('by id'). It is specific enough to distinguish from sibling tools like lyzr_delete_aci_connection or lyzr_delete_composio_auth_config.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives, or any prerequisites such as needing an existing connection. The description is purely declarative without contextual usage cues.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_delete_contextA
  3.6/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare destructiveHint=true and readOnlyHint=false, so the destructive nature is known. The description adds only the word 'permanently', which is essentially redundant with destructiveHint. It does not disclose any additional behavioral details such as side effects on associated resources, permission requirements, or irreversibility beyond what the annotation implies.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence: 'Permanently delete a context by id.' It contains zero wasted words, clearly conveys the action, and is easily parsable for an AI agent.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple single-parameter destructive tool with clear annotations. No output schema exists, but for a delete operation the response semantics are often straightforward. The description covers the essential purpose and permanence, and the sibling tools provide surrounding context. It is complete enough for the tool's complexity, though it could have mentioned expected response behavior.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides 100% coverage with a clear description for context_id ('Context id'), so the schema carries the heavy lifting. The description merely restates 'by id' without adding any new semantic detail about the parameter's format, source, or usage. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'delete' with a clear resource 'context' and the exact identifier ('by id'). It clearly distinguishes from sibling tools like create, update, list, and get contexts, making the tool's purpose unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use the tool (when you have a context_id and need to delete it), but it does not explicitly mention alternatives or exclusions. No guidance is given on when not to use it (e.g., versus updating or deactivating), but the simple nature of the operation makes the context reasonably clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_delete_mcp_serverA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already disclose destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description adds no extra behavioral context (e.g., irreversibility, associated resources affected), but it does align with the annotations. The bar is lower due to rich annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence with no filler words. It communicates the essential action and resource effectively.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple delete tool with one parameter and rich annotations. The description, combined with the schema and annotations, provides enough context for an agent to select and invoke the tool. There is no output schema, but the tool's purpose is straightforward.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage for the single parameter 'server_id', describing it as 'MCP server id'. The description adds no additional parameter meaning, but the schema already provides sufficient information, so a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action 'Delete' and the target resource 'a registered MCP server'. This is specific and unambiguous, distinguishing it from other sibling tools like list or create MCP server 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/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or consequences. The description simply states what it does without contextualizing the appropriate use case.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_delete_provider_credentialA
  3.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description adds the word 'permanently', which emphasizes irreversibility and provides context beyond the raw annotations. It does not contradict annotations and offers useful behavioral context for a destructive operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence, front-loaded with the action, and contains no extraneous words. It is perfectly sized for a simple delete operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple one-parameter delete tool with comprehensive annotations and no output schema. The description, combined with the schema and annotations, provides adequate context for an agent to select and invoke the tool. It does not elaborate on success/failure behavior or prerequisites, but these are not essential for task selection.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with credential_id described as 'The credential id to delete'. The description's 'by id' matches the schema but adds no new meaning. Since the schema fully documents the parameter, a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (permanently delete) and resource (provider credential) with the identifier method (by id). It is specific but does not explicitly distinguish from sibling tools like lyzr_credential_delete or lyzr_delete_tool_credential, though the resource type is named.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. With many credential-related delete tools among siblings, a note specifying that this is for provider credentials and not other credential types would be helpful. The description only states what it does, not when to choose it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_execute_toolA
  3.6/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already indicate this is not read-only, open-world, and not idempotent, but the description adds no extra behavioral context. It fails to disclose that the tool can invoke arbitrary tools with potentially side effects, what the return might be, or any risk/care advice.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no fluff. Every word contributes to purpose and usage context, making it highly concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a meta-tool that dynamically executes other tools, yet the description only gives the bare minimum. There is no output schema, and the description does not mention return value, tool name lookup, or example usage. It leaves the agent without enough context to predict behavior.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides 100% descriptions for all parameters, so the baseline is 3. The description's phrase 'optional tool configs' slightly clarifies tool_configs, but it does not add any further parameter-level meaning.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool executes a named tool directly with optional configs. It distinguishes itself from sibling chat/task tools by emphasizing 'without a full chat turn,' making the purpose very specific.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides the clear context that this is for direct tool execution as opposed to a full chat turn. However, it does not explicitly name alternative tools or exclusions, so it just misses the top tier.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_a2a_agentA
  3.6/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations (readOnlyHint, idempotentHint, destructiveHint) already cover the safety profile, so the description only needs to add extra behavioral context. It does not disclose error behavior, return shape, or other implementation details beyond 'registered'. The description largely restates the tool's name and schema, offering minimal added value.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence of 8 words: 'Fetch a registered A2A agent record by id.' It conveys the action, resource, and scope with zero waste.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only getter with one fully documented parameter and comprehensive annotations, the description is nearly complete. It states the resource and lookup key, and 'record' implies the full agent object, distinguishing it from card getters. However, the lack of an output schema and any mention of return format or error conditions prevents a perfect score.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already documents the only parameter 'agent_id' with a clear description ('The A2A agent id'), and schema description coverage is 100%. The tool description adds no new meaning beyond confirming the lookup is by id, so the baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Fetch' and identifies the resource as 'a registered A2A agent record' accessed by id. This clearly distinguishes it from sibling tools like list, create, update, delete, and even the card getter 'get_a2a_agent_card'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'by id' implies the tool is for fetching a specific agent when its id is known, but it does not explicitly state when to use it instead of alternatives like lyzr_list_a2a_agents or lyzr_get_a2a_agent_card. No exclusions or alternative guidance is provided; usage context is implied rather than stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_agent_evalA
  3.6/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. However, the description adds no behavioral context beyond what the annotations and schema already provide—no mention of return format, error conditions, or behavior when the agent does not exist.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, concise sentence that immediately states the tool's purpose. No filler, no repetition, and appropriately front-loaded for an agent to parse quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only retrieval tool with one parameter, rich annotations, and no output schema, the description is mostly sufficient. It leaves some ambiguity about what 'eval configs' includes, but no additional complexity requires more explanation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with the 'agent_id' parameter having a clear description ('Agent id whose evals to fetch'). The tool description adds no extra semantic detail beyond restating that it is for a given agent, so it does not improve on the schema. Baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get'), identifies the resource ('agent evaluation configs'), and scopes it to a given agent. It clearly distinguishes from sibling tools like lyzr_create_agent_eval and lyzr_get_agent_eval_result by referencing 'configs' rather than results or creation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use the tool (when you need an agent's eval configs) but does not explicitly state exclusions or alternatives. No guidance is given about when to prefer this over lyzr_get_agent_eval_result or other eval-related tools, leaving the agent to infer from the name and sibling list.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_asset_parse_statusA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, covering safety and repeatability. The description adds no behavioral context beyond the simple lookup and does not contradict the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, direct sentence with no filler. It is front-loaded with the action and resource, making it easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter status query with strong annotations (read-only, idempotent), the description is sufficiently complete. It does not mention possible return statuses, but the low complexity and schema coverage make this acceptable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage for asset_id with a clear description. The tool description only repeats 'by id' without adding further meaning, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Get the parsing status of an asset by id' clearly identifies the action (get), the resource (parsing status of an asset), and the key qualifier (by id). It distinguishes from sibling tools like lyzr_get_asset or lyzr_get_asset_raw by narrowing to the parse-specific status.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives, such as how it relates to the parse_* tools or when status checking is appropriate. There are no mentions of exclusions, prerequisites, or preferred contexts.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_cached_creditsA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds that the result is 'cached' and 'keyed by resource/action,' which is useful context. However, it does not disclose potential staleness or how to refresh, but that is not contradictory.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, compact sentence that is front-loaded with the action verb 'Fetch' and directly states the object. Every word earns its place with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's low complexity (zero required parameters, no output schema, no nested objects), the description sufficiently conveys the core purpose. It could optionally mention that the data is cached and refreshable, but for a simple getter it is largely complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for the single optional parameter x_server_token, described as 'Optional server-to-server auth token.' The tool description adds no additional parameter meaning beyond the schema, so the baseline score of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Fetch' and identifies the exact resource: the 'cached credit-cost map keyed by resource/action.' This clearly distinguishes it from sibling tools such as lyzr_refresh_credit_cache, which performs a different operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance is given on when to use this tool versus alternatives like lyzr_refresh_credit_cache. The description implies it is for reading cached credit costs, but there is no mention of exclusions or alternative tools, leaving the agent to infer usage on its own.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_composio_action_limitA
  3.6/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. The description adds no additional behavioral context such as return format, authentication needs, or rate limits, essentially restating the tool's purpose without going beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence with no redundant words. It communicates the essential action immediately and contains zero filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a parameterless, read-only getter with strong annotations, this description is adequately complete. The only minor gap is that it doesn't specify the exact structure of the returned data (e.g., usage vs. limit separately), but the tool's simplicity and annotations compensate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the description need not explain any input semantics. The baseline of 4 for zero-parameter tools applies, and the description correctly avoids inventing parameter details.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states this tool retrieves the current Composio action usage/limit, using a specific verb ('Get') and a specific resource. It is distinct from sibling tools like lyzr_get_composio_auth_config, which handles auth configuration rather than action limits.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool or how it compares to alternatives. There is no mention of scenarios like checking quota before running actions or monitoring usage, leaving the agent without context for selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_skill_usageA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations fully cover the safety profile (read-only, idempotent, non-destructive). The description itself adds no behavioral context beyond what annotations already imply, such as what the usage stats include or how they are aggregated. It does not contradict annotations, but provides minimal additional value.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single clear sentence, front-loaded with the action and resource. Every word earns its place; there is no verbosity or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (one parameter, clear read-only purpose, full annotations), the description is mostly sufficient. However, it leaves ambiguity about what the usage statistics contain (e.g., call counts, tokens, time range) and could benefit from a brief clarification of the return data.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% for the single parameter skill_id, so the schema already documents it adequately. The description adds no new semantic detail beyond referencing 'a given skill', which maps directly to the parameter. Baseline 3 is appropriate given high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (get), the resource (usage statistics), and the target (a given skill). It distinguishes itself from other usage-related siblings by specifying 'skill' as the resource, differentiating it from report_usage_by_model, report_usage_by_agent, etc.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus other usage-tracking tools like lyzr_report_usage_by_agent or lyzr_report_usage_by_model. The description implies a use case but does not explicitly state prerequisites, exclusions, or alternatives, which is problematic given the large sibling list.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_trace_summaryA
  3.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by specifying the summary contents (agent, LLM, tool call, token, cost), which clarifies what the returned data covers, though it does not describe response format or error cases.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Single sentence with no filler; every word contributes meaning. The parenthetical list efficiently communicates the summary's scope.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Simple one-parameter read operation with strong annotations; the description enumerates the summary's content areas, which compensates for the lack of an output schema. It doesn't address selection criteria, but that's captured in the usage dimension.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema fully documents the single trace_id parameter with a description, and the description does not provide additional syntax or format details. Baseline 3 applies due to 100% schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Fetch' and identifies the resource as the detailed summary for a trace, listing included data categories (agent, LLM, tool call, token, cost). It is clear but does not explicitly differentiate from sibling tools like lyzr_get_trace_details, which is a close alternative.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives; it only states what the tool does. Sibling tools such as lyzr_get_trace_details and lyzr_get_trace_gantt exist but are never mentioned, leaving the agent to infer selection criteria.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_workflowA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no additional behavioral context, such as behavior when the id is not found or what the response contains.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence of six words, front-loaded and free of any wasted text. Every word contributes to understanding the tool's purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple single-parameter read operation with strong annotations, the description is sufficient. There is no output schema, so the absence of return-value details is acceptable, and the tool's purpose is clear without further elaboration.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage with flow_id described as 'The workflow id'. The description adds no extra meaning beyond this, so the baseline score of 3 is appropriate when the schema already documents the parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Fetch a workflow by id' uses a specific verb (fetch), names the resource (workflow), and indicates the scope (by id). This clearly distinguishes it from sibling tools like lyzr_list_workflows, which would list multiple workflows.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided about when to use this tool versus alternatives such as lyzr_list_workflows or lyzr_get_workflow for other purposes. The description only states the action, leaving the agent to infer appropriate 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.

• lyzr_git_disconnectA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and idempotentHint=true, covering the safety profile. The description adds no extra context about side effects, reversibility, or the purge behavior; the purge parameter is only documented in the schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that immediately states the tool's action without any fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple two-parameter schema, full schema coverage, and strong annotations, the description is largely complete. It could mention the optional purge behavior, but that is already captured in the schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema fully documents both parameters. The description itself adds no parameter-level meaning, which is acceptable given the high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Disconnect') with a clear resource ('git integration for an agent'), making the tool's purpose unambiguous and distinct from sibling git tools like init, status, or branch 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/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. It does not mention relationships to other git tools, prerequisites, or scenarios where disconnecting would be appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_git_get_governanceA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare the tool as read-only, idempotent, and non-destructive, so the description does not need to repeat those. It adds little behavioral context beyond the annotations—no mention of behavior if the repo is not configured or error conditions—but it does not contradict the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that immediately communicates the tool's purpose. It contains no filler or redundant content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple getter with one parameter, good annotations, and no output schema, this description sufficiently conveys the return concept (governance policy). It could be slightly more detailed about the policy's structure or edge cases, but overall it is adequate for the tool's complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% for the single parameter agent_id, whose description ('Agent id') is self-explanatory. The description adds no additional semantic information about the parameter beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Get'), the resource ('governance policy'), and the scope ('for an agent's git repo'). It distinguishes from sibling tools like git_save_governance, git_delete_governance, and git_sync_governance by focusing on reading the policy.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given on when to use this tool versus alternatives, such as git_save_governance for modifying policy or git_sync_governance for syncing. The context implies a read operation, but explicit usage conditions or exclusions are absent.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_git_update_reviewersA
  3.6/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description simply states 'update' without disclosing important behavioral traits such as whether the update replaces the existing list or appends to it, whether the repo must already be initialized, or any side effects. Annotations indicate readOnlyHint=false and destructiveHint=false, but the description adds little beyond what annotations already imply.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence that front-loads the action and resource. It contains no redundant or unnecessary words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple 2-parameter mutation tool with fully documented schema and no output schema, the description provides sufficient context to understand the primary operation. However, it lacks explicit mention of whether the change is a replacement or merge, which would add completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Both parameters (agent_id and reviewers) are documented in the input schema with descriptions ('Agent id' and 'List of reviewer usernames'). The tool description does not add any further parameter semantics or clarify formats, so it meets the baseline for full schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'update' and clearly identifies the resource: the list of reviewers for an agent's git repo. This distinguishes it from sibling git tools like init, get_status, and create_pr, which serve different purposes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: use this tool when you want to update the reviewers list for an agent's repo. However, it provides no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives, which is acceptable given the tool's uniqueness but leaves some room for ambiguity.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kbsync_connector_updateA
  3.6/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already indicate this is a write operation with idempotency and non-destructive behavior. The description adds no further context about side effects, partial updates, or return values, providing minimal value beyond what the annotations already convey.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence of nine words, front-loaded with the verb and resource. It is appropriately sized for the tool's simplicity and contains no unnecessary information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple CRUD operation, full schema coverage, and comprehensive annotations, the description is adequate. It lacks information about return values or effects on existing connectors, but the overall context is sufficient for an agent to select and use the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides full descriptions for all four parameters (connector_id, name, disabled, connector_specific_config). The description's mention of 'name, config, or disabled state' merely summarizes the schema without adding additional semantics or examples, so it meets the baseline for full schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (update), the resource (KB Sync connector), and the specific attributes that can be changed (name, config, disabled state). This distinguishes it from sibling tools like create, get, list, and delete.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not explicitly say when to use this tool versus alternatives, such as using create for new connectors or get to read current state. It relies on the tool name and context to imply its usage, which is clear but not explicitly stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kb_train_xlsxA
  3.6/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already convey readOnlyHint=false and idempotentHint=false, so the description adds no additional behavioral disclosure. It omits important details like whether existing KB content is replaced, whether training is asynchronous, or any file size or processing constraints. It merely restates the obvious action.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that is front-loaded and free of filler. Every word contributes to identifying the action and target, making it highly concise and well structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having 8 parameters and no output schema, the description provides only a minimal statement. It does not clarify what the tool returns, whether training is synchronous, or how it affects existing knowledge base state. Annotations cover mutation status but not operational expectations, leaving significant gaps for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage with descriptions for all 8 parameters, including chunk_size, chunk_overlap, and parser_config. The description adds no further parameter-level meaning beyond the file type, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb and resource: 'Upload and train an XLSX spreadsheet into a knowledge base.' The XLSX target differentiates it from siblings like lyzr_kb_train_text and lyzr_kb_train_website, making purpose 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/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description makes the use case clear: it is for training an XLSX spreadsheet into a knowledge base. It does not explicitly mention alternatives or say when not to use it, but the XLSX-specific context is strong enough to guide selection among the sibling train tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kg_ext_train_file_task_neo4jA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate non-read-only, open-world, non-idempotent, and non-destructive behavior. The description adds the async execution trait, which is useful, but does not disclose side effects, return format, or how to track the task. It provides some context beyond annotations but remains limited.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that front-loads the core action. Every word contributes, with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For an async task with no output schema, the description does not explain what the caller should expect after submission (e.g., task ID, status polling) or mention companion status tools. This is a significant gap for a tool that trains a graph asynchronously.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so parameters are already well-documented. The description mentions 'file (base64-encoded)' corresponding to file_content_base64, but does not add additional semantic value beyond what the schema provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: uploading a base64-encoded file to train a Neo4j knowledge graph. It specifies the async nature and 'namespaced endpoint', which helps distinguish it from synchronous or non-Neo4j variants 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/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context (async training from file to Neo4j) but does not explicitly mention when to use this over alternatives like synchronous training or text/website training. No exclusions or alternative tool references are provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kg_train_websiteA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With annotations already indicating readOnlyHint=false and destructiveHint=false, the description adds minimal behavioral context beyond what is already known. It confirms the write operation (ingest) and mentions the v4 knowledge graph, but does not disclose potential long-running behavior, asynchronous execution, or effects on existing graph data. No contradiction with annotations 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence with no redundant words, front-loading the key action. It is appropriately sized for the simple purpose, though it could include more usage guidance without fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given 11 parameters and no output schema, this description is too minimal. It does not explain what the tool returns (e.g., a task ID or status), nor does it provide guidance on optional crawling parameters like max_crawl_depth or dynamic_content_wait_secs. The agent must rely on sparse schema descriptions and external knowledge to use the tool effectively.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All 11 parameters have schema descriptions, achieving 100% schema coverage, so the description does not need to repeat parameter details. The description omits any additional meaning about parameters such as defaults, units, or when to use optional fields like max_crawl_depth or chunk_size, but the schema already carries the burden.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool crawls and ingests URLs into the v4 knowledge graph, distinguishing it from sibling tools like lyzr_kb_train_website (which targets a knowledge base, not a knowledge graph) and lyzr_kg_train_text (which ingests text, not URLs). The verb 'crawl and ingest' is specific and the resource is explicit.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this tool is for training a knowledge graph from website URLs, but it does not explicitly differentiate from alternatives such as lyzr_kg_ext_train_website_neo4j or clarify when to choose this over lyzr_kg_train_text. No usage context or exclusions are provided, leaving the agent to infer usage from the tool name.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_list_channelsA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds no further behavioral context such as return format, pagination, or error conditions. It is consistent with annotations, but not information-rich beyond them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence that front-loads the verb and resource. There is no filler, repetition, or unnecessary detail. It is appropriately sized for the tool's simplicity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list operation with one parameter and strong annotations, the description is mostly complete. However, it does not state the shape of the response (e.g., array of channel configurations) and does not explicitly note that it only returns configurations for the specified agent beyond the parameter description. This modest gap prevents a perfect score.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% with agent_id already described as 'Agent id whose channels to list'. The tool description adds no additional meaning to the parameter, but the schema does the heavy lifting, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'List channel configurations for a given agent' clearly states the verb (list), resource (channel configurations), and scope (for a given agent). It distinguishes from the sibling tool lyzr_list_all_channels by indicating this is agent-scoped, making it specific and non-tautological.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives like lyzr_list_all_channels or lyzr_create_channel. There is no mention of exclusions, prerequisites, or alternative selection, leaving the agent without sufficient direction for tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_list_contextsA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds the pagination behavior, which is useful but does not disclose other behavioral aspects like default ordering, scope, or whether all contexts are returned. This is adequate but not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise with a single sentence that communicates the essential function and a key feature (pagination). There is zero redundancy or filler, and the information is front-loaded. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list operation with comprehensive schema descriptions and clear annotations, the description is mostly complete. It could optionally mention what the response contains (e.g., context metadata) or default ordering, but these are not critical given the tool's simplicity and the schema's clarity. The pagination note covers the main complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage with clear descriptions for 'skip' and 'limit', including defaults and max values. The description's mention of pagination aligns with these parameters but adds no additional semantic meaning. Baseline 3 is appropriate given the schema handles parameter documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'List' and a clear resource 'contexts', which precisely identifies the operation. It distinguishes from sibling tools like get_context, create_context, and update_context by indicating a collection listing operation. The phrase 'with pagination' further clarifies the scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives such as get_context or get_contexts_count. There is no mention of use cases, exclusions, or preferred scenarios. The agent must infer usage solely from the name and title, which is insufficient given the large sibling set.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_list_org_agentsA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds the org-wide scope and optional search/pagination, but does not disclose return format, potential pagination behavior, or authorization requirements, so it adds only modest context beyond annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, well-structured sentence that front-loads the core action and scope. Every word contributes value, with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list operation with well-documented parameters and supportive annotations, the description is largely complete. However, since there is no output schema, a brief note about the return type or content (e.g., agent objects with metadata) would strengthen completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers all three parameters (page, limit, search) with 100% description coverage, including defaults and types. The description merely restates that search and pagination are optional, adding no new semantic meaning beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb and resource: 'List agents across the organization,' which clearly identifies the operation and scope. The 'across the organization' phrase helps differentiate it from the sibling tool `lyzr_list_agents`, which likely handles user-scoped listing.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not explicitly state when to use this tool versus alternatives like `lyzr_list_agents`. It implies org-wide listing but provides no exclusions, prerequisites, or comparative guidance, leaving the agent to infer the appropriate context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_list_session_audit_logsA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is clear. The description adds minimal extra context: it confirms the scope is a single session ID. However, it does not disclose pagination behavior, ordering, or whether the session must exist, which are useful behavioral details. With strong annotations, the bar is lower, but the description still adds some value.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence, 'Get audit logs for a specific session ID.' It is extremely concise, with no filler or redundancy. Every word contributes to the purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite the concise description, the tool is simple and the schema plus annotations provide substantial context. The 100% parameter documentation and readOnly/idempotent hints cover the essential details. The main missing piece is explicit guidance on how this relates to other audit list tools, but that falls under usage guidelines. Given the tool's simplicity, the description is nearly complete, though a brief note on return format would have made it fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with each parameter (session_id, limit, offset) having a description. The description adds no additional meaning beyond what the schema already provides, so the baseline 3 applies. It does reinforce that session_id is the key filter, but that is already in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Get') and the specific resource ('audit logs for a specific session ID'). This distinguishes it from sibling audit log tools like lyzr_list_org_audit_logs or lyzr_list_user_audit_logs by emphasizing the session-scoped focus.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus the many sibling audit log tools (e.g., org, user, resource-level logs). It does not mention exclusions or alternatives, leaving the agent to infer the intended use case from the session-specific wording alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_livesource_ext_browse_sitesA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations (readOnlyHint, openWorldHint, idempotentHint) already establish the safe, read-only nature. The description adds minimal behavioral context (the use of a stored credential), but does not disclose potential error conditions, rate limits, or return format. It does not contradict annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, short sentence that is front-loaded with the action and resource. Every word earns its place, with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter read-only tool with rich annotations, the description is mostly adequate. It names the action and resource, but could mention the response shape or the relationship to sibling browse tools. Since there is no output schema, a bit more detail about what is returned would improve completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 100% description coverage for the single parameter credential_id, so the baseline is 3. The description's mention of 'stored credential' adds a small amount of context but does not explain the format or expected values beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'List' and the resource 'SharePoint sites accessible via a stored credential'. This distinguishes it from sibling tools like browse_drives and browse_children, which operate on different resources.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention typical workflows (e.g., use this to enumerate sites before browsing drives) or exclusions. The usage is only implied by the tool's name and description.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_memprovider_get_providerA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. The description adds the behavioral detail that the operation returns a single provider (not a list), but does not disclose error behavior or return format.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One concise, front-loaded sentence with no redundant words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter read-only fetch with strong annotations, the description covers the essential purpose and parameter. It might mention what is returned, but given the simplicity and sibling context, it is nearly complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description's 'by id' merely restates the schema's provider_id description, and schema coverage is 100%, so no additional semantic value is added.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Fetch'), identifies the resource ('memory provider'), and specifies the scope ('single ... by id'), clearly distinguishing from list operations and the generic get_provider via the tool name prefix.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided about when to use this tool versus alternatives such as lyzr_memprovider_list_providers or how to obtain the provider_id. The purpose is implied but no explicit usage context or exclusions are given.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_ops_get_agent_tool_logsA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare the operation as read-only, idempotent, and open-world, so the safety profile is covered. The description adds only the phrase 'combination' to indicate all four IDs are required together, which is a minor scoping note but does not disclose additional behavioral traits like response shape 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence—'Fetch agent tool logs for a trace/run/log/feature combination.' It is succinct, contains no filler, and every word contributes to the tool's purpose, making it highly efficient for an agent to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only fetch with four straightforward string parameters and no output schema, the description is largely adequate. However, the term 'feature' is ambiguous and it is not clarified whether the call returns a list or a single object, so a bit more context would push it to a 5.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides descriptions for all four parameters (Trace id, Run id, Log id, Feature name), giving 100% schema coverage. The description's mention of 'trace/run/log/feature combination' essentially restates the required parameter set without introducing meaningful semantics beyond the schema's required array, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Fetch' and clearly identifies the resource as 'agent tool logs,' scoped by a 'trace/run/log/feature combination.' This is specific enough to distinguish it from sibling tools like lyzr_ops_get_trace_run or lyzr_ops_get_grouped_logs, which target different levels of log/trace detail.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives no explicit guidance on when to use this tool versus alternatives such as lyzr_ops_get_trace_run or lyzr_ops_get_grouped_logs. It lacks any mention of prerequisites, exclusions, or recommended scenarios, leaving the agent to infer usage solely from the tool name.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_ops_get_tracesA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety and side-effect expectations. The description adds the filtering constraint (by agent and date range), which provides some useful context beyond annotations, but it does not disclose return format, pagination behavior, or ordering, though the schema covers pagination parameters.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is 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 action, resource, and key optional filters in a scannable format.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list operation with 100% schema coverage and strong annotations, the description is largely complete. It covers the core purpose and filter capabilities, and the schema handles parameters. Minor gaps: no mention of pagination or output format, but these are common for list tools and not critical. Given the presence of many trace-related siblings, a bit more differentiation would improve completeness, but it is not severely deficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% with each parameter having a clear description. The main description adds a high-level summary of filtering (agent and date range) but does not provide additional meaning beyond what the schema already states. Baseline 3 is appropriate given the full schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the action ('List'), the resource ('execution traces'), and the optional filtering scope ('by agent and date range'). This distinguishes it from non-list tools, but it does not explicitly differentiate from sibling tools like `lyzr_list_traces` or `lyzr_get_trace_details`, so it falls short of a perfect score.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies use when listing execution traces with optional filters, providing clear context. However, it offers no explicit guidance on when to use this tool versus alternative trace-related tools (e.g., `lyzr_get_trace`, `lyzr_get_trace_summary`), nor any exclusions or prerequisites.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_rag_get_doc_contentA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already communicate read-only, idempotent, and open-world behavior, lowering the burden on the description. The description adds that content is chunk-based and scoped to one source, but it does not clarify behavior around the limit parameter (e.g., truncation, pagination, or the exact return shape), which would add value beyond the schema and annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler. Every word contributes to identifying the action and resource, making it highly concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only retrieval tool with complete parameter documentation and safety annotations, this description is largely sufficient. It could specify the return structure or pagination semantics in more detail, but the tool's simplicity and the schema's completeness make this a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already documents all three parameters clearly. The description adds no parameter-specific detail beyond reinforcing that the result is stored content chunks; it does not compensate for or improve upon the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and clearly identifies the resource: 'full stored content (chunks) of a single document source in a knowledge base.' It is unambiguous and distinct from adjacent knowledge-base operations, though it does not explicitly name a sibling tool such as lyzr_kb_list_documents or lyzr_kb_query.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the intended use case (retrieving full chunk content for one exact document source) but provides no explicit guidance on when to use this tool versus alternatives. It neither names alternatives nor states exclusions, so the usage context is only implied by the wording.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_rai_get_policyA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and idempotentHint=true, so the description's 'fetch' is consistent and safe. However, it adds no extra behavioral context such as error handling, return format, or prerequisites beyond what annotations provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single short sentence that is front-loaded with the action and resource. There is no wasted wording.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read operation with strong annotations, the description is minimally viable. However, with no output schema, it does not state what the response contains or mention not-found behavior, leaving some gaps for the agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0% and the description does not compensate. It merely echoes 'by id' without explaining what policy_id is, its format, or how to obtain it. The parameter is self-explanatory by name, but the description adds no meaningful semantic enrichment.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Fetch a guardrail policy by id' uses a specific verb (fetch) and identifies the resource (guardrail policy) and scope (by id), clearly distinguishing it from sibling tools like create, delete, and list.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The usage context is implied—use when you need a single policy by ID—but there is no explicit mention of when not to use it or reference to alternatives like lyzr_rai_list_policies. It does not exclude other tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_reassign_agentA
  3.6/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate a non-read-only statement (readOnlyHint=false) and non-destructive operation (destructiveHint=false). The description adds no behavioral context beyond that: it does not disclose side effects like the previous owner losing access, whether the target email must be an existing user, or any validation. Since nothing new is added over the annotations, the score is low.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence, front-loaded with the action and specific target. It contains zero waste and is immediately comprehensible.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter mutation tool with annotations and full schema coverage, the description is complete enough. It clearly states the operation and the key parameters. However, it could mention side effects (e.g., the original owner is removed), but given the low complexity and existing annotations, it is adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with clear descriptions for both parameters ('The agent_id to reassign' and 'Email address of the new owner'). The description matches this but does not add extra semantic meaning beyond naming the target mechanism (by email), which the schema already conveys. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Reassign ownership of an agent to another user by email.' The verb 'reassign' is specific, the resource is identified ('agent'), and the target is defined ('another user by email'). This distinguishes it from sibling tools like lyzr_create_agent or lyzr_update_agent.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use this tool (when you need to transfer agent ownership), but it does not explicitly state when to use it versus alternatives, nor does it mention prerequisites or exclusions. There is no guidance about using this instead of lyzr_update_agent for ownership changes.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_schedule_getA
  3.6/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description 'Fetch a schedule by id' adds no additional behavioral context beyond what the annotations provide, such as return format, error behavior for non-existent IDs, or any side effects. With annotations present, the description carries little extra value.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single succinct sentence with no filler or redundancy. It fully captures the tool's primary action in minimal words, which is ideal for a simple retrieval operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (one parameter, no nested objects, no output schema), the description is mostly adequate. Annotations cover the read-only and idempotent behavior, so the main gap is the lack of information about what the returned schedule object contains or what happens if the ID does not exist. However, for a basic get-by-id tool, this is acceptable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has one parameter (schedule_id) with 0% description coverage. The description mentions 'by id', which clarifies that schedule_id is the schedule's identifier, but this is redundant with the parameter name. It does not explain the ID format, whether it is a UUID, how to obtain it, or any constraints beyond being a string.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Fetch a schedule by id' uses a specific verb (fetch) and resource (schedule), clearly indicating a single-item retrieval. This distinguishes it from sibling tools like lyzr_schedule_list (which lists schedules) and lyzr_schedule_create (which creates schedules), as the 'by id' phrase implies targeted lookup.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this tool should be used when you have a specific schedule_id to retrieve a schedule. However, it provides no explicit guidance on when to use it versus alternatives like lyzr_schedule_list to discover the ID first, nor does it mention any exclusions or prerequisites.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_session3_listA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only, idempotent, and open-world hints, so the safety profile is covered. The description adds minimal behavioral context: it mentions filtering by 'agent or source,' which aligns with parameters, but does not explain return behavior, ordering, or pagination (beyond schema hints). It does not contradict annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no fluff. Every word earns its place, efficiently conveying the core purpose and optional filters.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the rich sibling context (many session-related tools) and lack of an output schema, the description is too terse. It fails to explain what a 'v3 session' is, what 'source' refers to, or what the response format contains, leaving significant ambiguity for an agent attempting to invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema fully documents all four parameters (limit, offset, source, agent_id). The description adds no new semantic detail beyond what the schema already provides, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'List v3 sessions, optionally filtered by agent or source.' This provides a specific verb ('List'), a clear resource ('v3 sessions'), and unique differentiators (optional filters), distinguishing it from sibling tools like session3_list_messages or session3_get.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage (list v3 sessions with filters) but does not provide explicit when-to-use guidance relative to sibling tools, nor does it state exclusions or alternatives. It is not misleading, but it lacks direct comparative context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_session3_list_branchesA
  3.6/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, so the safety profile is covered. However, the description adds no extra behavioral context beyond what the name and annotations imply—no mention of branch ordering, whether nested branches are included, or the return format. It is purely a restatement of the tool's purpose.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that states exactly what the tool does with no redundant words or filler. Every word earns its place, making it highly concise and scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list operation with one parameter and strong annotations, the description is complete enough: it names the exact resource and version. However, the absence of an output schema and any description of the returned branch representation leaves a minor gap, preventing a perfect score.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully describes the single required parameter 'session_id' with the description 'Session id' (100% coverage). The tool description does not add any further meaning to the parameter beyond the schema, so it meets the baseline for schema-heavy coverage but does not exceed it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'List the branches created from a v3 session' uses a specific verb (list) and resource (branches from a v3 session), clearly distinguishing itself from general session tools like lyzr_session3_get or lyzr_session3_list_messages. The version qualifier 'v3' also differentiates it from non-v3 session tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies its use case (to enumerate branches of a v3 session) but provides no explicit guidance on when to prefer it over related tools such as lyzr_session3_tree or lyzr_session3_ancestry. There are no exclusions or alternative tool mentions, leaving the agent to infer contextual fit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_update_contextA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate the tool is non-readOnly, non-destructive, and idempotent. The description adds that updates can be partial ('name and/or value'), which is useful beyond the schema, but it does not disclose behavior for missing context IDs, error responses, or side effects beyond what annotations cover.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that immediately states the action, the target, and the key parameters. Every word earns its place with no unnecessary detail or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple update tool with a fully documented schema and safety-related annotations, the description is mostly complete. It could mention that the context must already exist or how to obtain the context_id, but these are implied by the 'by id' phrasing and the required parameter, so the gap is minor.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and each parameter is already described. The description adds a bit of semantic grouping by showing that 'name' and 'value' are the updatable fields and that they can be used in combination ('and/or'), but this largely mirrors the schema's optional field indications.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Update' with the resource 'context' and the specific fields affected ('name and/or value') plus the lookup key ('by id'). This distinguishes it from sibling context tools (create, get, list, delete) and makes the tool's sole purpose 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/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus create or delete, nor any prerequisite that the context must already exist. The description merely states what it does, leaving the agent to infer that it is for modifying an existing context based on the tool's name and siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_upload_assetA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already establish this as a non-read, non-idempotent write operation. The description adds the base64 transport requirement and the RAG parsing side effect, which are useful beyond annotations. However, it does not disclose whether parsing is asynchronous (lyzr_get_asset_parse_status suggests it is), whether upload credentials are required, or what the response contains.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, roughly 22 words, with the primary purpose front-loaded and the critical base64-encoding requirement stated in the second sentence. Every word earns its place; there is no repetition of schema details or annotation information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a complex tool (12 params, 11 optional parsing controls) with no output schema, yet the description explains neither the return value (e.g., asset IDs/parse status) nor how to track an async parse. It also offers no guidance on navigating the many parsing options (page ranges, VLM providers, chunking strategies) or follow-up steps like polling lyzr_get_asset_parse_status. The schema's per-parameter descriptions help, but the operational flow is left for the agent to infer.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 100% schema description coverage, the baseline is 3; the schema already documents all 12 parameters, including the parse_config JSON shape. The description adds marginal value by framing the parse/chunk parameters as optional and RAG-oriented, but terse string params (vlm_model, parsing_mode, parser_provider, chunking_strategy) remain underspecified with no enum choices or examples, and the description does not compensate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Upload') tied to a clear resource ('files as assets') and adds distinctive scope with 'optionally parsing/chunking them for RAG.' This clearly distinguishes it from sibling parse-only tools (lyzr_parse_pdf, lyzr_parse_docx) and KB training tools (lyzr_kb_train_pdf), which handle parsing or training but not asset creation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The RAG parsing mention implies when to use it (ingesting files for RAG workflows), but there are no explicit when-to-use/when-not-to-use instructions or named alternatives among the many siblings. An agent gets no direct guidance on choosing between this and lyzr_kb_train_pdf, lyzr_parse_pdf, or lyzr_kb_train_documents for seemingly similar workflows.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_chat_with_fileA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate openWorldHint, non-read-only, and non-idempotent behavior. The description adds the base64 encoding detail for the file, which is useful, but does not disclose other behavioral aspects such as the optionality of the file or the nature of the response. With annotations present, the added value is moderate, so a score of 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that is front-loaded, specific, and contains no wasted words. It efficiently communicates the core action and the key constraint (base64 file attachment) without unnecessary elaboration.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (10 parameters, no output schema), the description provides the essential action but omits details about the expected return value (e.g., the agent's reply) and does not elaborate on parameter interactions such as file requiring file_name. However, the schema fully documents all parameters and annotations cover side-effect expectations, making the description minimally sufficient but not comprehensive.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage for all 10 parameters. The description's mention of 'base64-encoded content' merely duplicates the schema's file parameter description, providing no additional semantic value. This meets the baseline for a fully documented schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose with a specific verb ('Send') and resource ('chat message to an agent with an attached file'). The modifier '(base64-encoded content)' adds technical clarity, and it distinguishes this tool from siblings like lyzr_chat and lyzr_stream_chat by emphasizing the file attachment.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is used when a chat message must include an attached file, but it does not explicitly state when to use it over alternatives (e.g., lyzr_chat for text-only messages) or provide exclusions. The context is clear but implied rather than spelled out.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_create_a2a_agentA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds minor context by mentioning 'remote agent' but does not disclose whether it validates the URL, fetches the agent card, or what side effects occur. Annotations already indicate a write operation, but no extra behavioral details are provided.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One concise sentence, front-loaded with the verb, no unnecessary words. It is an ideal length for a simple create operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 15 parameters and no output schema, the description is minimal but not entirely inadequate. It does not explain workflow context, such as whether a credential is required upfront or how the agent card is used, leaving some gaps for the agent to infer.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and each parameter already has a description. The tool description does not add meaning beyond what the schema provides, so a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'register' and identifies the resource as an 'A2A agent record', clarifying it points to a remote agent's base URL. This clearly distinguishes it from sibling tools like lyzr_create_agent, which likely handles local agents.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use the tool (registering external A2A agents) but does not explicitly state alternatives or exclusions. No mention of prerequisites like creating a credential first or contrasting with lyzr_create_agent.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_context_usageA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety. The description adds no behavioral context such as what 'usage' includes, return format, or pagination limits. It is consistent with annotations but contributes no additional transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single clear sentence with no waste. It is front-loaded with the action and resource, appropriate for a simple lookup tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Complexity is low and annotations are rich, but the description does not elaborate on what 'usage information' includes or what the response will look like, and there is no output schema. A brief note on the nature of usage (e.g., token counts, credits, requests) would make it more complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: the only parameter 'context_id' is described as 'Context id'. The tool description adds no further meaning, so baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb ('Get'), the resource ('usage information for a context'), and the lookup key ('by id'). This distinguishes it from sibling tools like lyzr_get_context, which presumably retrieves context details, by focusing on 'usage'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage (if you need usage info for a context, use this) but provides no explicit when-to-use guidance or alternatives. It does not mention when to choose this over related tools like lyzr_get_context or lyzr_get_context_value_internal.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_credential_agentsA
  3.7/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which the description does not contradict. However, the description adds no behavioral context beyond the annotations—no mention of output format, pagination, auth requirements, or edge cases—so it provides no extra transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no redundant words. It is concise and easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list operation with two parameters and a clear schema, the description is sufficient. Annotations cover safety and idempotency, and the output schema is not needed to understand the tool's basic behavior.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: both parameters have meaningful descriptions ('Tool credential id' and 'Optional provider id filter'). The tool description itself adds no parameter detail, so the baseline score of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') with a clear resource ('agents') and a condition ('that use a given tool credential'). It distinguishes this from the many credential CRUD and agent management siblings in the tool list.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use the tool (when you need to know which agents are associated with a credential) but does not explicitly state alternatives, prerequisites, or exclusions. It lacks direct guidance on choosing this over other credential-related tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_module_adminA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, covering the safety profile. The description adds minimal context beyond the resource type ('sidebar module') and does not disclose return format, error behavior, or admin-specific requirements. This is acceptable given the strong annotation coverage, but the description adds little beyond what's already known.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that directly states the core action and target. It contains no filler words and is appropriately sized for a simple read operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple get-by-key operation with one parameter and rich annotations, the description is minimally adequate. However, it does not clarify when to choose this admin variant over the many sibling tools, nor does it mention expected return structure. Given the extensive tool list, a bit more context would improve completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with the only parameter 'key' described as 'Module key', so the schema carries the semantic weight. The description's phrase 'by key' aligns with the schema but adds no further detail about the expected value format or constraints.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Fetch a single sidebar module by key' uses a specific verb (fetch), identifies the resource (sidebar module), and clarifies the operation is for a single item by key. This clearly distinguishes it from sibling tools like lyzr_list_modules_admin or lyzr_get_modules, which likely handle listing or multiple modules.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: when you have a module key and need one specific sidebar module, call this tool. However, it does not explicitly name alternatives or state when not to use it, leaving the agent to infer distinctions from sibling names.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_providers_by_typeA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, covering the safety profile. The description adds that results are paginated, which is useful, but does not disclose return structure, default pagination behavior, or what constitutes a provider type.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence, front-loaded with the action and resource. It is appropriately sized for a simple list tool with no wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only list tool with schema-covered parameters and strong annotations, the description is adequate but not fully complete: it lacks an output schema or description of returned fields, and does not clarify the scope of 'providers' relative to other provider-related tools. This could leave an agent uncertain about what a provider is in this context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 100% schema description coverage, all three parameters (provider_type, page, limit) are already documented. The description only reinforces that filtering by type and pagination are the behaviors, adding no new parameter-specific information.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List'), identifies the resource ('providers') and the filtering criterion ('of a given type'), and mentions pagination. This clearly distinguishes it from sibling tools like lyzr_get_provider (single) and lyzr_list_provider_credentials_by_type (credentials).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when you want to enumerate providers filtered by a specific type, but provides no explicit when-to-use vs alternatives or exclusions. It does not mention that lyzr_get_provider exists for single-provider lookup or any criteria for when pagination is needed.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_git_list_repo_filesA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly and idempotent behavior. The description adds the branch optionality, which is a behavioral nuance beyond annotations, but it doesn't mention return format, recursion depth, or default branch behavior. It adds some context but not rich 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, well-structured sentence with no redundant words. Every part earns its place, making it highly concise and front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list tool with good annotations and full schema coverage, the description is adequate but leaves gaps: it doesn't specify what exactly is returned (e.g., file paths, directories), whether the list is recursive, or what happens when branch is omitted. These omissions could lead to incorrect usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with both 'branch' and 'agent_id' already described. The description repeats the branch concept without adding new meaning, so it falls to the baseline for complete schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'List files in an agent's git repo' uses a specific verb and resource, clearly distinguishing from sibling tools like get_file_content or list_commits. The optional branch modifier adds useful 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/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use the tool (to see files in a repo), but provides no explicit guidance about alternatives or exclusions. There's no 'use this instead of X' or when-not-to-use, so it relies on the agent to infer context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_git_restore_commitA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations (readOnlyHint=false, destructiveHint=true) already declare the destructive nature, and the description adds that it targets a specific commit. However, it does not detail what is destroyed (e.g., later commits, uncommitted changes) or whether the restore is irreversible, missing an opportunity to add value beyond annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the low complexity (two parameters) and the presence of destructiveHint in annotations, the description is minimally adequate. However, it omits consequences like loss of uncommitted changes or later commits, and lacks any mention of output or post-conditions, which is a notable gap for a destructive mutation tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptions for both parameters ('Agent id' and 'Commit SHA to restore'). The description itself does not add any further semantic meaning, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific action (restore) on a specific resource (the repo) to a specific state (that of a given commit). This distinguishes it from sibling git tools like list_commits or get_commit_snapshot, which do not modify the repo.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no explicit guidance on when to use this tool versus alternatives, or any cautionary notes. However, the description implies its use when reverting to a prior commit, so the usage context is reasonably inferable.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kb_delete_docs_by_filterA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is known. The description adds the selection criteria but does not disclose additional side effects, conditions, or behavior when both filter and IDs are combined. It is consistent with annotations, with no contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that front-loads the verb and resource, with no wasted words. It efficiently conveys the core functionality.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the basic operation but leaves ambiguity about how filters and document IDs interact (the 'and/or' phrasing is vague), what happens if neither is provided, and how this tool relates to closely named siblings. Annotations and schema fill some gaps, but the destructive nature warrants more cautionary context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides descriptions for all parameters, but the description adds the key semantic that filters and document IDs can be used together or individually ('and/or'). This clarifies the relationship between the docs and filters parameters, going beyond the schema's standalone descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Delete'), the target ('documents from a knowledge base'), and the selection mechanism ('matching a filter and/or a list of document ids'). This distinguishes it from sibling tools like lyzr_kb_delete_docs by explicitly mentioning filter-based deletion.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives such as lyzr_kb_delete_docs or lyzr_kb_delete. It only states what the tool does, leaving the agent to infer usage from the name and context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kb_sync_cc_pairs_createA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate a non-read-only mutation (readOnlyHint=false) with open-world effects. The description adds minimal behavioral context by clarifying the action is a linking operation with an optional knowledge base. However, it does not disclose whether creation triggers synchronization, uniqueness constraints, or failure modes. This is acceptable given annotation coverage but not richly 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, concise sentence of 14 words that front-loads the action and key objects. Every word earns its place; no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with a well-covered schema, but the description omits that the connector, credential, and optional rag must already exist, and does not mention how to obtain their IDs (e.g., via sibling list tools). This is a minor but meaningful gap for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides full descriptions for all four parameters (100% coverage), so the bar is baseline 3. The description reinforces the relationship between connector_id and credential_id and notes the optional knowledge base, but adds no additional constraints or format guidance beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('create') and identifies the resource as a 'connector-credential pair,' clearly stating the linking relationship. It distinguishes from sibling tools like lyzr_kbsync_connector_create and lyzr_kbsync_credential_create by focusing on the pair object.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is used to link an existing connector and credential, but it does not explicitly state prerequisites (e.g., that connector_id and credential_id must already exist) or mention alternatives among siblings. There is no guidance on when to use this versus creating connectors/credentials separately.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kb_sync_cc_pairs_getA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so safety and idempotency are covered. The description adds no additional behavioral context, such as return format, error behavior, or not-found handling. With robust annotations, a neutral score is appropriate since the description adds minimal value beyond them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no redundant phraseology. It conveys the essential action and target without wasting words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple single-parameter getter with no output schema, the description is adequate for basic selection. However, it does not describe the return payload or any special nuances of connector-credential pairs. Given the low complexity and strong annotations, a middle score is justifiable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage for the only parameter cc_pair_id is 100% because its description ('The connector-credential pair id') fully explains it. The description's 'by id' aligns with the parameter but adds no extra semantic detail beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Fetch a connector-credential pair by id' provides a specific verb (Fetch), a clear resource (connector-credential pair), and retrieval method (by id). This clearly distinguishes it from sibling tools like lyzr_kb_sync_cc_pairs_list (list all) and mutation tools like create/pause/resume.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when you have a known cc_pair_id and need a single pair. However, it does not explicitly state when to use this over siblings, nor does it mention exclusions or alternatives. The sibling naming (list, create, etc.) provides implicit context, but no direct guidance is given.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kbsync_credential_createA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate this is a write operation (readOnlyHint false) and not idempotent, so the description's 'create' is consistent. The description adds context about a distinct credential system but does not disclose error conditions or validation behavior. Overall it adds modest value beyond annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that front-loads the action and resource, with a parenthetical distinction. Every word earns its place; there is no redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a straightforward create operation with a clear name and title, but the description provides no guidance on the structure of credential_json or when this credential should be used relative to the many sibling credential tools. The absence of an output schema means return behavior is not explained, but that is acceptable for a create. Overall it is minimally viable but leaves gaps for users unfamiliar with KB Sync.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Both parameters have descriptions in the schema (100% coverage), so the tool description adds no additional parameter guidance. The credential_json parameter remains vague ('data for the connector's source'), and the description does not compensate for the open-ended object structure.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool creates a KB Sync connector credential, using a specific verb and resource. The parenthetical explicitly distinguishes this from the general RAG credentials system, which differentiates it from sibling tools like lyzr_credential_create.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage is tied to KB Sync connector credentials rather than general RAG credentials, giving some differentiation. However, it does not explicitly state when to use this tool over alternatives or provide exclusions, so guidance is only implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kb_sync_sharepoint_oauth_authorizeA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare this as read-only and idempotent, so the safety profile is covered. The description adds the deprecation status and the fact that the tool returns a URL, which is useful, but it omits any prerequisites or flow context that would help an agent navigate the OAuth process.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no wasted words. The '[deprecated]' marker is placed first, making the status immediately visible.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter deprecated helper, the description covers the core purpose and return kind. However, it does not name a replacement tool or explain the OAuth flow sequence, leaving the agent without enough guidance to decide whether and how to use it in a real workflow.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so there is nothing to explain beyond the schema. The 100% schema coverage baseline of 4 applies, and the description's mention of 'authorize URL' indirectly clarifies the expected return behavior.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Get the SharePoint OAuth authorize URL' with a specific verb and resource, making the tool's function immediately clear. The '[deprecated]' prefix and the distinction from sibling exchange/callback tools further clarify that this is the authorize step.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool within the OAuth flow or what to do once the URL is obtained. The deprecation note implies it should likely be avoided, but no alternative tool is named, even though siblings like lyzr_rag_source_auth_sharepoint_authorize appear to serve a similar purpose.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kb_train_websiteA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate this is a non-read-only, non-idempotent operation with external side effects. The description adds the concept of crawling, which implies network activity, but does not disclose details about whether existing KB content is replaced, how long ingestion takes, or whether it is synchronous or asynchronous.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence that front-loads the action and object. There is no wasted wording or repetition, making it highly concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simple two-parameter schema and annotations, the description is mostly adequate. However, without an output schema, it would help to mention what the tool returns (e.g., a job status or success message). It also omits any guidance on URL format or crawl scope, leaving some ambiguity for the agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both parameters (urls and rag_id) adequately described in the schema. The description adds no additional parameter-level information, so a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Crawl and ingest one or more URLs into a knowledge base.' This specifies the verb (crawl and ingest), the resource (URLs), and the target (knowledge base), distinguishing it from parsing tools and other KB training tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is used for adding web content to a knowledge base, but it does not explicitly state when to use it over alternatives like lyzr_parse_website or lyzr_kg_train_website, nor does it mention any exclusions or prerequisites.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kg_ext_get_graph_neo4jA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the agent knows the operation is safe and repeatable. The description adds minimal context beyond these, only noting that nodes are fetched for a RAG system. It does not elaborate on return format, pagination behavior, or the meaning of 'namespaced endpoint', but it does not contradict the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that conveys the essential information without unnecessary words. It is efficient and easy to parse, earning full marks for conciseness.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite good annotations and full schema coverage, the description leaves some gaps. It does not explain the 'namespaced endpoint' distinction from sibling tools, nor does it describe the output structure, which is important given the absence of an output schema. The openWorldHint suggests unexpected behaviors, but the description does not address this, making the tool slightly under-specified for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for the two parameters (limit and rag_id), each with clear descriptions. The tool description adds no additional parameter-level detail beyond what the schema already provides, so the baseline score of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Fetch' and the resource 'Neo4j knowledge graph nodes for a RAG system', making the tool's function specific and unambiguous. The parenthetical '(namespaced endpoint)' differentiates it from potentially similar tools like lyzr_kg_get_graph, which likely serves a non-namespaced endpoint.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for Neo4j graph retrieval via a namespaced endpoint, but it does not explicitly state when to use this tool versus the sibling lyzr_kg_get_graph or other Neo4j-related tools. There is no direct mention of alternatives or exclusions, leaving the distinction to inference.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kg_task_statusA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is clear. The description adds minimal behavioral context beyond 'poll', such as the fact it's for async KG tasks, but does not describe return format, polling intervals, or status meanings. With annotations carrying the burden, this is adequate but not enriched.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that directly states the action and resource. No wasted words, perfectly concise.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter polling tool with strong annotations, the description is minimally adequate. However, it does not explain what statuses might be returned, how to handle the response, or which types of KG async tasks it applies to (e.g., training, deduplication). There is no output schema, so the description could have provided more context but does not.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with 'task_id' described as 'Async task id'. The description does not add additional meaning to the parameter beyond the schema. Baseline 3 is appropriate since the schema already fully documents the only parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Poll the status of an async knowledge graph task' clearly states the verb (poll), the resource (knowledge graph task), and the async scope. It distinguishes this from generic status tools like 'lyzr_get_task_status' by specifying 'knowledge graph task'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage after launching an async KG task, but it does not explicitly mention when to use this tool vs alternatives like 'lyzr_get_task_status' or 'lyzr_get_chat_task_status'. There is no when-not-to-use guidance or named alternatives, so it earns a 3 for implied usage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kill_switch_traceA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate destructiveHint=true, and the description aligns by saying 'stop agents.' It adds the context that the scope is 'running under a trace,' but does not elaborate on consequences (e.g., immediate termination, irreversibility) or any side effects beyond what the annotations imply.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence with no redundant words. It is appropriately sized for a simple action tool and front-loads the core purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple one-parameter destructive action, the description is almost sufficient but lacks guidance on where to obtain the trace_id (e.g., from lyzr_list_traces) and what the expected outcome/success response looks like. No output schema exists, so the description could mention the result of triggering the kill switch.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers the only parameter (trace_id) with description 'Trace id' (100% coverage). The description does not add any extra meaning or guidance about how to obtain or format trace_id, so it provides no added value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Trigger the kill switch') and the target ('stop agents running under a trace'). It is specific and distinguishes this from read-only trace tools like lyzr_list_traces and lyzr_get_trace_details.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The purpose implies usage—when you need to stop running agents under a trace—but it does not explicitly state when to use this vs. alternatives or mention any prerequisites (e.g., needing an active trace). No exclusions or alternative tool references are given.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_list_agent_versionsA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds minimal behavioral context by specifying 'version history' (implying a list), but does not detail return format, sorting, or pagination.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, focused sentence with no redundant information. The key action and object are immediately clear.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple, well-annotated read-only list operation with a single parameter, the description is sufficient. Annotations and schema cover safety and input requirements; the description states the purpose clearly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%; the agent_id parameter is fully described in the schema. The description adds no additional parameter semantics beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists an agent's version history, using a specific verb and resource. It distinguishes from sibling tools like get_agent_version (which retrieves a specific version) and activate_agent_version (which changes the active version).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No usage guidance is provided. The description does not indicate when to prefer this over get_agent_version or other agent-related tools, nor does it mention any prerequisites or alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_list_modules_adminA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already cover read-only and idempotent behavior, so the description does not need to repeat those. It adds useful context about scope ('all') and content ('configuration'), but does not disclose potential pagination, authorization requirements, or the exact structure of the returned data, which would enhance transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, compact sentence that gets straight to the point. Every word contributes to the meaning: the verb, the object, and the scope are all present with no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter list operation, the description covers the core purpose well. However, with no output schema, it leaves unspecified details like what 'configuration' exactly includes, the response format, and whether admin role is required. These gaps are notable but not critical for such a simple tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool takes no parameters, and the schema is trivially covered at 100%. The description reinforces the absence of filters by stating 'all' modules, which aligns with having zero parameters. As per the baseline for 0-param tools, this is strong.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('List all sidebar modules') and adds the additional detail 'with their configuration,' making the scope explicit. It distinguishes itself from sibling tools like lyzr_get_module_admin (which targets a single module) and the create/update/delete variants.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives such as lyzr_get_modules or other module-related tools. There is no mention of exclusions, prerequisites, or preferred contexts, leaving the agent to infer usage solely from the 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.

• lyzr_livesource_addA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate this is a mutating, non-idempotent operation. The description adds that it returns the created live source, but it fails to disclose potential side effects like triggering a sync or requiring connector-specific credentials, which would be useful behavioral context beyond what annotations provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences, front-loaded with the action and the result. There is no filler, repetition, or unnecessary technical detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a create operation with a rich schema, this minimal description covers the basic purpose and return value, but it omits broader context such as how live sources are set up, that credentials are required for some source types, or that adding a live source initiates syncing. The openWorldHint annotation hints at side effects, so the description could have elaborated on those.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, meaning all 8 parameters already have detailed descriptions in the schema. The tool description adds no additional parameter semantics beyond what the schema preserves, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Add') and the target resource ('a live source to a knowledge base'), which distinguishes it from sibling list/get/remove operations. The title 'Add Live Source' reinforces the same message.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies that the tool is used to add a live source to a knowledge base, but provides no explicit guidance on when to prefer this over related tools like lyzr_kb_train_website or lyzr_parse_website. It also does not mention prerequisites such as requiring credentials for certain source types.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_memprovider_aws_agentcore_statusA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description aligns with the readOnlyHint, openWorldHint, and idempotentHint annotations but adds no additional behavioral context beyond restating the tool's purpose. No details are given about polling behavior, status values, or what the response contains.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single clear, front-loaded sentence with no unnecessary details. Every word adds value, making it highly concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with one parameter and strong annotations, but the absence of an output schema means the description should explain what status information is returned. It does not, leaving the agent unsure of the response format or possible provisioning states.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage for the single required 'credential_id' parameter, with a clear description. The tool description does not add extra parameter context, but the schema already fully documents the parameter, so the baseline is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and a precise resource ('provisioning status of an AWS AgentCore memory resource'), clearly distinguishing it from sibling status tools like mem0_status and supermemory_status by naming the provider and resource type.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this tool is for retrieving provisioning status, but provides no explicit guidance on when to use it versus validating, provisioning, or listing resources. Usage context is only inferred from the tool name and sibling tools, with no stated prerequisites or alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_parse_docxA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already convey non-read-only, non-idempotent, and non-destructive behavior. The description adds a small behavioral detail by stating the output is 'text chunks,' which hints at the chunking process. However, it does not disclose other potential behaviors such as S3 integration, side effects, or error handling, leaving the agent with limited insight beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence with no wasted words. It is concise and front-loaded, clearly stating the primary action and the file type. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 10 parameters and no output schema, so the description should provide a high-level context for how the tool fits together. It clarifies the core purpose and output ('text chunks'), but it omits mention of alternative input sources (S3 vs. base64), default behaviors, or what the actual return structure looks like. The schema covers parameter details, so the description is minimally acceptable but not rich.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% description coverage for all 10 parameters, so the baseline is 3. The description itself adds no parameter-specific meaning beyond the schema, as it never references parameters like chunk_size, s3_key, or file_content_base64. The schema does all the heavy lifting here.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Parse') and resource ('DOCX (Word) file') with a clear outcome ('into text chunks'). It effectively distinguishes from sibling tools that parse other file types (e.g., lyzr_parse_pdf, lyzr_parse_txt) by explicitly naming the DOCX format.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage is appropriate when a DOCX file needs to be converted to text chunks, but it does not provide any exclusions or mention alternative tools. There is no explicit 'when to use this vs. others' guidance. The context is clear from the file type, but the description alone offers limited direction beyond that.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_parse_pptxA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds the output format ('text chunks') beyond what annotations provide, which is useful. However, it does not disclose side effects, auth needs, or limitations, and the annotations (readOnlyHint=false) leave ambiguity about whether parsing has side effects, which the description does not clarify.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is 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 tool's core action and outcome.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given there is no output schema, the description does communicate the return type (text chunks). However, with 7 parameters and no output schema, it omits details about chunking behavior, PPTX feature support, and limitations, which would be valuable for an agent deciding whether and how to use this tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so all 7 parameters are documented in the input schema. The description adds no additional parameter semantics, such as how chunk_size or chunk_overlap affect parsing, so it does not go beyond the schema baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Parse' and identifies the resource 'PPTX (PowerPoint) file' and the outcome 'text chunks'. This clearly distinguishes it from sibling parse tools for other formats like lyzr_parse_pdf or lyzr_parse_docx.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for PPTX parsing but does not explicitly discuss when to use it vs alternatives or mention any exclusions. It provides clear context about the file type but lacks explicit guidance on tool selection among the many parse and kb_train siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_parse_website_apifyA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate openWorldHint=true and readOnlyHint=false, and the description adds 'using the Apify crawler backend', which suggests an external network operation. However, it does not disclose potential costs, rate limits, or output behavior, and does not contradict annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, short sentence that states the core function and backend without any fluff or repetition. It is front-loaded and every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the primary purpose but lacks details about return chunks format, edge cases, or how it differs functionally from the non-Apify variant. With no output schema and multiple parameters, the agent gets enough to invoke it but not a full picture, so a moderate score is warranted.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all six parameters (url, chunk_size, extra_info, extra_fields, chunk_overlap, parser_config) have individual descriptions. The tool description adds no additional parameter semantics, and the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Parse') and resource ('website URL into chunks') and mentions 'Apify crawler backend', which clearly distinguishes it from the sibling tool 'lyzr_parse_website' likely using a different backend. It is precise 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/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for website parsing with Apify as the backend, which hints at when to use it versus other parse tools, but it does not explicitly state alternatives or exclusions. No clear 'when to use vs. when not to use' guidance is provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_schedule_listA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds no additional behavioral context beyond the basic list operation, such as pagination or return format. It does not contradict the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that is front-loaded and free of any redundant information. Every word contributes to the meaning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with one optional parameter, strong annotations, and no output schema, the description is nearly complete. It could mention the return type or pagination, but the operation itself is clearly defined.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides no description for the user_id parameter (0% coverage). The description compensates by stating it is an optional filter, which is critical for correct usage. It does not explain the format or exact semantics of user_id, but for a single optional parameter this is adequate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists schedules and optionally filters by user_id. It is specific enough to understand the resource and action, though it doesn't explicitly distinguish from sibling tools like lyzr_schedule_get or lyzr_schedule_create.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies it is used for listing schedules but provides no explicit guidance on when to use this tool versus alternatives (e.g., schedule_get for a single schedule). The optional user_id filter is mentioned but no exclusions or alternative recommendations are given.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_send_a2a_jsonrpcA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true. The description adds 'raw' implying arbitrary JSON-RPC methods may be invoked, but it does not disclose specific behavioral traits such as error handling, side effects, or validation behavior. It does not contradict annotations, but provides minimal added 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no unnecessary words. It efficiently conveys the tool's core function.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a low-level raw JSON-RPC tool, the description is minimal but adequate for an agent familiar with the protocol. It lacks details about supported methods, response format, or how the endpoint is derived from agent_id, but the schema covers the basic parameters. There is no output schema, so return behavior is not described.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptive parameter comments for request and agent_id. The description adds little beyond mentioning the endpoint concept, which is already captured in the agent_id parameter description. It does not compensate for any schema gaps because there are none.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'send' and the resource 'a raw JSON-RPC 2.0 request to a served A2A agent's endpoint'. This distinguishes it from sibling tools like lyzr_chat or lyzr_get_a2a_agent, which operate at a higher level or on metadata.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for low-level, raw interactions (via the word 'raw') but does not explicitly state when to use this tool versus alternatives such as lyzr_chat or lyzr_get_a2a_agent_card. There is no mention of exclusions or preferred higher-level alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_session3_list_messagesA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety and idempotency. The description adds the generic notion of 'optional filters' but does not disclose additional behavioral details like pagination behavior, ordering, or how filters interact. It neither contradicts annotations nor adds significant context beyond them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single sentence, 'List messages in a v3 session, with optional filters,' is extremely concise and front-loaded. Every word earns its place, and there is no redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity and the rich schema/annotations, the description is minimally sufficient, but it fails to differentiate from the many sibling session-related tools and does not mention pagination or return behavior. It lacks any contextual cues that would help an agent decide when to use this tool over others.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides 100% coverage for all 5 parameters, so the description's generic mention of 'optional filters' adds no meaning beyond what the schema already documents. The baseline of 3 applies because the schema does the heavy lifting and the description does not compensate with extra detail.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('List'), the resource ('messages in a v3 session'), and the optional filters, making the tool's purpose unambiguous. It distinguishes from sibling session-level tools (e.g., lyzr_session3_list) by focusing on messages rather than the session itself.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for listing messages in v3 sessions, but it does not provide explicit guidance on when to prefer this tool over alternatives such as lyzr_session_history or lyzr_session_conversation. There are no exclusions or contextual hints beyond the basic action.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_sharing_refresh_groupA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds context that it affects the cached index, but does not describe side effects, required permissions, failure modes, or what exactly 'refresh' entails. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, well-structured sentence that is front-loaded with the action and object. No unnecessary words or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a low-complexity tool with one parameter and annotations, the description is minimally adequate. However, it lacks context on when to use it versus the similar sibling replenish_indexes or what outcomes to expect, leaving some ambiguity for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The only parameter group_id is fully described in the schema as 'Sharing group id'. The description adds no extra semantic meaning beyond the schema, which has 100% coverage, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Refresh a sharing group's cached shared-resource index' clearly states the action (refresh) and the specific resource (sharing group's cached shared-resource index). It distinguishes itself from other sharing tools like get_group or update_group by focusing on cache refresh.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage is for refreshing cached indexes but gives no explicit when-to-use guidance or alternatives. It does not differentiate from the sibling tool reconcile_indexes or explain when a refresh is needed.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_bulk_delete_toolsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and readOnlyHint=false, so the destructive nature is covered. The description adds minimal behavioral context ('one call' implies batching) but does not disclose consequences like irreversibility, partial failure behavior, or permissions required beyond what annotations imply.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One short, front-loaded sentence that clearly states the action, resource, and scope. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter destructive tool with annotations and no output schema, the description is largely sufficient. It could be more complete by noting how failures are handled (e.g., if some IDs don't exist), but the essential information is present.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% for the single parameter 'tool_ids' with its own description. The tool description reinforces that deletion is by id and supports multiple, but adds no extra parameter-level detail beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description uses a specific verb ('Delete') and resource ('tools'), and clearly indicates scope ('multiple tools by id in one call'). This distinguishes it from singular delete tools and bulk deletes of other entities like agents or workflows.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'in one call' implies this is for batching multiple deletions, which gives some usage context. However, it does not explicitly mention when to use this over alternatives like calling the singular delete_tool repeatedly, or exclude cases where it 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.

• lyzr_channel_webhookA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already disclose readOnly=false, idempotent=false, and destructive=false. The description adds that the payload is delivered 'for processing,' implying downstream side effects, but it does not elaborate on what processing entails, delivery guarantees, or error behavior. This is moderate added context beyond annotations, not rich disclosure.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that states the verb and object immediately. There is no wasted wording or redundant detail, which makes it maximally concise for a simple tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a low-complexity tool with complete schema coverage and useful annotations, the description is mostly sufficient. The main gap is not explaining what 'processing' means or what the caller should expect in return, but the core invocation intent is clear and the tool is small enough that this does not severely impede usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so both 'payload' and 'channel_id' are already documented. The description does not add meaning beyond the schema; it merely echoes the concept of a webhook payload. Baseline 3 is appropriate given full schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('deliver') with a clear resource ('inbound messaging-platform webhook payload') and destination ('to a channel for processing'). It distinguishes itself from sibling channel tools (create/list/delete) and webhook tools by focusing on inbound payload delivery for processing.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: you would call this when you have a messaging-platform webhook payload to route to a channel. However, it does not explicitly state when to use this over alternatives (e.g., KB sync webhook tools) or exclude other cases, so 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.

• lyzr_create_bigquery_credentialA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already flag this as non-read-only, non-idempotent, and non-destructive, so the safety profile is covered. The description adds the uploading method (service account JSON) but does not disclose side effects, storage details, or return behavior beyond that.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, front-loaded sentence that gets straight to the point. No wasted words or redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is relatively simple (2 params, no output schema) and the annotations plus schema cover the main details. However, the description does not explain what happens after creation (e.g., what the response includes) or when to use this over other provider credential tools, creating a small gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% (both parameters have descriptions), so the baseline is 3. The description only echoes the service account JSON part and provides no additional parameter details beyond what the schema already states.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Create'), identifies a clear resource ('BigQuery provider credential'), and states the method ('uploading a service account JSON file'). This distinguishes it from sibling tools like the generic lyzr_create_provider_credential or lyzr_create_file_upload_credential.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not explicitly mention when to choose this over alternatives, though the BigQuery-specific wording implies it is for BigQuery credential setup. No exclusions or alternative tool suggestions are provided, leaving some ambiguity among the many credential-creation sibling tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_credential_getA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare the tool as read-only and idempotent, lowering the transparency burden. The description adds the id-scoped retrieval behavior but does not disclose details like not-found handling, return format, or authorization requirements. It is consistent with annotations but provides no additional behavioral color.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no wasted words. Every word earns its place: action, resource, and retrieval key.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter read-only getter, the description is nearly complete. It doesn't describe the return value shape or error cases, but the tool's low complexity and strong annotations make the omission acceptable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the single parameter credential_id is fully described in the schema. The description's phrase 'by id' reinforces the schema but does not add extra semantic detail about the id format or constraints.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Fetch') with a clear resource ('a credential') and retrieval condition ('by id'). This clearly distinguishes it from sibling tools like lyzr_credential_list, lyzr_credential_create, and lyzr_credential_delete.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when a credential id is known and a single credential is needed, but it does not explicitly state when to avoid this tool or mention alternatives. It provides only implied usage context rather than explicit guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_credential_updateA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate this is a write operation (readOnlyHint=false), non-destructive, and idempotent. The description adds minimal behavioral context beyond that: 'All fields optional' implies partial update semantics (omitted fields remain unchanged), but it does not describe what happens to unspecified fields, any validation side effects, or return behavior. With annotations covering the basic safety profile, this is adequate but not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences, front-loaded with the primary purpose and followed by a key usage note. Every word earns its place; no fluff or repetition of schema details. This is an example of appropriate conciseness.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 6 parameters, 1 required, with nested objects, but the schema provides thorough descriptions for all parameters. The description, while minimal, conveys the core operation and partial-update flexibility. It does not explain return values (no output schema) or provide deeper context about how extra_fields interact with the request, but the overall picture is adequate for a simple credential update tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so each parameter already has a description (e.g., credential_id, name, scope, metadata, credentials, extra_fields). The description's 'All fields optional' is redundant with the schema's required list (only credential_id). It adds no new meaning beyond what the schema provides, so the baseline score of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Update an existing credential' clearly states the action (update) and the resource (credential), distinguishing it from sibling tools like create, list, get, and delete. The additional note 'All fields optional' adds important scope semantics. This is a specific, actionable purpose statement.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: it targets existing credentials and allows partial updates via 'All fields optional'. However, it does not explicitly state when to use this tool instead of lyzr_credential_create or lyzr_credential_delete, nor does it mention any prerequisites or context where update is appropriate. No exclusions or alternatives are named.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_delete_aci_custom_appA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The phrase 'permanently delete' conveys irreversibility, which aligns with and reinforces the destructiveHint=true annotation. However, beyond that, it does not disclose additional behavioral details like cascading effects, idempotency behavior, or permission requirements. Annotations already cover the destructive and idempotent nature, so the description adds minimal new 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, compact sentence that front-loads the action and target. Every word earns its place with no filler or redundant clichés.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a straightforward delete operation with one required parameter, the description is adequate. It clearly states the action, the target resource, the identifier, and the irreversibility. No output schema is provided, which is acceptable for a delete tool. Minor gaps such as return behavior or error conditions are not needed given the simplicity and the existing annotations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The only parameter, app_id, is fully described in the schema ('The ACI custom app id to delete'), and the description simply repeats 'by id'. With 100% schema coverage, the description provides no additional parameter meaning beyond what the schema already offers.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('delete'), identifies the resource ('ACI custom app'), and states the identifier ('by id'). It clearly distinguishes from sibling tools like lyzr_delete_lyzr_aci_tool or lyzr_delete_aci_connection by naming the exact resource type.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage—when you need to permanently delete an ACI custom app by its id—but it does not explicitly mention alternatives, prerequisites, or when not to use this tool. No exclusions or contrasting sibling tools are provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_delete_channelA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds 'permanently' to clarify irreversibility and 'configuration' to narrow the target object, but it does not disclose potential side effects (e.g., impact on associated routes) or authorization requirements. It adds some value beyond annotations but remains limited.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence of eight words with no redundant content. Every word earns its place, making it highly concise and well structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter destructive operation with rich annotations, the description is sufficiently complete. It states what is deleted and how. It could optionally mention prerequisites or side effects on related configurations, but the low complexity and schema coverage make the current description adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides 100% coverage with a clear description of channel_id ('The channel id to delete'). The tool description adds no extra semantic detail about the parameter, so the schema carries the full burden. Baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Permanently delete a channel configuration by id' uses a specific verb (delete), specifies the resource (channel configuration), and includes the input method (by id). It clearly distinguishes from sibling tools like create, list, or update channel operations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies use when a channel configuration needs to be permanently deleted, but provides no explicit context, exclusions, or comparisons to alternative delete tools such as lyzr_delete_agent or lyzr_session3_delete. The name and description make the usage fairly obvious, but it lacks direct guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_delete_moduleA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already convey destrutiveness (destructiveHint: true) and non-read-only behavior (readOnlyHint: false). The description adds 'permanently' reinforcing irreversibility, but it does not detail side effects, permission requirements, or what happens to associated data. With annotations covering the core safety profile, this is adequate but not enhanced.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence, front-loaded with the action and object, with no superfluous words. It is concise and efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple deletion tool with one parameter and rich annotations, the description is mostly complete. It correctly identifies the action and target. However, it does not mention how to discover the module key or what happens on missing keys, which could be useful context, but the idempotentHint suggests repeated calls are safe.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema describes the lone parameter 'key' as 'Module key' with 100% coverage, so the description adds little beyond that. The phrase 'by key' simply restates the schema's parameter meaning without additional context like format or how to obtain the key.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Permanently delete a sidebar module by key.' It uses a specific verb ('delete') and resource ('sidebar module'), distinguishing it from sibling tools like create_module, update_module, and get_modules.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when a sidebar module needs to be removed, but it does not explicitly state when to use it versus alternatives or mention prerequisites (e.g., obtaining the key via get_modules). No exclusions or alternative tool references are provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_delete_workflowA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and idempotentHint=true. The description adds 'permanently,' which reinforces irreversibility, but does not disclose side effects on related resources or error behavior. This is adequate given annotation coverage but not enriched.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence with no filler or repetition. It conveys the essential action and scope with zero wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple single-resource deletion with one parameter, no output schema, and comprehensive annotations, the description is sufficient. It could mention return behavior or edge cases, but those are not critical given the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema fully documents flow_id with a description, and the description's 'by id' merely restates that. No additional parameter semantics are provided, so the baseline score of 3 for high schema coverage applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Permanently delete a workflow by id' uses a specific verb (delete), identifies the resource (workflow), and clarifies it is a single deletion by ID. It clearly distinguishes from sibling tools like bulk delete or update.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The usage is implied: this tool deletes a single workflow, while bulk deletion is handled by lyzr_bulk_delete_workflows. However, the description does not explicitly mention alternatives or exclusions, leaving the agent to infer the intended scope from context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_a2a_agent_cardA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful context about the exact resource path (.well-known/agent-card.json) and the 'served agent' scope, but does not disclose response behavior, error handling, or the need for the agent to be published. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence. It opens with the verb ('Fetch'), names the resource, and clarifies via a parenthetical—no redundant wording. Every word contributes value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read tool with one parameter and rich annotations, the description is adequate. It states the resource and the 'served agent' prerequisite. However, it does not explicitly state that the return value is the raw JSON descriptor content, which is implied by 'Fetch ... descriptor.' No output schema exists, so a slightly more explicit return description could be added, but the current wording is sufficient for the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with a single parameter `agent_id` described as 'The A2A agent id.' The tool description supplements this by stating 'for a served agent,' which adds a meaningful constraint that the ID must correspond to a served agent. This goes beyond the bare schema description and helps the agent select a valid ID.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Fetch') and the specific resource ('A2A agent card' as the .well-known/agent-card.json descriptor). This precision distinguishes it from sibling tools like lyzr_get_a2a_agent (which likely retrieves agent details) and lyzr_get_a2a_agent_card_convenience (a convenience wrapper), leaving no ambiguity about which tool to use for the raw descriptor.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does 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 such as lyzr_get_a2a_agent_card_convenience or lyzr_get_a2a_agent. There are no explicit exclusions or alternative recommendations. The only hint is 'for a served agent,' which serves as a prerequisite rather than usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_assetA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the read-only nature is covered. The description adds the behavioral context that it returns metadata (not the raw asset), which is useful distinction from get_asset_raw. However, it does not disclose error behavior or output structure.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence, front-loaded with the core action and resource. There is no wasted wording or repetition of schema details.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple 1-parameter read-only tool, the description is largely complete: it specifies the input (id), the output type (metadata), and safety profile via annotations. It could be enhanced by noting not-found behavior, but that is a minor gap given the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with asset_id documented as 'Asset id'. The description's 'by id' adds no new semantic information beyond what the schema already provides, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'fetch', the resource 'asset metadata', and the access method 'by id'. This distinguishes it from related tools like lyzr_list_assets and lyzr_get_asset_raw, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'by id' implies the tool should be used when an asset_id is known, but there is no explicit mention of when to choose it over alternatives like list_assets for finding IDs or get_asset_raw for raw content. Usage context is implied but not explicitly stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_asset_rawA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description does not need to repeat safety info. It adds minimal context about 'raw content' but does not disclose return format, authentication needs, or potential errors. Acceptable given annotation coverage, but no extra value.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence, perfectly front-loaded with the action and object. No unnecessary words or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with one parameter and strong annotations, the description is nearly complete. It could explain what 'raw content' means (e.g., file bytes vs parsed text) since there is no output schema, but the title and description together are sufficient for most use cases.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with asset_id described as 'Asset id'. The description's 'by id' adds no new meaning beyond the schema. Baseline 3 applies since the schema carries the parameter semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Fetch'), the resource ('raw content of an asset'), and the key identifier ('by id'). It distinguishes itself from siblings like lyzr_get_asset by specifying 'raw content', making the purpose unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for retrieving raw asset content but provides no explicit guidance on when to use it versus alternatives like lyzr_get_asset for metadata. There are no stated exclusions or alternative tool references.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_audit_logA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already communicate read-only and idempotent safe behavior. The description adds the scoping constraint of fetching a single entry by ID, but provides no further behavioral context (e.g., error behavior, return format, permissions). With annotations covering safety, a 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, front-loaded sentence that states exactly what the tool does. No wasted words, and the key information (action, resource, identifier) is immediately visible.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple get-by-ID operation with excellent schema coverage and safe annotations, the description is largely sufficient. It could mention the return object or absence behavior (e.g., 404) for completeness, but the simplicity and sibling context reduce the need. Overall, well-covered for its complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema covers 100% of parameters, with log_id described as 'Audit log id'. The description's 'by its id' adds no meaningful semantic beyond what the schema already provides. Baseline 3 for high schema coverage is correct.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Fetch a single audit log entry by its id' uses a specific verb (fetch), identifies the resource (audit log entry), and specifies the scope (single, by id). This clearly distinguishes it from the many list-type audit log siblings (e.g., list_org_audit_logs).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies use for retrieving a single log entry when an ID is known, as opposed to list tools. However, it does not explicitly state when to use this vs alternatives, nor does it mention any prerequisites or exclusions. Guidance is thus implied rather than direct.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_composio_auth_configA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations fully cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false). The description adds no extra behavioral context (e.g., prerequisites, return format) but is consistent with the read-only nature.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, concise 9-word sentence with a front-loaded verb. Every word earns its place; no redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple 1-parameter read-only tool with strong annotations, the description is largely complete. The only minor gap is no explicit mention of the return value or that the provider_id must exist, but the simplicity makes it adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and provider_id is adequately described as 'Composio provider id'. The tool description adds no additional parameter meaning, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Fetch') and clearly identifies the resource ('Composio auth config') with scope ('for a provider'). It distinguishes itself from sibling tools like create/delete composio auth config.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit when-to-use or when-not-to-use guidance is provided. The getter nature implies usage when a provider's auth config is needed, but no alternatives or exclusions are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_context_by_name_internalA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds the internal api_key requirement, which is useful auth context, but does not mention return format or error behavior. With annotations present, this is adequate but not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler. Every word adds meaning, and it clearly communicates the essential purpose and auth requirement.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple 2-parameter tool with strong annotations and complete schema coverage, the description covers purpose and auth. The only gap is distinguishing this from sibling context tools, but that is a minor omission given the tool's low complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the schema already fully documents both parameters (context_name and api_key). The description simply restates that fetch is by name and using an internal api_key, adding no additional semantics or constraints beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('fetch') and resource ('a context by its name'), and the 'internal endpoint' qualifier distinguishes it from public context getters. This 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 Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The 'internal endpoint' and 'internal api_key' wording implies this is for restricted/internal use only, but the description does not explicitly state when to choose this over alternatives like lyzr_get_context or lyzr_get_context_value_internal. Usage guidance is implied, not explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_mcp_oauth_statusA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to repeat safety. It adds the useful contextual detail that it checks an 'in-progress' flow, confirming a non-destructive status query. It does not disclose possible status values or polling behavior, but this is not critical given the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One clear sentence, front-loaded with the action and resource, no unnecessary words. It earns its place entirely.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple status-check tool with good annotations and fully described parameters, the description is sufficient. It does not explain what status values are returned, since there is no output schema, but the tool's purpose is clear enough for an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already describes both parameters (state as 'OAuth state token returned by initiate' and server_id as 'MCP server id') with 100% coverage. The description adds no additional parameter semantics, so the baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('check') and a specific resource ('status of an in-progress MCP OAuth flow'). It clearly distinguishes this from the sibling tool lyzr_initiate_mcp_oauth, which starts the flow, and other MCP server management tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The word 'in-progress' implies this should be used after initiating an OAuth flow, but the description does not explicitly say 'use after lyzr_initiate_mcp_oauth' or mention any alternatives. Usage is implied but not spelled out.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_toolA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds no additional behavioral context such as return format, error handling, or prerequisites. It is neutral and non-contradictory.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler. It is appropriately sized for the tool's simplicity and fully earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple fetch-by-id tool with one parameter, no output schema, and strong annotations, the description is nearly complete. It does not explicitly state the return value, but 'fetch a tool' implicitly conveys that the tool object is returned. This minor gap prevents a perfect score.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for the only parameter, tool_id, which is described as 'The tool id to fetch'. The description 'Fetch a tool by id' adds no extra meaning beyond what the schema already provides, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Fetch' with the resource 'tool' and scope 'by id', clearly distinguishing from listing tools or fetching other entities. It precisely states what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'by id' implies it is for retrieving a specific tool when the ID is known, but there is no explicit mention of alternatives like lyzr_list_tools or when not to use it. Usage context is implied rather than stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_trace_detailsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety behavior is covered. The description adds minimal extra context ('raw details') but does not disclose return format, potential errors, or relationship to trace lifecycle.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, focused sentence front-loads the action and resource with no filler or redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple single-parameter lookup, rich annotations, and full schema coverage, the description is mostly complete. It could mention how to obtain trace_id or what 'raw details' includes, but the low complexity lowers the burden.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%; the trace_id parameter is already described as 'Trace id'. The description adds no meaning beyond 'by id', so it provides no extra value over the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Fetch'), the resource ('raw details for a trace'), and the lookup method ('by id'). The phrase 'raw details' helps distinguish it from sibling tools like lyzr_get_trace_summary and lyzr_get_trace_gantt.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when you need raw trace details and already have a trace_id, but it does not explicitly mention when to prefer it over alternatives like get_trace_summary or get_trace_gantt. There is no exclusion or alternative guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_traces_dashboardA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds aggregation scope and metric types, but it does not disclose response structure, default time windows, or pagination, which would add further 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single sentence, front-loaded with the verb 'Fetch' and the resource, lists key metrics and notes optional filtering. No redundant words or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only aggregation tool with optional filters, the description covers purpose and metric scope, sufficient for basic selection. However, it lacks explicit usage guidance and response format details, given there is no output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already documents all six filter parameters. The description adds only that filtering is optional, providing minimal additional semantic value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool fetches aggregate dashboard metrics, enumerating the metric types (credits, traces, spans, tokens, latency, error rate). This specific verb-resource pairing distinguishes it from trace-listing tools by emphasizing aggregation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit when-to-use guidance or alternatives are provided. 'Optionally filtered' implies flexible usage, but the description does not tell the agent when to prefer this over related tools like lyzr_list_traces or lyzr_ops_get_dashboard.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_git_delete_governanceA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and idempotentHint=true, which align with the 'delete' action. The description adds no extra behavioral details beyond the scoping to an agent's git repo, and does not state permanence or side effects. It is consistent with annotations and provides minimal added value.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that front-loads the action and avoids any fluff. Every word contributes directly to the meaning, making it highly efficient for an agent to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete operation with one parameter and existing annotations, the description is adequately complete. It specifies what is deleted and the target scope, though it could optionally mention what happens after deletion or any effects on the repo. Given the tool's simplicity, this is sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The single parameter 'agent_id' is fully described in the schema ('Agent id'), and the tool description does not add any extra meaning beyond clarifying that the agent's git repo is the target. With 100% schema coverage, the baseline is 3 and there is no additional contribution.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly specifies the action (delete), the resource (governance policy), and the scope (for an agent's git repo). It effectively distinguishes from sibling tools like lyzr_git_get_governance or lyzr_git_save_governance by focusing on the delete operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: use this when you want to delete a governance policy. However, it does not provide explicit guidance on when to use this tool vs alternatives, nor does it mention any prerequisites or caveats. The intended use is mostly left to inference.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_git_list_branchesA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the agent knows this is a safe read operation. The description adds minimal behavioral context beyond the annotations—it doesn't mention return format, whether branches are local/remote, or ordering—but for a simple list operation this is acceptable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single clear sentence with zero unnecessary words. It fully fits its purpose without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (one required parameter, no output schema, comprehensive annotations), the description is adequately complete for an agent to select and invoke it. It could optionally mention what the tool returns, but it is not necessary for a straightforward read-only list operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with agent_id described as 'Agent id'. The description does not add meaningful parameter semantics beyond the schema; it merely ties agent_id to the concept of an agent's git repo, which is already implied by the tool name.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'List branches in an agent's git repo' uses a specific verb (List), a clear resource (branches), and a scope qualifier (in an agent's git repo). This distinguishes it from sibling git listing tools like lyzr_git_list_commits, lyzr_git_list_prs, and lyzr_git_list_repo_files, and also from the session-level lyzr_session3_list_branches.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context (operating on an agent's git repository) but does not explicitly state when to use this tool versus alternatives such as session branches or other git listing tools. No exclusions or alternative guidance is provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kb_createA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate this is not read-only, is not idempotent, and is not destructive, so the description's 'Create' action aligns without contradiction. It adds a small behavioral detail by noting the tool returns the new KB's id, but it does not describe any further side effects, prerequisites, or what happens on duplicate names. With annotations present, this is adequate but not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description consists of two short, front-loaded sentences: one stating the action and one stating the return value. Every word earns its place, with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 5-parameter create tool with high schema coverage and no output schema, the description plus schema provide enough to invoke the tool correctly. It communicates the key outcome (returns the id), and the sibling tool names imply related next steps like training. It is slightly incomplete in not mentioning how the KB should be populated, but it is not a serious gap given the available structured metadata.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 80%, so the input schema already explains most parameters (name pattern, llm_model, vector_store, embedding_model). The description itself adds no parameter-level meaning beyond labeling the resource as a RAG knowledge base, so it does not exceed the baseline for well-documented schemas.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Create') and a precise resource ('RAG knowledge base'), clearly distinguishing this from sibling KB tools like lyzr_kb_update or lyzr_kb_delete. It also states the primary return value ('Returns its id'), making the tool's purpose unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for creating a knowledge base before training/querying it, but it does not explicitly state when to use this versus alternatives like lyzr_kb_update or lyzr_kb_train_text. There is no exclusion or direct comparison to sibling tools, leaving usage context implicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kb_delete_docsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and readOnlyHint=false, so the deletion nature is known. The description adds no further behavioral context such as permanence, permissions, or effects on related data, but it does not contradict the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single sentence that immediately states the action, resource, and mechanism. Every word earns its place, and the structure is front-loaded for quick parsing.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete operation with complete schema and useful annotations, the description is adequate. It could add a note about irreversibility or return behavior, but the essential context is covered by the structured data.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with both rag_id and docs fully described. The description mentions 'document ids' but adds no additional meaning beyond what the schema already provides, landing at the baseline for complete schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Delete'), a resource ('documents from a knowledge base'), and the method ('by their document ids'). This clearly distinguishes it from the sibling tool lyzr_kb_delete_docs_by_filter, which deletes by filter rather than specific IDs.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives no explicit guidance on when to use this tool versus alternatives like lyzr_kb_delete_docs_by_filter or lyzr_kb_delete. Usage is implied by the operation itself but not articulated, leaving the agent to infer context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kb_getA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, covering the safe-read profile. The description adds no additional behavioral context such as error handling, permissions, or return shape. It does not contradict the annotations, but it also does not go beyond them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single seven-word sentence ('Fetch a knowledge base by id.') with zero filler. It is front-loaded and every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter, read-only tool with comprehensive annotations and full schema coverage, the description provides sufficient information to select and invoke it correctly. It could mention the return shape or point to lyzr_kb_list for finding IDs, but the simplicity of the operation makes it nearly complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully describes the only parameter (kb_id: string, 'Knowledge base id'). The description's 'by id' only reinforces the schema without adding new semantic detail. With 100% schema coverage, the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Fetch' and identifies the resource as 'a knowledge base' accessed 'by id.' This clearly distinguishes it from sibling tools like lyzr_kb_list (list all), lyzr_kb_create/update/delete (mutations), and training tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when the agent knows a specific knowledge base ID, but it does not explicitly state when to use this tool versus alternatives like lyzr_kb_list for discovering IDs, nor does it mention exclusion cases. Usage is only implied, not directly guided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kb_sync_cc_pairs_listA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, covering safety and idempotency. The description adds the 'all' qualifier, implying an unfiltered result set, which is a small behavioral trait. However, it does not disclose output format, pagination, or whether paused/inactive pairs are included. With annotations covering the core safety profile, this is minimally acceptable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence with zero waste, immediately front-loading the verb and resource. It is appropriately sized for a no-parameter list operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema and no additional context in the description, the agent is left without details about return values, the structure of each pair, or relationship to KB sync operations. Given the specialized domain and many sibling tools, this description is insufficient for fully informed invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, and schema coverage is trivially 100%. The description does not need to add parameter details. Baseline for 0 params is 4, and no deduction is needed since there is nothing to explain.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'List all connector-credential pairs' uses a specific verb ('list') and resource ('connector-credential pairs'), clearly distinguishing it from siblings like lyzr_kbsync_connector_list (lists connectors only) and lyzr_kbsync_credential_list (lists credentials only). It unambiguously states the scope ('all') and action.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage by stating 'list all connector-credential pairs', but it does not explicitly mention when to use this over related list tools or provide exclusions or alternatives. It offers no guidance on filtering or context, making it adequate but not instructive.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kb_sync_cc_pairs_pauseA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly=false, destructive=false, and idempotent=true. The description adds no further behavioral context, such as effects on in-progress syncs or persistence of the paused state, but it does not contradict the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that front-loads both the verb and resource, containing no unnecessary words or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter state-change operation with a clear sibling set, the description is largely complete. It could mention whether pausing applies only to future syncs, but given the low complexity and supportive annotations, it covers the essentials.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema explains cc_pair_id as 'The connector-credential pair id', providing 100% coverage. The description adds no additional meaning beyond the schema, making the baseline score of 3 appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Pause' with the resource 'connector-credential pair', clearly distinguishing it from sibling tools like resume, sync, and status. It leaves no ambiguity about the action performed.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit usage guidance is provided beyond the implied use case of pausing syncs. The tool name and sibling context (e.g., resume, sync) make the purpose obvious, but there is no mention of when not to use or alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kbsync_connector_deleteA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows this is a destructive operation. The description adds 'Permanently delete', reinforcing irreversibility, which is useful context beyond the generic annotation. However, it does not disclose any other behavioral traits such as what happens to associated sync configurations, whether permissions are required, or error behavior if the connector does not exist. With annotations present, this is adequate but not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is one concise sentence with no filler words. It front-loads the critical information ('Permanently delete') and immediately states the target resource and method. Every word earns its place, making it highly efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple deletion tool with a single required parameter, no output schema, and annotations covering the destructive and idempotent nature. The description fully explains what the tool does and how to invoke it. While it lacks details about preconditions or cascade effects, those are not critical for a basic delete operation, and the information provided is sufficient for correct use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage with a clear description for connector_id ('The connector id to delete'). The description also mentions 'by id', but this adds no additional meaning beyond what the schema already provides. Since the schema fully documents the single parameter, the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does 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 specific resource ('KB Sync connector') with a precise identifier ('by id'). This distinguishes it from sibling tools like lyzr_kbsync_connector_get, lyzr_kbsync_connector_update, and lyzr_kbsync_connector_list, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not explicitly state when to use this tool versus alternatives or provide any usage conditions. The verb 'delete' and the reference to 'by id' imply its use, but there is no explicit guidance on prerequisites or when not to use it, such as suggesting listing first to confirm the ID. This is reasonable for a simple delete tool but lacks clear usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kbsync_connector_getA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, fully conveying the safety profile. The description adds no extra behavioral context beyond the fact that it fetches by id, which is already captured by the schema. It is consistent with annotations but does not go beyond them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that is front-loaded with the action and resource. Every word is necessary, with no redundant or promotional content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a minimal get-by-id tool with strong annotations and a single well-described parameter, the description is adequate. It lacks an explicit statement of what is returned, but given the tool's simplicity and the absence of an output schema, the current description is sufficient for an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for the single parameter connector_id, which has its own description 'The connector id'. The tool description merely repeats 'by id' without adding any additional semantic detail, so the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Fetch a KB Sync connector by id' uses a specific verb (fetch), identifies the resource (KB Sync connector), and indicates the selection method (by id). This clearly distinguishes it from sibling tools like lyzr_kbsync_connector_list, which retrieves multiple connectors.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when a specific connector_id is known, as opposed to listing or creating connectors. However, it does not explicitly state when to use this tool over alternatives or provide any exclusions, so the guidance remains implicit rather than explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kb_updateA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds no significant behavioral context beyond what annotations provide, such as merge semantics or prerequisites. It is not contradictory, but it doesn't add meaningful transparency beyond the structured fields.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences, front-loaded with the core action and resource, and immediately explains how to specify changes. Every word is purposeful; there is no redundancy or filler. This is an exemplar of concise, well-structured tool documentation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's low complexity (2 parameters, no output schema, no enums), the description is mostly sufficient. It tells the user what to do and how to supply changes. However, it could mention implications of the update (e.g., whether it merges or replaces config) or the return value, but the schema and annotations fill in key details. The description is adequate but not exhaustive, hence a 4.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: both parameters (config_id and extra_fields) have descriptions in the schema. The tool description merely restates that fields are provided via extra_fields, which adds no new meaning beyond the schema. According to guidelines, baseline is 3 when schema coverage is high, and the description doesn't compensate or enhance the parameter understanding.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Update'), the resource ('a knowledge base config'), and the identifier type ('by id'). It distinguishes this from related siblings like lyzr_kb_create, lyzr_kb_get, and lyzr_kb_delete by focusing on the config update operation. The title reinforces the specific resource, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context: use this when you have a knowledge base config id and want to change fields via extra_fields. However, it does not explicitly state when not to use this tool or mention alternatives (e.g., lyzr_kb_update_docs_metadata for document metadata updates). The guidance is present but implicit, relying on the tool name and sibling list for differentiation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_list_aci_configurationsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds minimal behavioral context beyond the acronym expansion (Aipolabs Composio-alternative), but does not disclose return format, pagination, or other behavioral traits. This is adequate given the strong annotation coverage but adds little extra.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that states exactly what the tool does. There is no wasted wording or unnecessary repetition, making it easy for an agent to parse quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simplicity of the tool (zero parameters, read-only, idempotent) and the presence of sibling tools providing context, the description is sufficient for an agent to understand its purpose. While it does not mention what the returned list contains, the name and description imply a straightforward list operation, so it is fairly complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and the input schema is empty, so the schema provides 100% coverage by default. With no parameters to document, the description has no semantics to add, and the baseline of 4 is appropriate for a parameter-less tool.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function with a specific verb ('List') and resource ('ACI app configurations'), and it distinguishes itself from sibling tools like create/delete configurations. The parenthetical explanation of ACI as 'Aipolabs Composio-alternative' adds useful clarifying 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/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no explicit guidance on when to use this tool versus alternatives, nor does it mention filters, prerequisites, or exclusions. Unlike the get_calls example which names a specific alternative, this description leaves usage entirely implicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_list_artifacts_by_sessionA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds 'paginated' behavior and session-specific scoping, but does not explain pagination defaults, ordering, or response structure. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler. 'List paginated artifacts belonging to a specific user's session' efficiently conveys the core operation and scope.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list operation with well-documented parameters and strong annotations, the description is mostly complete. Lack of an output schema and mention of response format adds minor ambiguity, but it is not a significant gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides complete descriptions for all four parameters, so the baseline is 3. The description only reinforces that artifacts belong to a user's session and adds no new parameter details beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (List), the resource (artifacts), and the scope (specific user's session), which distinguishes it from general artifact tools like lyzr_list_artifacts. The title and name reinforce the purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies use when retrieving artifacts for a specific user's session, but it provides no explicit when-to-use guidance or comparisons with sibling tools such as lyzr_list_artifacts or session history tools. Context is clear but exclusions/alternatives are not stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_list_mcp_server_promptsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well-covered. The description adds no additional behavioral context beyond the fact that it lists prompts, which is essentially the same as the annotation set. No extra details about output format, pagination, or potential caveats are provided, but given the simple read-only nature, this is acceptable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, short sentence that is directly relevant and contains no filler or redundancy. It is front-loaded with the action ('List') and resource ('prompts'), making it easily scannable. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is very simple: one required parameter, no output schema, and a clear action. The description sufficiently conveys what the tool does, and the parameter is fully described in the schema. While it does not detail the return structure, the phrase 'list the prompts' strongly implies a list of prompt definitions. Given the low complexity and good schema support, the description is nearly complete, but lacks any mention of output shape or potential edge cases, so a 4 rather than 5.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers the only parameter (server_id) with a description ('MCP server id'), so schema description coverage is 100%. The tool description adds no additional semantic information about the parameter. Baseline score of 3 is appropriate when the schema provides all necessary parameter meaning.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'list' and explicitly identifies the resource: 'prompts exposed by an MCP server.' This clearly distinguishes it from sibling tools like lyzr_list_mcp_server_tools and lyzr_list_mcp_server_resources, which target different resource types. The purpose is immediately clear 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/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies its usage (call when you need to see prompts for an MCP server) but does not explicitly mention when to use it vs. alternatives or provide exclusions. Sibling tools like list_mcp_server_tools and list_mcp_server_resources are present, but the description does not guide the agent to choose between them. The guidance is implied rather than explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_list_mcp_server_resourcesA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, which cover the safety profile. The description adds no extra behavioral context (e.g., auth requirements, pagination, return format). It does not contradict the annotations, so with annotations present the score aligns with the minimum viable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no redundant words. Every word contributes to the purpose, making it highly concise.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter, read-only list tool with strong annotations and no output schema, the description sufficiently conveys the core function. However, it could be slightly more helpful by mentioning the need for server_id or hinting at the return format, so it does not reach a perfect score.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema fully covers the single parameter server_id with a clear description ('MCP server id'), so the description does not need to add parameter details. Baseline 3 is appropriate because schema coverage is 100%.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'List the resources exposed by an MCP server' uses a specific verb and resource, clearly distinguishing this from sibling tools like lyzr_list_mcp_servers (lists servers) and lyzr_list_mcp_server_tools (lists tools). It unambiguously identifies what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies use when you need to see resources for a given MCP server, but it does not explicitly state when to use it over alternatives or mention any exclusions. The distinction from sister list tools is embedded in the resource vs tool wording but not made explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_list_provider_credentials_by_userA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare the tool is read-only, idempotent, and open-world, so the safety profile is covered. The description adds no additional behavioral context such as return format, pagination, or sensitivity of credentials. It essentially restates the operation without enriching the agent's understanding.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that directly states the tool's purpose. No wasted words or redundant elaboration, achieving exactly what is needed with minimal text.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter list operation with strong annotations, the description is mostly complete. However, it refers to 'a user's credentials' without clarifying whether the user is the current authenticated user or if a user parameter is expected (though not in the schema). This minor ambiguity prevents a perfect score.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with both parameters having clear descriptions ('The provider type to filter by', 'The provider id to filter by'). The description adds no extra meaning beyond the schema; it merely echoes the parameter names. Baseline 3 is appropriate when schema handles parameter documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and clearly identifies the resource ('a user's credentials') and the filtering criteria ('given provider type and provider id'). It differentiates from the sibling tool 'lyzr_list_provider_credentials_by_type' by scoping to a user, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for listing credentials with user, type, and id scoping, but it does not provide explicit guidance on when to use this over the sibling 'by_type' tool or other credential-listing tools. There are no declared exclusions or alternatives, leaving usage context implicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_list_shared_skillsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds the scope 'available to the account', which clarifies the resource boundary. However, it provides no further behavioral details such as pagination, ordering, or whether the list includes unpublished skills.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence, immediately front-loaded with the action and resource. Every word earns its place, with no filler or redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple, zero-parameter, read-only list tool, the description is largely complete: it states the resource and scope. The absence of an output schema means the return format is not explicitly described, but the verb 'List' strongly implies a list result. Overall, it is sufficient for the tool's low complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, and the description correctly implies that no inputs are needed. Schema coverage is 100% with an empty properties object, so the description adds no parameter-level meaning, but the baseline for a zero-parameter tool is 4.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and a clear resource ('all shared skills available to the account'). It clearly states what the tool does and distinguishes it from sibling tools like list_tools or get_skill_usage by focusing on shared skills specifically.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives no explicit guidance on when to use this tool versus alternatives. It does not mention exclusions, recommended contexts, or relationships to sibling tools like lyzr_list_tools or lyzr_get_skill_usage. The usage is only implied by the tool name and resource type.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_list_user_audit_logsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, which covers the safety profile. The description adds the user-scoping constraint but does not disclose additional behavioral details such as pagination behavior, rate limits, or permission requirements. Given the annotations, this is an acceptable baseline but not enriched.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that front-loads the action and resource. Every word earns its place with no redundant information or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple read-only list operation, the description is largely complete. It identifies the key scope (user by ID) and notes optional filters, while the schema covers all parameters and annotations cover safety. However, it does not differentiate from the many sibling audit log tools, which is a minor completeness gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all 8 parameters are well-documented in the schema itself. The tool description only says 'with optional filters' and does not add any extra meaning beyond what the schema provides. This aligns with the baseline for full schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Get audit logs for a specific user by ID, with optional filters.' It uses a specific verb ('Get') and resource ('audit logs for a specific user'), which distinguishes it from sibling tools like list_org_audit_logs or list_my_audit_logs by explicitly targeting a user ID.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage but does not explicitly state when to use this tool over alternatives. It mentions 'optional filters' but provides no guidance on when to choose this tool compared to other audit log listers (e.g., list_org_audit_logs, list_resource_audit_logs). The context is clear from the name and description, but no exclusions or alternatives are named.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_list_voicesA
  3.8/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds no behavioral information beyond what the annotations already declare (readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false). It does not mention authentication, rate limits, output structure, or any side effects, and unlike the get_calls example, it adds no extra operational constraints. This is a minimal disclosure that relies entirely on annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that directly states the action and object with no redundant words. It is front-loaded with the verb 'List' and efficiently conveys the tool's function within eight words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a parameterless, read-only list operation, the description adequately states the tool's purpose. The annotations cover safety and idempotency, and the absence of an output schema is less critical for a simple list operation. However, the description could be slightly more explicit about what the returned voice configuration contains, so it's not a perfect 5.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, and the schema is an empty object. Per the rubric, a zero-parameter tool gets a baseline of 4. The description doesn't need to explain parameters, and it doesn't attempt to add semantics for nonexistent inputs.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'List' and identifies the resource as 'available ElevenLabs voices configuration', clearly distinguishing it from the many other list tools in the sibling list. It adds provider context (ElevenLabs) beyond the name/title, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is used when the agent needs to retrieve available ElevenLabs voice settings, but it provides no explicit guidance on when to prefer it over alternatives or any exclusions. Since the tool is a unique read-only list operation with no parameters, the usage context is reasonably inferable, but the description itself does not articulate it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_list_workflowsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations (readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false) already convey that this is a safe, read-only, repeatable operation. The description's 'all' adds the scope that no filtering or parameters are applied, which is a modest behavioral detail beyond the annotations, but it does not mention pagination or return format.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence ('List all workflows.') that is immediately front-loaded with the action and object. There is no filler, redundancy, or unnecessary detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only, highly annotated list tool, this description is adequately complete. It clearly states the operation, and the annotations cover safety. Without an output schema, it does not spell out the return value, but for a simple 'list all' operation, the meaning is self-evident and sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has zero properties, so there are no parameter semantics to document. The description's 'all workflows' reinforces that no arguments are needed, aligning with the 0-parameter baseline of 4.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'List all workflows' uses a specific verb ('List') and resource ('workflows'), with 'all' clarifying that it returns the full set rather than a single item. This distinguishes it clearly from lyzr_get_workflow (single workflow) and CRUD tools like create/update/delete.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives no guidance on when to use this tool versus alternatives. It does not mention that lyzr_get_workflow is for retrieving a single workflow, nor does it discuss any filtering or prerequisites, so the agent receives no usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_livesource_ext_browse_childrenA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds minimal extra context beyond the scope ('within a SharePoint drive folder') and does not mention behavior like optional folder_path defaulting to root or return format, but this is acceptable given the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single concise sentence that is front-loaded with the action and resource. Every word earns its place, with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple nature of the tool, the description, combined with 100% parameter schema coverage and strong safety annotations, is largely complete. It does not explain optional folder_path behavior or return format, but the core action and parameters are clear enough for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3. The description provides a brief context that files/folders are listed within a drive folder, but adds no additional meaning about parameters beyond what the schema already states.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists files/folders within a SharePoint drive folder, using a specific verb and resource. It distinguishes from sibling tools like browse_sites and browse_drives by focusing on children within a drive.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit when-to-use or alternative guidance is provided. The usage is implied by the name 'browse_children' and the description, but it does not clarify how it fits with browse_sites or browse_drives, nor mention any prerequisites like needing a selected drive.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_livesource_pauseA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, which the description does not contradict. The description adds minimal extra context by specifying that it pauses 'syncing' rather than deleting or modifying the source, but it does not explain behavioral effects such as whether ongoing syncs are stopped or whether the source remains retrievable until resumed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, complete sentence with no filler or redundant phrases. It is front-loaded with the action verb and clearly communicates the tool's purpose, earning every word.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the low complexity of the tool (two required string parameters, no output schema) and the informative annotations (idempotent, non-destructive), the description is sufficiently complete for an agent to understand and invoke the tool. It clearly states what action is performed, and the lack of details about side effects is compensated by the annotations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers 100% of the parameters, with descriptions 'Knowledge base id' and 'Live source id'. The tool description adds no additional parameter information beyond what the schema already provides, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb phrase 'Pause syncing' and identifies the resource as 'a live source', making the tool's action immediately clear. It distinguishes itself from sibling tools like lyzr_livesource_resume, lyzr_livesource_remove, and lyzr_livesource_sync by specifically targeting the pause action.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when the user wants to halt syncing for a live source, but it does not explicitly state when to use this tool versus alternatives like resume or remove. No exclusions or context about prerequisites are provided, so guidance is only implied by the verb 'pause'.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_memory_getA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is clear. The description confirms a read-only fetch but adds no additional behavioral context (e.g., error handling, return format, or owner scoping). No contradiction 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence, front-loaded with the verb 'Fetch' and resource, containing zero redundant wording. Perfectly concise for the tool's simple purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simplicity of retrieving a single record and the presence of annotations, the description is nearly complete. It could mention what 'memory record' includes or error behavior, but likely unnecessary for this narrow operation under the given schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 50%, covering memory_id with 'Memory record id' but leaving owner_id undocumented. The description text does not add meaning for owner_id, only reinforcing the 'by id' purpose. It neither compensates for the gap nor complicates it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Fetch a single memory record by id' clearly states the action (fetch), the resource (memory record), and the scope (by id). It distinguishes this tool from sibling tools like lyzr_memory_list and lyzr_memory_search, which handle broader retrieval scenarios.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when you have a specific memory_id, but it does not explicitly state when to use this tool versus alternatives like lyzr_memory_search or lyzr_memory_list. No exclusion or alternative guidance is provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_memprovider_delete_aws_agentcore_resourceA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description's 'Permanently delete' reinforces the destructive nature but adds limited new behavioral context. It does clarify the target ('for a credential') and emphasizes irreversibility, but it does not disclose additional traits like specific side effects or authorization requirements.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence that conveys all necessary information without waste. It is front-loaded and efficient, earning a high score for conciseness and structure.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with one parameter and no output schema, the description combined with annotations provides sufficient context for an agent to invoke it. It covers the destructive, idempotent nature and the target. However, it does not specify behavior when the resource doesn't exist or whether the credential must still be valid, which would improve completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the parameter 'credential_id' is described as 'The AWS AgentCore credential id'. The description adds minimal meaning beyond this, just clarifying that it is the credential whose memory resource gets deleted. Since the schema already documents the parameter fully, the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Permanently delete the AWS AgentCore memory resource for a credential.' It specifies the verb (delete), the resource (AWS AgentCore memory resource), and the scope (for a credential), which distinguishes it from siblings like lyzr_memory_delete (general memory deletion) and lyzr_credential_delete (credential deletion).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The tool's purpose is implied by the name and description, but there is no explicit guidance on when to use it versus alternatives, such as checking resource status first or using a different deletion tool. It does not clarify when not to use it or mention prerequisites like ensuring the credential no longer needs the memory resource.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_memprovider_list_providersA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint and idempotentHint, covering safety. The description adds a small scope detail ('available for agents'), but does not mention output format, potential empty results, or any authentication aspects. This is minimal beyond annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler. Every word contributes to understanding the tool's purpose and scope.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple, parameterless, read-only listing tool, the description is mostly sufficient. However, no output schema exists, and the description does not hint at what fields or types of providers are returned, leaving a minor gap in full self-contained context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, and the input schema is empty, so schema coverage is complete. The baseline for parameterless tools is 4, and the description has nothing to add.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool's action (list) and resource (memory providers available for agents). This distinguishes it from sibling tools like lyzr_memprovider_get_provider, which fetches a specific provider, and from non-memory provider listing tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives no guidance on when to use this tool over alternatives such as lyzr_memprovider_get_provider or provider configuration tools. There are no stated use cases, exclusions, or relationship to other memory management functions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_memprovider_validate_mem0A
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. The description adds no further behavioral context (e.g., what happens on invalid credentials, response format, or side effects). It is consistent with annotations, but contributes no extra transparency beyond the schema and hints.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence containing no filler or redundant information. It is front-loaded with the action and resource, making it easy to parse quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple validation tool with one fully documented parameter and safety annotations, the description is nearly complete. The only gap is the absence of an output schema or any mention of the return value, but since the purpose is validation, the agent can infer that a status/result is returned. This is acceptable given the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with the credential_id property described as 'The Mem0 credential id'. The tool description does not add any additional parameter semantics beyond that, so the baseline of 3 is appropriate given that the schema fully documents the single parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Validate Mem0 memory provider credentials' clearly states the action (validate), the target resource (Mem0 memory provider credentials), and is specific enough to distinguish from sibling validation tools like those for AWS AgentCore or Supermemory. 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 Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when Mem0 credentials need to be validated, but it does not provide explicit guidance on when to choose this tool over alternatives such as lyzr_memprovider_validate_supermemory or mem0_status. No exclusions or alternative mentions are present, so usage context is only implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_ops_get_dashboardA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already disclose readOnlyHint=true and idempotentHint=true, so the safety profile is known. The description adds only the date-range and agent-scoping context, which is useful but does not disclose additional behaviors such as whether the result is paginated, aggregated, or subject to any 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler. It conveys the essential information efficiently and is well-structured for quick parsing.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only dashboard fetch with good annotations and full schema coverage, the description is largely adequate. However, since there is no output schema, a brief mention of what kind of metrics or data the dashboard includes would improve completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% with clear descriptions for start_date, end_date, and agent_id. The description's mention of 'date range' and 'scoped to one agent' simply restates what the schema already conveys, adding no new semantic depth.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Fetch') and resource ('operations dashboard'), and clearly scopes the operation by date range and optional agent. This distinguishes it from sibling dashboard-like tools such as lyzr_get_traces_dashboard and lyzr_ops_get_traces, which target different resources.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context: when the user wants the operations dashboard for a date range. However, it does not explicitly state when to prefer this over alternatives like lyzr_ops_get_traces or lyzr_get_traces_dashboard, nor does it mention any exclusions or prerequisites.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_remove_channel_agent_routeA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already communicate destructiveHint=true and idempotentHint=true, so the description does not need to restate these. However, it adds no extra behavioral context, such as what exactly happens to the route, whether the operation is reversible, or any access requirements.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, front-loaded sentence communicates the core action without waste. Every word contributes to understanding, making it appropriately concise for a straightforward removal operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with two well-documented parameters and rich annotations covering destructiveness and idempotency. The description covers the core behavior sufficiently, though it leaves some ambiguity about what an 'agent route' is and what happens after removal.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully describes both required parameters (channel_id and agent_id) with 100% coverage. The description adds no additional parameter-level meaning, but none is needed given the schema is complete and self-explanatory.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'remove' and names the resource 'agent route from a channel', which is unambiguous. It clearly distinguishes from the sibling 'lyzr_add_channel_agent_route' and related channel management tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implicitly tells when to use this tool: whenever an agent route must be removed from a channel. However, it does not explicitly contrast with alternatives or state prerequisites, such as verifying the route exists or using the add tool for the reverse operation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_report_get_statusA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the behavior that download_url appears when the report is ready, which is useful. However, it does not disclose other behavioral aspects like response statuses or what happens before readiness.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that gets straight to the point. Every word adds value, with no redundant or filler content. The key behavior (download_url) is front-loaded and clearly stated.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with one parameter and strong annotations. The description covers the core purpose and the most important output behavior (download_url when ready). It lacks details about the exact response structure, but for a basic status poll, it is mostly adequate. A 5 would require more specificity around possible status values or the full return format.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides 100% coverage for job_id with the description 'The report job id'. The tool description simply refers to a 'report job' without adding syntax, format, or relationship details beyond the schema. Since schema coverage is high, the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose with a specific verb ('Get') and resource ('status of a report job'), plus the key detail about download_url. This distinguishes it from siblings like lyzr_ops_generate_report and lyzr_report_list, which handle creation and listing rather than status.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies a polling workflow ('once it is ready') but does not explicitly say when to use this tool versus alternatives such as lyzr_get_task_status or lyzr_report_list. No exclusion criteria or alternative tools are mentioned, so usage guidance is only implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_semantic_model_get_descriptionsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds only that descriptions are 'saved', implying a read of persisted data, but does not disclose return format, error behavior, or any interaction with a connected database beyond what annotations imply. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, tightly worded sentence that conveys the essential action and scope without any fluff or redundancy. Every word earns its place, making it highly efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only getter with rich annotations and 100% schema coverage, the description provides the core purpose sufficiently. However, it could be more complete by noting that it only returns descriptions that were previously saved, and it does not explain what the return structure looks like (though no output schema exists). Given the tool's simplicity, this is a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% with 3 required parameters (table_name, database_id, rag_config_id), each having at least a basic description. The tool description does not add meaning beyond the schema; it merely restates the table/database scope. Baseline 3 is appropriate since the schema handles the parameter documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb ('Get') and resource ('saved table and column descriptions') scoped to 'a table in a database'. It is distinct from sibling semantic model tools like save_documentation or remove_documentation, and its purpose is 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 Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The intended use is implied by the description (retrieve previously saved descriptions), but it does not provide explicit guidance on when to use this vs. alternatives, nor does it mention prerequisites like needing an existing database connection or saved documentation. There are no exclusions or when-not-to-use statements.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_semantic_model_get_task_statusA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, making the safe read nature clear. The description adds the semantic-model context and example but does not disclose return format, polling behavior, or how to interpret statuses. Adequate but not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, front-loaded sentence with no filler. The example adds helpful specificity without bloat, making it highly concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple status-polling tool with one documented parameter and strong annotations, the description is mostly sufficient. However, it does not mention that task_id is typically returned by task-creation tools, and the absence of an output schema leaves the response format unspecified. Slightly under-specified.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema fully documents the only parameter (task_id as 'Task id to poll'), achieving 100% coverage. The description adds no extra parameter semantics, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Get the status of a semantic-model background task' with a concrete example ('save_documentation_task'). This clearly identifies the tool's action and resource, distinguishing it from generic task status tools like `lyzr_get_task_status`.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this tool versus the generic `lyzr_get_task_status` or other domain-specific status tools. The example implies it is for semantic-model tasks, but there are no exclusions or alternatives mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_semantic_model_table_previewA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to repeat these. The description adds no extra behavioral context beyond the basic action, but it does not contradict the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that is concise and front-loaded. It contains no fluff or redundant information, making it easy to parse quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only preview tool with full annotation coverage and complete parameter schemas, the description is adequately complete. It clearly states the purpose and context, though it could optionally mention the return format or row limit, but this is not essential given the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter having a clear description ('Table name to preview', 'Database id', 'RAG config id'). The tool description adds no additional semantic meaning beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Preview rows of a table in a connected database' uses a specific verb ('Preview') and clearly identifies the resource ('rows of a table in a connected database'). It distinguishes this from sibling tools like 'lyzr_semantic_model_list_tables', which lists tables rather than their contents.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage by stating what the tool does ('Preview rows'), but it does not explicitly provide when-to-use guidance or alternatives. It lacks any mention of exclusions or comparisons with related tools like 'lyzr_semantic_model_list_tables'.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_session3_ancestryA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds useful context by specifying 'root to leaf' ordering, but it does not describe the return format, error behavior, or whether the chain includes the root session itself. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no redundant words. It efficiently states what the tool does and the ordering semantics.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with one parameter, strong annotations, and no output schema, the description is mostly sufficient. The 'root to leaf' phrase implies an ordered chain, but slightly more detail about the returned structure would make it fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with the single parameter session_id already described as 'Session id to trace ancestry for.' The description does not add additional parameter-level detail, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('ancestry chain of a v3 session') and clarifies ordering with 'root to leaf.' This clearly distinguishes the tool from related siblings like session3_tree and session3_list_branches.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies use when the ancestry chain is needed, but it does not explicitly state when to prefer this over closely related session3 tools or mention any exclusions. Given the many sibling tools, more explicit guidance would be helpful.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_session_create_for_agentA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate this is a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds 'bound to a specific agent' but does not disclose additional behavioral traits like side effects, permissions, or persistence behavior. It is consistent and adequate for a simple create operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with zero wasted words. It conveys the essential operation and scope effectively.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the rich schema (all parameters described), annotations, and the simple nature of a create operation, the description is adequate. No output schema exists, so return values need not be explained. A minor gap is the lack of explicit guidance on when to prefer this over the general session_create tool, but the description covers the core purpose.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and the description does not add significant value beyond what the schema already provides. The phrase 'bound to a specific agent' clarifies the purpose of agent_id but is already implied by the parameter description. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb ('Create'), resource ('session'), and scope ('bound to a specific agent'). It effectively differentiates from the sibling tool lyzr_session_create by emphasizing the agent binding, which is the key distinguishing factor.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when a session needs to be created for a specific agent, but it does not explicitly mention alternatives or when not to use it. Given the existence of lyzr_session_create as a sibling, explicit guidance would improve the score.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_sharing_list_groupsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds the pagination behavior, but it does not clarify what 'sharing groups' contain, how results are ordered, or what a caller should expect in the response.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that front-loads the action and resource, immediately followed by the key behavioral trait (paginated). There is no filler or redundant restatement beyond the title.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list operation, the description plus annotations and fully documented parameters are largely sufficient. It could be more complete by explaining what constitutes a sharing group or how this list relates to other sharing-list tools, but the minimal context does not create a serious gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully documents both parameters ('page' with default 1 and 'limit' with default 10), so the schema carries the semantic weight. The description only reinforces that the listing is paginated, adding marginal meaning beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('List') and resource ('sharing groups'), and adds 'paginated' to convey the operation's scope. It is immediately distinguishable from sibling sharing-group tools like create/get/update/delete/share, as well as related list tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: when you need a paginated list of sharing groups. However, it does not explicitly mention when not to use it, nor does it point to alternatives such as lyzr_sharing_get_group or lyzr_sharing_list_accessible.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_update_org_llm_fallbacksA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds the important behavioral detail that this is a full replacement (overwrite) rather than a merge or partial update. However, it does not disclose side effects, permission requirements, or validation behavior, leaving gaps beyond what annotations provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is 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 action, target, and input format while remaining easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With a single parameter, rich schema descriptions, and no output schema, the description plus schema fully covers the operation's essentials. The description is brief but sufficient for a straightforward replace operation. Minor deduction for not explicitly stating the entire chain is overwritten (though 'Replace' already implies this).

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: the fallbacks array is described as 'Ordered list of fallback LLM entries', and each sub-property (priority, provider_id, model, credential_id) has a clear description. The tool description adds no additional parameter meaning beyond the redundant phrase 'given ordered list', so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Replace') and the resource ('organization's LLM fallback chain'), distinguishing it from the sibling tool lyzr_get_org_llm_fallbacks and other update tools. The verb and object 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 Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is used when the organization's fallback chain needs to be replaced, but it does not explicitly state alternatives (e.g., get_org_llm_fallbacks for reading) or conditions for non-use. The guidance is implicit rather than explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_world_model_add_test_casesA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate a mutating, non-destructive, non-idempotent operation. The description adds no additional behavioral context beyond 'add', such as whether duplicates are allowed, if the world model must exist, or 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, concise sentence that directly states the purpose without any redundant or filler content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple add operation, the description together with the schema and annotations is mostly sufficient. It lacks any context about relationship to the world model lifecycle or evaluation workflow, but no critical information is missing for basic invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all parameters are already documented in the schema. The description does not add any extra meaning or examples beyond what the schema provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states the action (add), resource (test cases), and target (world model), distinguishing it from siblings like update_test_case, delete_test_case, add_personas, and add_scenarios.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The usage is implied by the name and description, but there is no explicit guidance on when to use this tool versus updating or deleting test cases, or any prerequisites such as the world model needing to exist.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_world_model_createA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations show readOnlyHint=false, so the create action is consistent. The description adds that a world model is built from a source agent and that the world_model_id is returned, but it does not mention side effects, permissions, or asynchronous behavior. This adds some context but not extensive.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One sentence, front-loaded with the verb, includes a clarifying parenthetical and return value. Every word is purposeful with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple 2-parameter create tool with annotations present, the description covers the essential aspects: action, source, and return. It lacks some context about prerequisites or how this tool fits with other world-model sibling tools, but it is sufficiently 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.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides full descriptions for both parameters (source_agent_id and name). The description's phrase 'simulation clone' adds slight conceptual context but no new parameter-level details, so it meets the baseline for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (Create), the resource (world model), the source (from a source agent), and the return value (world_model_id). It distinguishes itself from sibling tools like lyzr_world_model_get or lyzr_world_model_update by being the creation operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies its usage (when you need to create a world model) but does not explicitly contrast with alternatives like lyzr_clone_agent or lyzr_world_model_create_evaluation_run. No exclusions or preconditions are stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_world_model_dashboard_by_world_modelA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds that it returns a dashboard summary but does not disclose response format, pagination, or permissions. It is consistent with annotations and adds minimal but non-contradictory 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that is front-loaded with the action and resource. There is no redundant wording or filler, and every word adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter read-only fetch with strong annotations, the description is largely complete. However, it does not clarify what the dashboard summary includes or what a typical response looks like, leaving minor gaps for an agent expecting more detail.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The single parameter world_model_id is fully described in the schema with 100% coverage. The description does not add additional semantic details beyond what the schema already provides, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb ('Fetch'), the resource ('dashboard summary'), and the scope ('for a single World Model'). It distinguishes itself from the sibling lyzr_world_model_dashboard_overview by explicitly indicating it targets a single World Model, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage (fetch dashboard for a single World Model) but provides no explicit guidance on when to use this tool versus the sibling dashboard_overview tool or any other alternatives. The scope is clear but not the decision boundary.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_world_model_list_evaluation_runsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. The description adds the scope constraint 'for a given World Model' but that is also present in the schema. No additional behavioral details like pagination or ordering are disclosed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler. It directly states the action and scope with minimal words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple 1-parameter list tool with strong annotations, the description is sufficient. It clearly states what is listed and the required scope. It does not explain the return structure, but no output schema is present and the purpose is straightforward.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the parameter world_model_id has a clear description in the schema. The tool description does not add any extra meaning beyond what the schema already provides, so a baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'List' and clearly identifies the resource ('evaluation runs') and the scope ('for a given World Model'). This distinguishes it from sibling tools like get_evaluation_run and create_evaluation_run.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies that this tool is used to list all runs for a world model, but it does not explicitly mention when to use it versus alternatives like get_evaluation_run. No when-not-to-use guidance is provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_delete_aci_connectionA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=true, so the safety profile is known. The description adds no further behavioral context such as permanence or error handling, but doesn't contradict annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One sentence, directly states the operation and target. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple single-parameter delete with strong annotations, this is complete. No output schema is needed, and the parameter is fully documented.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides 100% coverage with a clear description for linked_account_id. The description's 'by its id' adds no additional meaning beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly specifies the action (delete), the resource (ACI linked account connection), and the method (by its id). It distinguishes from other delete tools like lyzr_delete_aci_configuration and lyzr_delete_composio_connection.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context (deleting an ACI linked account connection) but does not explicitly state when to use it versus alternatives, nor any prerequisites or exclusions. It's clear for a simple delete operation but lacks explicit differentiation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_dauA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and idempotentHint, covering the safety profile. The description adds useful context beyond annotations: the default date behavior (today UTC) and the timezone. This is sufficient for a simple read-only metric query.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, efficient sentence that front-loads the primary action ('Get') and immediately states the resource and optional parameter. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with one optional parameter, clear annotations (readOnly, idempotent), and no output schema, the description adequately covers what the tool does and its default behavior. There are no significant gaps for an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with the date parameter fully described as 'Date to query, ISO 8601 date-time (defaults to today UTC)'. The description merely repeats this default, adding no new semantic meaning beyond what the schema already provides. Baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool gets a daily active user count for a specific date, with a clear verb and resource. It doesn't explicitly distinguish from related siblings like get_mau or get_dau_trend, but the scope is unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The intended use is implied: when you need a DAU count for a given date. However, there is no explicit guidance on when to prefer this over alternatives such as get_mau or get_dau_trend, and no mention of exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_mau_trendA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds the time-window behavior ('over the last N months'), but this closely mirrors the parameter semantics and does not disclose return format or aggregation details, so it provides only marginal behavioral context beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is one concise sentence of ten words, fully front-loaded with the key verb and resource. Every word earns its place with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only analytics tool, the combination of the clear description, full schema coverage, and strong annotations (readOnlyHint, idempotentHint, openWorldHint) provides sufficient context. No output schema is present, but the trend output is intuitive from the description, and no further elaboration is needed for this low-complexity tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema fully documents the single parameter 'months' with a description, range, and default, achieving 100% coverage. The description adds no parameter information beyond what the schema provides, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Get'), resource ('monthly active users trend'), and scope ('over the last N months'), making its purpose immediately clear. It distinguishes itself from sibling tools like lyzr_get_mau (current MAU) and lyzr_get_dau_trend (daily active users) through the phrase 'monthly active users trend'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage—if you need a monthly active users trend, use this tool—but it does not explicitly state when to use it over alternatives or mention any exclusions or prerequisites. There is no guidance on comparing it with lyzr_get_dau_trend or lyzr_get_activity_metrics, leaving the agent to infer 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.

• lyzr_git_list_commitsA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, fully covering the safety profile. The description adds no extra behavioral context beyond the schema (e.g., pagination or return format), but it is consistent with the read-only nature, so no contradiction 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence of 12 words, with no wasted language. It efficiently conveys the action, target, and optional filter.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter, read-only tool with comprehensive annotations and schema, the description is sufficient. It identifies the target (agent's git repo), the action (list commits), and the optional filter (branch). The lack of an output schema is acceptable because the return type (a list) is clearly implied.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for both agent_id and branch, with the branch parameter already described as 'Branch to filter commits by'. The description merely restates this optional filter, adding little semantic value beyond what the schema provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'List' with a clear resource 'commits for an agent's git repo' and notes the optional branch filter. This clearly distinguishes it from sibling tools like lyzr_git_list_branches or lyzr_git_list_repo_files by targeting commit history 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/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage (when you need to see commit history) but does not explicitly state when to use this over related git tools like lyzr_git_get_commit_snapshot or lyzr_git_list_branches. No exclusions or alternative tool references are provided, so guidance is only implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_git_list_prsA
  3.9/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. However, the description adds no additional behavioral context (e.g., default PR state, sorting, or repository prerequisites). The phrase 'for an agent's git repo' merely restates the agent_id parameter, adding no new information.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence of eight words, front-loaded with the action and resource. It contains zero filler and is perfectly concise for a simple list operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only list tool with one well-documented parameter and strong annotations, the description is complete. It states the purpose and scope, and since no output schema exists, the phrase 'List pull requests' sufficiently implies the return of PR data. No additional information is needed for this complexity level.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers the only parameter (agent_id) with a clear description ('Agent id'), providing 100% coverage. The tool description adds no additional parameter semantics beyond the schema, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb-resource pair ('List pull requests') and scopes it to 'an agent's git repo.' This clearly distinguishes it from sibling tools like lyzr_git_list_commits and lyzr_git_list_branches. 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/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context: use this when you need to list PRs for a specific agent's git repo. It doesn't explicitly mention alternatives, but the resource is specific enough that an agent can infer when to use it. No exclusions are stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_git_save_file_contentA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds 'create or update' behavior beyond the readOnlyHint=false annotation, which is useful. However, it doesn't disclose that saving will overwrite existing content or create a git commit (though the 'message' param implies a commit). The annotations already cover mutation safety, so this is adequate but not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single sentence that is verb-first and directly states the purpose. No filler or redundant content; every word carries meaning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a straightforward write tool with full parameter documentation, the description is sufficient. It lacks explicit mention of prerequisites (e.g., repo must already exist) and whether a commit is automatically created, but these are inferable from the schema and the presence of git-related sibling tools.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage, so the schema already documents all parameters. The tool description adds a small semantic cue ('create or update') but does not explain parameter relationships or defaults, which is acceptable given the high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (save), the resource (file content), and the scope (agent's git repo). It explicitly includes create/update semantics, distinguishing it from read-oriented siblings like get_file_content and from governance/config tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context for when to use the tool: when you need to persist file content in an agent's git repo. It doesn't explicitly mention alternatives or exclusions, but the create/update phrasing makes the intended use obvious.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_git_validate_configA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already convey the tool is not read-only, not idempotent, and not destructive. The description adds the key insight that it does not save the configuration. Yet it does not disclose potential side effects (e.g., connecting to an external git provider, validating credentials) or what happens during validation. With annotations present, the bar is lower, but some transparency about validation's external interactions 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler. It immediately states the tool's action, target, and key differentiator, earning its place without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 8 parameters, full schema coverage, and annotations, but no output schema. The description clearly states the tool validates a config without saving, but it does not hint at the return value or success/failure semantics. Given the absence of an output schema, a note about what constitutes a successful validation would improve completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% parameter description coverage, so the baseline is 3. The description adds no parameter-specific context, but none is necessary since the schema fully documents each field, including defaults and self-hosted base URL usage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the verb ('Validate'), the resource ('git connection configuration'), and the scope ('for an agent'). The phrase 'without saving it' directly distinguishes this tool from lyzr_git_save_config and other persistence-related siblings, fully clarifying the tool's unique purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context by stating the tool validates a config without saving it, which distinguishes it from the save and disconnect operations among siblings. However, it does not explicitly name alternatives or provide when-to-use/when-not-to-use guidance, leaving room for improvement but not ambiguity.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kb_update_docs_metadataA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already communicate that this is a non-read-only, non-destructive, idempotent operation, so the bar is lowered. The description adds no behavioral caveats beyond what annotations and schema convey, such as the effect of omitting filters or whether metadata_updates merges or replaces existing fields. It neither contradicts the annotations nor adds meaningful transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that directly states the tool's purpose. Every word carries necessary information, with no filler, repetition, or irrelevant detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  While the schema and annotations cover parameters and safety, the description omits practical details such as what happens when no filter is provided, whether metadata updates are merged or overwritten, and what the tool returns. No output schema exists, so the description carries more responsibility for explaining behavior, leaving a noticeable gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already documents rag_id, filters, extra_fields, and metadata_updates. The description essentially restates the role of filters and metadata updates without adding extra meaning or usage nuance beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (Update), the resource (metadata on documents in a knowledge base), and the selection scope (matching a filter). This distinguishes it from sibling tools like lyzr_kb_delete_docs_by_filter and lyzr_kb_update, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear context for when to use the tool: when metadata on filtered knowledge base documents needs to be updated. It does not explicitly mention alternatives or exclusions, but the phrasing is specific enough to infer the intended use case.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_list_mcp_server_toolsA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no additional behavioral context such as pagination, output format, or permission requirements. Since annotations handle the key metadata, this is adequate but not enriched.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, well-structured sentence that directly states the tool's action and target. No wasted words, and it front-loads the key information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple list operation with one parameter, strong annotations, and no output schema. The description is sufficient for an agent to select and invoke the tool correctly. No additional context is necessary for such a low-complexity operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%: the only parameter, server_id, is documented as 'MCP server id'. The description does not add extra meaning beyond the schema. Per guidelines, with full schema coverage, a baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'List the tools exposed by an MCP server' uses a specific verb and resource, clearly distinguishing this tool from siblings like lyzr_list_mcp_servers (which lists servers) and lyzr_list_mcp_server_resources (which lists resources). It is unambiguous and directly reflects the tool's name and function.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when the user needs to see tools from a specific MCP server, but it does not explicitly state when to use this vs. alternatives, nor does it mention any exclusions or prerequisites. Given the large sibling tool list, explicit guidance would improve clarity, but the purpose is still inferable.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_livesource_ext_sync_permissionsA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate a non-read-only, idempotent mutation. The description adds the 're-check' example, implying verification, but it doesn't disclose whether the tool modifies the live source or only updates internal permission records. With annotations covering the safety profile, this is adequate but not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence with an illustrative example. Every word earns its place, and the structure is front-loaded with the primary purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter mutation tool, this is a minimal viable description. It lacks differentiation from the broader lyzr_livesource_sync sibling and does not mention expected outcomes or prerequisites, though annotations cover idempotency and non-destructiveness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema fully describes both parameters (rag_id and live_source_id) with 100% coverage. The description adds no additional parameter-level meaning, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Sync') with a specific resource ('access permissions for a live source') and a concrete example ('re-check SharePoint ACLs'). This clearly differentiates it from sibling tools like lyzr_livesource_sync, which likely handles broader synchronization.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The example 're-check SharePoint ACLs' provides clear context for when this tool is useful. However, it does not explicitly mention alternative tools or state when not to use it, though it is reasonably clear this is for permission-specific sync.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_livesource_list_credentialsA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and idempotentHint=true, so the read-only behavior is covered. The description adds no further behavioral details like pagination, return format, or auth requirements, but for a zero-parameter list operation this is adequate, though not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that leads with the verb and resource. Every word is informative, and there is no padding or repetition of the title or schema.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a low-complexity tool with no parameters and good annotations, the description is sufficient to convey what it does. It could explicitly say it returns all matching credentials, but the scope is clear from the 'available for use with live sources' qualifier.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has zero parameters and 100% coverage, so the baseline is 4. The description doesn't need to explain parameters because none exist; it correctly keeps the focus on the tool's purpose.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the action ('List') and the resource ('credentials available for use with live sources'), which distinguishes it from the generic credential list sibling. However, it doesn't explicitly name alternatives or highlight the difference, so it's clear but not fully differentiated.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'available for use with live sources' implies when this tool is appropriate—when the agent needs credentials tied to live sources. It provides clear context, but it doesn't explicitly mention exclusions or contrast with the generic lyzr_credential_list sibling.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_semantic_model_create_documentation_agentA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate this is a mutating, non-read-only operation. The description adds the creation context and the agent's purpose but does not disclose additional behavioral traits such as response format, side effects beyond creation, or any dependencies.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence, concise and front-loaded, with no wasted words. It communicates the key information efficiently.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has no output schema and is a create operation, the description would benefit from clarifying what the agent returns (e.g., agent ID) or any prerequisites like provider/model availability. The current description is adequate for basic selection but lacks this important contextual detail.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all six parameters are documented in the schema. The description adds no additional parameter-level semantics, leaving the schema to carry the burden. Baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a clear verb ('Create') with a specific resource ('new semantic-model documentation agent') and states its purpose ('generate table/column descriptions'). This distinguishes it from the generic sibling tool lyzr_create_agent.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies when to use this tool: when you need a documentation agent specifically for semantic models. It does not explicitly mention alternatives or exclusions, but the specialized purpose and naming make the use case evident.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_session3_branchA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=false and destructiveHint=false. The description adds minimal behavioral context beyond the schema—it mentions branching from a message, but this is already in the required parameter from_message_id. It does not disclose side effects, return values, or prerequisites beyond the schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is one sentence of 10 words, front-loaded with the action. Every word contributes meaning, with no filler or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description does not explain what the tool returns or any postconditions (e.g., how to reference the new branch). It adequately conveys the core action but leaves a gap for the agent regarding expected results.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3. The description does not add any parameter semantics beyond what the schema already provides; all parameters are fully described in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Branch') and resource ('v3 session') with a precise starting point ('from a specific message'). This clearly distinguishes it from sibling tools like session3_create or session3_list_branches.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly states what the tool does and the context (v3 session, from a message). While it doesn't explicitly list when not to use it or alternative tools, the unique 'branch' verb and resource make the usage context unmistakable.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_update_agentA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide key safety traits: readOnlyHint=false (mutation), idempotentHint=true (repeated updates safe), destructiveHint=false (not destructive). The description adds little beyond 'update' and 'existing', such as whether it is a partial update (only provided fields) or what happens if the agent does not exist. It does not contradict annotations, and the annotations carry most of the burden.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence that lists the updatable fields without any wasted words. It front-loads the verb and resource, making the tool's purpose immediately clear.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple update tool with no output schema, but the description does not state the return value (e.g., updated agent object) or explicitly note that only provided fields are updated. It also does not mention any prerequisites beyond 'existing' agent. Given the low complexity and good schema/annotations, some gaps remain but are not severe.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so each parameter already has a clear meaning ('New goal', 'New agent name', etc.). The description lists the field names but adds no additional semantic detail beyond the schema. Baseline of 3 applies since the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Update') with a clear resource ('existing Lyzr agent') and enumerates the exact fields that can be modified (name/role/goal/instructions/temperature/description). This clearly distinguishes it from sibling tools like lyzr_create_agent, lyzr_delete_agent, and lyzr_get_agent.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the use case: modify fields on an agent that already exists, which is distinct from creating, deleting, or fetching. However, it does not explicitly state when not to use it or mention alternatives (e.g., 'for creating a new agent, use lyzr_create_agent'). No explicit exclusions, but context is clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_world_model_getA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, covering the safety profile. The description adds no extra behavioral context beyond these annotations; it does not mention return format, error behavior, or auth needs, but this is acceptable for a simple fetch operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single front-loaded sentence with no filler or redundant phrasing. It efficiently conveys the tool's purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter get-by-id tool with strong annotations and no output schema, the description is fully sufficient. It clearly indicates what resource is fetched and the required identifier, leaving no ambiguity for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage for the single required parameter 'world_model_id' with a clear description. The tool description's 'by id' mirrors this without adding extra meaning such as format, examples, or constraints, so it stays at the baseline for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Fetch a world model by id.' uses a specific verb ('Fetch') and resource ('world model') with a clear scope ('by id'). It distinguishes itself from siblings like list, create, delete, and update operations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when a world_model_id is held, but does not explicitly state when to use this tool over alternatives like lyzr_world_model_list_by_agent. There is no mention of exclusions or prerequisites, so the guidance is only implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_world_model_get_evaluation_runA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, covering the safety and side-effect profile. The description adds no additional behavioral context beyond 'Fetch a single...', such as return format or error behavior. Since annotations already provide the key transparency, a 3 is appropriate—not lower, but the description does not enrich beyond the structured metadata.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence: 'Fetch a single evaluation run by its id.' It is front-loaded with the verb and resource, contains no filler, and every word contributes value. 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.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple get-by-id tool with one parameter, a clear schema, and strong annotations, this description is complete. It accurately states what is returned (a single evaluation run) and the required input. There is no output schema, but the tool's simplicity means the description is sufficient for an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: the only parameter 'run_id' is described as 'The evaluation run id'. The tool description says 'by its id', which reinforces but does not add new meaning. With full schema coverage, baseline 3 is correct.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Fetch' combined with the resource 'a single evaluation run' and the method 'by its id'. This clearly distinguishes it from sibling tools like 'lyzr_world_model_list_evaluation_runs' (list all) and 'lyzr_world_model_create_evaluation_run' (create). The purpose is immediately 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/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: you need a specific run_id to fetch a single run. However, it does not explicitly state when to use this tool over alternatives, nor does it mention any exclusions or prerequisites beyond the required id. The guidance is implicit and minimal, so it earns a mid-level score.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_activate_agent_versionA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate this is not read-only, not destructive, and not idempotent. The description adds the key behavioral detail that activation makes the specified version live, which explains the state change. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no wasted words. It effectively conveys the action and result in minimal space.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with two well-documented parameters and no output schema, the description is sufficiently complete to understand the purpose and effect. It could optionally mention that the previous version is replaced, but this is implied and not necessary for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Both parameters (agent_id and version_id) are fully described in the schema with 100% coverage. The description does not add extra meaning beyond the schema, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific action ('Activate a specific version of an agent') and the outcome ('making it the live version'), which distinguishes it from sibling tools like lyzr_list_agent_versions (listing) and lyzr_get_agent_version (retrieving).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use this tool (when you want a particular version to become live) but does not explicitly mention prerequisites (e.g., listing versions first) or contrast with alternatives like updating an agent directly. Usage is clear but lacks explicit guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_bulk_delete_agentsA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds 'permanently', emphasizing irreversibility, which is useful beyond the generic destructive hint. However, it doesn't mention potential side effects on related data, but the low complexity and existing annotations make this acceptable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Single sentence, directly front-loaded with the action and resource. Every word earns its place; no wasted content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (one parameter, no output schema), the description is sufficient. It clearly communicates the operation and scope. It could mention potential side effects or return format, but for a bulk delete, this is a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides 100% coverage with a clear description ('List of agent IDs to delete'). The description's 'by id' is redundant with the schema, adding no new semantic value beyond what the schema already specifies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('permanently delete'), the resource ('multiple agents'), and the method ('by id'). It distinguishes from the sibling 'lyzr_delete_agent' by explicitly indicating bulk operation, making it 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/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The usage context is implied by the description and sibling name ('bulk delete'), but there is no explicit when-to-use or alternative guidance. It doesn't mention that this is for multiple agents or contrast with single delete, though that can be inferred.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_bulk_delete_tool_credentialsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is clear. The description adds little beyond restating the batch nature; it does not disclose additional effects like cascading deletions or reversibility, but with annotations present, this is an acceptable baseline.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, tightly-constructed sentence with no redundant words. Effectively communicates the core action and scope.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter delete tool with annotations covering destructiveness, the description is sufficient. It lacks only an explicit statement about irreversibility, which is already implied by the destructiveHint annotation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% ('Tool credential ids to delete'), and the description's 'by id' merely paraphrases the parameter. No additional semantic detail is given, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Delete') and resource ('multiple tool credentials') with a scope ('by id in one call'). It clearly differentiates from the sibling single-delete tool (lyzr_delete_tool_credential) by emphasizing 'multiple' and batch operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'in one call' provides clear context for batch deletion, implying usage when deleting multiple credentials at once. It does not explicitly name the alternative single-delete sibling, but the bulk/multiple framing makes the appropriate scenario clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_create_agentA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate this is a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds the useful detail that it returns the new agent_id, but it does not disclose other potential side effects, such as uniqueness constraints, persistence guarantees, or permissions required. That extra return-value context is helpful, but minimal, so a 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is only two sentences: one stating the primary action and one stating the result/return value. Every word earns its place, and the most important information is front-loaded. There is no redundant or filler content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a create tool with 8 parameters and no output schema, the description covers the key elements: what it does and what it returns (agent_id). It also ties into the broader workflow via 'to use with lyzr_chat.' However, it doesn't mention that name/role/goal/instructions are required (though the schema covers that) or any uniqueness/conflict behavior. Still, given the rich schema and annotations, it is reasonably complete for the agent to select and invoke the tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage with descriptions for all 8 parameters, so the baseline is 3. The description adds no parameter-specific details beyond what the schema already offers. It does not name or explain any of the parameters, so it neither adds nor detracts from the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Create a new Lyzr agent' with a specific verb and resource, and it explicitly distinguishes this from sibling tools like lyzr_update_agent, lyzr_delete_agent, and lyzr_list_agents. It also mentions the return value (agent_id) and its intended use with lyzr_chat, which further clarifies the tool's purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'to use with lyzr_chat' provides clear context that this tool is the prerequisite for creating an agent before chatting. However, it does not explicitly mention alternatives or exclusions (e.g., when to prefer lyzr_create_a2a_agent or lyzr_update_agent), so it stops short of full when-to-use vs when-not-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_create_agent_eval_resultA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the description does not need to restate these. It adds no extra behavioral context such as whether the submit inserts or overwrites records, auth requirements, or side effects. The description is consistent with annotations, but adds only domain 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no redundancy. Every word contributes to explaining what the tool does, making it concise and easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's moderate complexity (3 fully described parameters, annotations present, no output schema), the description is sufficient but leaves out some context such as return behavior or the prerequisite of an existing eval config. It is not incomplete enough to harm usage, but has room to add a bit more workflow context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with detailed descriptions for agent_id, agent_eval_id, and the structure of agent_eval_result_list. The description adds no parameter-specific details beyond the schema, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Submit') and clearly identifies the resource ('results of running an agent evaluation') with a scope ('pass/fail outcomes per eval case'). This distinguishes it from sibling tools like lyzr_create_agent_eval (which creates an eval config) and lyzr_get_agent_eval_result (which retrieves results).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'results of running an agent evaluation' gives clear context for when to use this tool: after an evaluation has been executed. It does not explicitly name alternatives or exclusions, but the intended workflow is implied, and the tool's relationship to related eval tools is understandable from the description.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_create_channelA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already disclose readOnlyHint=false and openWorldHint=true, indicating a mutating operation with potential side effects. The description adds minimal behavioral context ('routes an inbound messaging platform'), which hints at side effects like webhook setup but does not elaborate on specifics such as required credentials or idempotency. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence that immediately states the action and purpose. There is no redundant wording or filler, making it optimally concise and front-loaded for an agent to parse quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's moderate complexity (4 params, nested objects) and rich schema descriptions, the description provides sufficient context for an agent to understand the purpose and choose the tool. No output schema exists, but this is a create operation where the primary outcome (channel creation) is implied. The absence of return-value documentation is a minor gap, but not critical for invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers 100% of parameters with descriptions, including platform, config, agent_routes, and default_agent_id. The description adds only a high-level example of platforms (telegram, slack), which is already present in the schema. As schema coverage is high, a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Create' with a clear resource ('a channel configuration') and explains its function: routing inbound messaging platforms (e.g. telegram, slack) to Lyzr agents. This distinguishes it from sibling tools like lyzr_create_agent or lyzr_list_channels, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies when to use this tool: when setting up a new inbound messaging channel for Lyzr agents. It provides context (messaging platforms) and does not actively conflict with alternatives, but it does not explicitly mention exclusions or alternatives (e.g., lyzr_add_channel_agent_route for modifying routes). Thus it has clear context but no exclusion guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_create_contextA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=false and idempotentHint=false, so the description does not need to cover safety. It adds the useful behavioral detail that the new context is returned. However, it does not disclose behavior for duplicate names, potential overwrites, or scope, leaving some ambiguity beyond what annotations provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences with no fluff, front-loading the verb and resource. Every word earns its place, and it provides a clear, minimal statement of function and return value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple creation tool with full schema coverage and adequate annotations, the description covers the essential behavior (creates and returns). It could mention edge cases like duplicate names, but given the tool's simplicity and the presence of annotations, it is sufficiently complete for an agent to select and invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already describes both parameters ('Context name' and 'Context value') with 100% coverage. The description's phrase 'key/value' aligns with the schema but adds no additional nuance or format details, matching the baseline for full schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Create' and names the resource as 'named key/value context', which clearly distinguishes it from sibling tools like lyzr_list_contexts, lyzr_get_context, lyzr_update_context, and lyzr_delete_context. The added clause 'Returns the new context' further clarifies the tool's purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description makes the strong contextual implication that this tool is for creating a new context, whereas siblings handle listing, retrieving, updating, or deleting. However, it does not explicitly state exclusions or name alternative tools when not to use this one, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_create_feedbackA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare this as a non-read-only, non-idempotent operation; the description confirms the write intent. It adds the scoping detail that the feedback is tied to a RAG feedback config, but does not disclose additional behavioral traits such as side effects, prerequisites, or return behavior. With annotations present, this is acceptable minimal 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single sentence, front-loaded with the verb, no wasted words. It earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with four fully documented parameters and no output schema. The description combined with the schema provides enough context to understand the operation; it could mention expected return values, but that's not required given the schema richness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3. The description paraphrases the four parameters (human feedback, agent's output, RAG feedback config) but doesn't add format, constraints, or syntax beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (submit), the object (human feedback), and the context (on an agent's output for a given RAG feedback config). It distinguishes itself from siblings by specifying a unique feedback submission operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides clear context for when to use: submitting human feedback for a specific RAG feedback config. No explicit exclusions or alternatives are named, but the context is sufficient for this focused tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_credential_deleteA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already disclose destructive behavior (destructiveHint=true) and idempotency (idempotentHint=true). The description adds the important trait of permanence ('Permanently delete'), which is more specific than the generic destructive hint and implies irreversibility. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that front-loads the action ('Permanently delete') followed by the resource and scope. Every word contributes to clarity without fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with one parameter, no output schema, and good annotation coverage, the description adequately conveys the core behavior. However, it could mention potential side effects (e.g., impact on agents using the credential) or clarify it targets the generic 'credential' resource versus provider or tool credentials, which would enhance completeness given the sibling context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides 100% coverage for the single parameter (credential_id) with description 'Credential id'. The description's phrase 'by id' adds minimal extra meaning, not specifying format or any further semantics. Baseline 3 is appropriate since the schema fully documents the parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (permanently delete), the resource (credential), and the required identifier (by id). This distinguishes it from sibling tools like lyzr_credential_create, lyzr_credential_get, and lyzr_credential_update, making the tool's purpose 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/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is used when deleting a credential, but provides no explicit guidance on when not to use it or alternatives. Given the large number of similar delete tools (e.g., lyzr_delete_provider_credential, lyzr_delete_tool_credential), the description does not clarify which credential type it applies to, leaving room for confusion.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_delete_agentA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already signal that this is a destructive, non-read-only operation. The description adds the word 'permanently,' reinforcing irreversibility. It does not disclose potential side effects like whether associated sessions or knowledge bases are also deleted, or what happens if the agent does not exist. Given the annotations cover the core safety profile, this modest addition warrants a midpoint 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, eight-word sentence that immediately states the action, object, and identifier. Every word is necessary, with no fluff or repetition. It is perfectly sized for the tool's simplicity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  As a simple, single-parameter delete tool with strong annotations (destructive, non-read-only), the description covers the essential purpose. It lacks a note about return values or consequences for dependent resources, but given the tool's low complexity and the annotations' coverage, it is sufficiently complete. A 5 would require explicit statements about side effects or response format.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already fully documents the single parameter agent_id with the description 'The agent_id to delete.' The tool description repeats this ('by its agent_id') without adding extra context such as where to obtain the agent_id (e.g., from lyzr_list_agents). Since schema coverage is 100%, the description adds no meaningful parameter semantics beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('delete') and a specific resource ('Lyzr agent') with a clear method ('by its agent_id'). It unambiguously distinguishes this from sibling tools like lyzr_update_agent or lyzr_list_agents. The title also reinforces 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/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies the tool is for deleting a single Lyzr agent, and the word 'permanently' provides an important caution. However, it does not explicitly mention alternatives (e.g., lyzr_bulk_delete_agents for multiple agents) or exclusions (e.g., cannot delete published agents). Still, the singular 'delete_agent' name and resource scope provide clear context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_delete_assetA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and readOnlyHint=false, so the description adds the important nuance of permanence with 'Permanently delete'. However, it does not disclose other behavioral details such as side effects, error behavior when the asset does not exist, or authorization requirements. Given the strong annotation coverage, a score of 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence with no filler, efficiently conveying the action, resource, and permanence. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple, one-parameter delete tool with strong annotations and schema coverage, the description is largely complete. It communicates the essential permanence aspect. It does not explain return values or failure behavior, but these are not required given the tool's simplicity and lack of an output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage for the only parameter, asset_id, with an 'Asset id' description. The tool description's 'by id' simply echoes the parameter, adding no new meaning beyond what the schema already conveys. Baseline 3 applies due to high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Permanently delete an asset by id' clearly states the action (delete), resource (asset), and method (by id). It distinguishes this tool from sibling delete tools for other entity types (e.g., agents, contexts).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The context is clear: use this tool to permanently remove an asset by its id. There are no alternative delete-asset tools among siblings, so explicit alternative guidance is less critical. It does not mention prerequisites or when not to use, but for a simple delete operation the context is sufficient.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_delete_providerA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint: true and readOnlyHint: false. The description adds 'permanently,' which discloses irreversibility—a behavioral nuance not covered by annotations. It also clarifies the deletion is by id, aligning with the schema. No contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single six-word sentence, front-loaded with the action and target. It is succinct and contains no unnecessary words, earning a perfect score.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter delete operation with full schema coverage and strong annotations, the description is largely complete. It covers the action, target, and permanence. It omits output details, but the lack of an output schema makes this a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers 100% of parameters, with provider_id described as 'The provider id to delete.' The description's 'by id' adds no meaning beyond what the schema already provides, so the baseline score of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Permanently delete a provider by id' uses a specific verb ('delete') and clearly identifies the resource ('provider'), adding 'permanently' to convey irreversibility. This distinguishes it from sibling CRUD tools like lyzr_update_provider and lyzr_get_provider.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions. Usage is implied by the name and description (delete provider), but there is no guidance comparing it to related operations like update or get.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_a2a_agent_card_convenienceA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description does not need to restate safety. It adds meaningful behavioral context by indicating the request uses a convenience path rather than the standard .well-known URL, which helps the agent understand what is being done differently.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is one sentence, front-loaded with the verb and resource, and contains no filler or repetition. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read tool with a single fully documented parameter and strong annotations, the description is nearly complete. It could explicitly mention the sibling standard-path tool or describe the returned card's content, but the current information is sufficient for an agent to select and invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The single parameter agent_id is fully described in the schema ('The A2A agent id'), and schema coverage is 100%. The description adds no additional parameter meaning beyond the schema, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Fetch') and resource ('A2A agent card'), and clearly distinguishes this tool from the standard path variant by explicitly stating it uses the convenience path without .well-known/agent-card.json. This makes the tool's intent and differentiating scope 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/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this is the convenience-path variant, but it never explicitly states when to prefer this tool over lyzr_get_a2a_agent_card or any conditions/exclusions. Usage guidance is only implicit via the word 'convenience' and the path note, so it is adequate but not explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_activity_metricsA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnly, openWorld, and idempotent hints. The description adds the default-to-today-UTC behavior and clarifies that it returns combined metrics, which is extra context beyond the annotations. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that conveys the action, resource, and default behavior without any redundant or filler words. Every part earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with rich annotations and complete schema coverage. The description adequately conveys the core purpose and default date behavior. The only gap is that no output schema exists and the return format is not explicitly described, but for a simple metrics query this is acceptable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema fully describes the single 'date' parameter with ISO 8601 format and default value, giving 100% coverage. The description only repeats the default behavior, adding no additional parameter-level meaning beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Get' with a specific resource 'combined DAU/MAU activity metrics' and a date specifier. It clearly distinguishes itself from sibling tools like lyzr_get_dau and lyzr_get_mau by emphasizing 'combined'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides useful context by stating the date defaults to today UTC, but gives no explicit guidance on when to use this tool versus alternatives such as get_dau or get_mau. The intended usage is implied rather than clearly stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_dau_trendA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, covering the safety profile. The description adds only 'trend' and 'last N days', which is consistent but does not disclose return format or edge cases (e.g., timezone). It neither contradicts nor substantially extends the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One concise, front-loaded sentence that immediately conveys the tool's essence. No filler or redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with one optional parameter, the description is nearly complete. Annotations handle safety, the schema handles parameter constraints, and the description defines the core behavior. Minor missing detail about the response shape is acceptable given no output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with a well-described 'days' parameter (min, max, default). The description's 'N days' merely restates the parameter without adding new semantic detail, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('daily active users trend') with a clear temporal scope ('over the last N days'). It distinguishes this tool from sibling metrics tools like get_dau (likely single-day) and get_mau_trend (monthly trend).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The context is clear: use this when you need a daily active users trend over a customizable number of days. However, it does not explicitly mention alternatives or when not to use it, so it lacks exclusions but provides sufficient implicit guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_featuresA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark this as read-only, open-world, and idempotent. The description adds the aggregation and caller-scoping context but doesn't detail return shape or error behavior, which is acceptable given annotation coverage.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Single sentence, 10 words, front-loaded, no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter read-only getter, the description adequately conveys the purpose and scope. It lacks a mention of return value shape, but the absence is mitigated by the simple nature and annotations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so schema coverage is trivially 100%. Per rubric, 0 params receive a baseline of 4; the description doesn't need to add parameter details.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Get' and identifies a distinctive resource ('aggregate feature-availability map') scoped to 'current caller,' distinguishing it from sibling tools like get_feature_flags and list_feature_flags_admin.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not explicitly state when to use this tool or mention alternatives. Usage is implied for a getter, but no context or exclusions are provided, so it falls short of clear guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_mauA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, covering safety profile. Description adds default month/timezone behavior and clarifies date interpretation, but does not describe return format or edge cases like invalid dates. This adds some value but not rich 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Single sentence, front-loaded with verb and resource, includes key default behavior. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only metric tool with good annotations and one optional documented parameter, the description covers purpose, default, and output (count). It lacks explicit return type but 'count' is sufficient. Could mention alternatives but not required.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description covers 100% of the single parameter with the same default and format info. Description does not add information beyond the schema, so baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description uses specific verb 'Get' with resource 'monthly active user count' and scope 'month containing a given date' with UTC default. Clearly distinguishes from sibling tools like lyzr_get_dau and lyzr_get_mau_trend by specifying MAU count rather than DAU or trend.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear context on when to use: to get MAU for a month, defaulting to current month UTC. Does not explicitly name alternatives or exclusions, but the intended usage is unambiguous given the description.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_mcp_server_agentsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds no further behavioral context (e.g., return shape, invalid server_id handling), but it does not contradict the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single sentence that is free of redundancy; every word contributes to the meaning, making it appropriately concise.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple, with one parameter and full schema coverage, and annotations cover safety. The description is adequate, though a note on the return format or edge cases would make it more complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with a single parameter described as 'MCP server id'. The description does not elaborate beyond the schema, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'List agents that use a given MCP server' — a specific verb (List) and resource (agents) scoped by MCP server. This distinguishes it from sibling tools like lyzr_list_mcp_servers or lyzr_list_agents.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The implied usage is clear: use this tool to discover which agents are associated with a particular MCP server. It does not explicitly mention alternatives or exclusions, but the context is unambiguous from the wording.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_git_get_file_contentA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds minimal context beyond that (reads from 'agent's git repo') but does not disclose additional behavioral traits like error handling or return format. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, concise sentence that captures the essential purpose without any fluff or redundancy. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with well-defined parameters and safety annotations, the description is adequate. It lacks explicit return format or branch behavior details, but these are either covered by the schema or not critical for basic usage. The lack of an output schema means some return context would help, but this is a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% and all three parameters have meaningful descriptions in the input schema. The tool description adds no extra parameter information, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('content of a file in an agent's git repo'), clearly distinguishing it from sibling tools like lyzr_git_list_repo_files (which lists file names) and lyzr_git_save_file_content (which writes content).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies when to use this tool (to retrieve file contents) without confusing it with other git operations. However, it does not explicitly mention alternatives or when not to use it, though the simple read-only nature makes this less critical.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kb_deleteA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark this as destructive and not read-only; the description adds the key detail that deletion is 'permanent', signaling irreversibility. This goes beyond the annotations and sets correct expectations, though it does not mention cascading effects 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One short sentence, 'Permanently delete a knowledge base by id.' Front-loaded with the verb, and every word contributes meaning without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter delete tool with strong annotations, the description covers the core action and irreversibility. It lacks details on return value or consequences, but output schema is absent and the operation is simple enough that this is a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with kb_id described as 'Knowledge base id'. The description's 'by id' adds no new semantics beyond the schema, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'delete' and names the resource 'knowledge base' with 'by id' scope. This clearly distinguishes the tool from siblings like lyzr_kb_bulk_delete, lyzr_kb_delete_docs, and lyzr_kb_reset.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for deleting a single knowledge base identified by kb_id, but it does not explicitly state when to use it versus alternatives such as bulk delete or document deletion. No exclusions or alternative tool references are provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_list_a2a_agentsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare the operation as read-only, idempotent, and non-destructive, which covers the safety profile. The description adds the 'all registered' scope but does not provide additional behavioral details such as response format, pagination, or ordering. This is acceptable given the strong annotation coverage, but the description contributes minimal extra 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that directly states the action and subject with no wasted words. It is highly concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple, parameterless list operation, the description is sufficient. It does not elaborate on return value structure, but no output schema exists and the tool is straightforward. A slight gap is the lack of differentiation from other list tools, but this is not critical for basic understanding.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, and the schema has 100% coverage since there are no properties. The description's 'all' implies no filtering, aligning with the empty parameter set. This matches the baseline expectation for a parameterless tool.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly specifies the action ('List') and the resource ('A2A agents'), and the phrase 'all registered' indicates the scope. It distinguishes itself from sibling tools like 'lyzr_list_agents' by explicitly targeting A2A agents.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance is given on when to use this tool versus alternatives like 'lyzr_list_agents' or 'lyzr_list_org_agents'. The A2A in the name implies a distinction, but the description does not articulate the appropriate context or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_list_user_asset_filtersA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is conveyed. The description adds useful context by enumerating example facets (providers, models, owners, tags), but it does not disclose return format, pagination, counts, or any other behavioral constraints beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that packs the essential information—listing filter facets for user assets—without any redundant words. Every word earns its place, and the parenthetical examples are useful without being verbose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple, read-only, zero-parameter tool, the description is mostly complete. It names the facet categories, but because there is no output schema, it could have been more explicit about whether the response includes values, counts, or just facet names. Still, the examples give a strong hint, and the overall context is sufficient for an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the schema carries no burden. The description doesn't need to add parameter details; the baseline for zero-parameter tools is 4, and the description adequately sets expectations for a no-input operation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description is specific: 'List the available filter facets (providers, models, owners, tags, etc.) for user assets.' It clearly identifies the verb (list), the resource (filter facets), and the target (user assets), and it implicitly distinguishes itself from sibling tools like lyzr_list_user_assets and lyzr_search_user_assets by focusing on facets rather than assets themselves.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage—it provides filter facets for user assets, presumably to support filtering or search—but it does not explicitly state when to use this tool versus alternatives, nor does it name any sibling tools. It lacks explicit exclusions or comparative guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_list_user_assetsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds the caller-scoping context but does not disclose additional behavioral traits such as response format, pagination defaults, or handling of shared assets. The schema descriptions for has_trigger/has_schedule reveal subtle exclusions, but that is in structured fields, not the description itself.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single sentence that is front-loaded with the core purpose ('List the caller's user assets'), immediately followed by the key capabilities. Zero wasted words; every phrase earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's read-only nature, excellent annotations, and fully described parameters, the description is almost sufficient. It lacks an explicit statement of the return shape (what fields appear in the list), but since no output schema exists and the resource type is well-known, this is a minor gap. The 'etc.' in the type list introduces slight ambiguity about what asset types are included.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all 16 parameters are already well-documented. The description's mention of 'filtering, sorting, and pagination' is a high-level summary that adds no extra meaning beyond the schema. Baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb ('List'), the resource ('the caller's user assets'), and explicitly includes asset types (agents, folders, workflows, etc.). It also distinguishes from sibling tools like lyzr_list_agents and lyzr_list_org_agents by scoping to the caller's own assets.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context about when to use the tool (listing the caller's own user assets), but does not explicitly mention alternatives or when-not-to-use cases. It implies usage through the 'caller's' scoping, which separates it from org-level or agent-specific list tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_livesource_removeA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds the behavioral trait 'permanently' beyond the annotations, confirming irreversible deletion. It also specifies the target context ('from a knowledge base'), which is useful. The annotations already provide destructiveHint and idempotentHint, so the description does not need to repeat those, but it does reinforce the destructive nature with 'permanently'. It does not mention any potential side effects like data loss, but that is largely covered by destructiveHint.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, straightforward sentence: 'Permanently remove a live source from a knowledge base.' It is front-loaded with the action and includes the essential qualifier 'permanently'. There is no redundancy or irrelevant detail, making it appropriately concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's low complexity (two required parameters of simple string type, no output schema, and strong annotations), the description is sufficiently complete. It covers the core action and scope. It does not explicitly state the effect on synced data or mention idempotency, but the annotations and schema fill in most remaining gaps. The description is adequate for an agent to select and invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully describes both parameters—rag_id as 'Knowledge base id' and live_source_id as 'Live source id'—with 100% coverage. The description does not add any additional semantics or context about the parameters, so it provides no value beyond the schema. This matches the baseline of 3 for full schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Permanently remove a live source from a knowledge base.' The verb 'remove' is specific, the resource ('live source from a knowledge base') is defined, and the word 'permanently' distinguishes this from pause/resume operations. It clearly differentiates from siblings like lyzr_livesource_pause, lyzr_livesource_resume, and lyzr_livesource_get.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for permanent removal but does not explicitly state when to use this over alternatives. It does not mention that pause is preferred for temporary disabling or that this is irreversible. The destructiveHint annotation provides some context, but the description itself gives no explicit 'when not to use' guidance, leaving the agent to infer from the name and sibling tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_livesource_repointA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses that existing webhook subscriptions are re-created, which is meaningful behavioral context beyond the annotations. The annotations already indicate a mutating, non-idempotent, open-world operation, but the description adds the specific side effect of webhook re-creation. There is no contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is exceptionally concise: two short sentences. The main action is front-loaded, and the side effect is stated in the second sentence with zero redundancy. It earns its place entirely.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a mutation tool with annotations and full schema coverage, the description is reasonably complete. It covers the core purpose and the key side effect. It does not mention return values or prerequisites, but these are partially covered by the absence of an output schema and the simplicity of the operation. Overall, it provides sufficient context for an agent to use the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and the parameter descriptions (e.g., 'ACI credential_id (UUID) to repoint to') are clear. The tool description does not add additional semantic meaning beyond the schema, so a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Repoint a live source to a new credential.' It uses a specific verb ('repoint') and resource ('live source'), and the added detail about re-creating webhook subscriptions distinguishes it from siblings like add, remove, pause, or resume. This provides clear purpose and differentiation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the usage scenario (changing the credential of a live source) but does not explicitly state when to use this tool versus alternatives, nor provide exclusions or mention sibling tools. The purpose is clear, but there is no direct guidance on when not to use it or what to do instead (e.g., recreating a live source).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_livesource_resumeA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint=false and idempotentHint=true, so the agent knows this is a safe write operation. The description adds the 'paused' precondition, but doesn't disclose potential side effects 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence with no wasted words, making it highly efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter resume operation with good annotation coverage, the description is adequately complete. It could mention that the live source must exist, but is otherwise sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and both parameters (rag_id, live_source_id) have clear descriptions. The tool description adds no additional parameter meaning beyond what the schema provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (resume syncing) and the target (a paused live source). This distinguishes it from sibling live source tools like pause, add, and sync.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: use this tool for a paused live source. It does not explicitly mention alternatives or exclusions, but the primary usage scenario is evident.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_log_auth_eventA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows this is a write operation with no destructive side effects. The description adds that it goes into the audit log and is frontend-originated, which is useful context. However, it does not disclose potential authorization requirements, rate limits, or what happens if duplicates are logged. With annotations lowering the burden, a 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficiently worded sentence that immediately communicates the tool's core function. It contains no filler or redundancy, earning full marks for conciseness.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with only 3 parameters (one required), full schema descriptions, and clear annotations, the description sufficiently covers the primary context: purpose and origin. It lacks an explicit note about the return value or error behavior, and with no output schema, that omission is slightly noticeable. Nevertheless, the overall context is adequate for a simple logging action, so it remains above the minimum viable threshold.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, as each parameter (event_type, user_email, metadata) already has a clear description. The tool description adds minimal additional meaning beyond 'login or logout' and 'audit log,' which slightly reinforces event_type but does not elaborate on metadata structure or formatting. Baseline for full schema coverage is 3, and the description does not elevate it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Log'), the resource ('a login or logout event'), and the destination ('into the audit log'). It directly matches the title and name, leaving no ambiguity about the tool's purpose. It also naturally distinguishes itself from sibling audit-list tools which retrieve logs rather than create them.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'from the frontend' provides contextual guidance, indicating this tool is intended for client-side auth event logging. While it does not explicitly mention alternatives or when not to use it, the sibling tools are predominantly read-only audit log queries, making it clear this is the write counterpart. No formal exclusion criteria are given, so it stops short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_memprovider_validate_aws_agentcoreA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With annotations already declaring readOnlyHint, openWorldHint, and idempotentHint, the description adds value by revealing the secondary behavior of listing associated memories, which is not obvious from the tool name alone. It does not contradict the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no redundant words. It efficiently communicates both the primary action and the secondary behavior.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter tool with strong annotations and no output schema, the description is largely sufficient. It could mention the validation result format, but the phrase 'list associated memories' suggests the output nature. Minor gap in not describing return semantics of the validation itself.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema fully describes the single parameter (credential_id) with 100% coverage, and the description adds no additional parameter semantics beyond what the schema already provides. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Validate') with a clear resource ('AWS AgentCore credentials') and adds a second action ('list associated memories'). This distinguishes it from sibling tools like lyzr_memprovider_aws_agentcore_status and lyzr_memprovider_list_aws_agentcore_resources.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for validating AWS AgentCore credentials and listing associated memories, but it does not explicitly state when to use this tool over alternatives, nor does it mention any exclusions or prerequisites. The context is clear but not fully articulated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_refresh_credit_cacheA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate the tool is not read-only (readOnlyHint=false). The description adds the 'server-side' and 'force' aspects, but does not disclose side effects such as whether the cache is cleared, recomputed, or if there are rate limits. It provides minimal value beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, concise sentence that fully communicates the purpose without any redundancy. It is properly front-loaded and easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simplicity of the tool (one optional parameter, no output schema) and the annotations, the description is almost complete. It would benefit from a note on when a refresh is appropriate, but the current text is sufficient for most agents.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% (the only parameter, x_server_token, is described as 'Optional server-to-server auth token'). The description adds no additional parameter context, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Force a refresh of the server-side credit-cost cache.' This uses a specific verb ('refresh') and a specific resource ('server-side credit-cost cache'), making the tool's purpose unambiguous and distinguishing it from read-only siblings like lyzr_get_cached_credits.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the usage context: use this tool when you need to force a refresh of the credit-cost cache. It does not explicitly state when not to use it or mention alternatives, but the context is clear enough for a low-complexity utility.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_report_listA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating a safe, read-only operation. The description adds the resource and filter options but does not mention return format, pagination behavior, or any other contextual details like rate limits. Consistent with annotations, but the added value beyond them is minimal.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that immediately states the action and resource, followed by optional filters. Every word earns its place; no fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with robust annotations and fully described parameters, the description is nearly complete. It clearly states the purpose and the key filtering options. It could optionally clarify that it returns a list of jobs, but the tool name and verb already imply this. Given no output schema, the description is sufficient for an agent to select and invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter (skip, limit, status, report_type) described in the input schema. The description's mention of 'filtered by type or status' adds nothing beyond what the schema already provides. Baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists report jobs and supports optional filtering by type or status. It uses a specific verb ('list') and resource ('report jobs'), effectively distinguishing it from sibling tools that generate or fetch individual reports like lyzr_report_usage_by_agent or lyzr_report_get_status.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: this is for listing report jobs with optional filters. It does not explicitly discuss when to use this tool over alternatives, but the scope is unambiguous given the listing purpose and the sibling 'get_status' tool. No exclusions are stated, but the implied usage is straightforward.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_search_user_assetsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations (readOnlyHint, idempotentHint, destructiveHint false) already disclose safety traits. The description adds the ownership scope ('caller's user assets') and points to shared behavior with listing, but doesn't detail specifics like default ordering or whether search is case-insensitive. This is acceptable given strong annotation coverage, though the added behavioral context is moderate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, front-loaded sentence with no waste. It states the core action and references the listing tool to avoid repeating parameter details. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the 17-parameter schema with full coverage, the description doesn't need to enumerate options; referencing 'listing' is sufficient. It clearly scopes to 'caller's user assets' and includes read-only annotations. It could be more complete by naming the listing sibling tool explicitly, but the reference is clear. No output schema is present, but it's a search/list operation where return shape is presumably obvious given the schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All 17 parameters have schema descriptions, so the baseline is 3. The description adds no new param-specific semantics beyond saying the options are the same as listing, which simply reinforces that the schema already document them. It doesn't explain any parameter values or relationships beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('Search') and resource ('the caller's user assets'), and clarifies it's query-based. It distinguishes itself from the sibling lyzr_list_user_assets by referencing 'same filtering, sorting, and pagination options as listing', making it a distinct search variant.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use it: when searching assets by query string, with filtering/sorting/pagination. It references 'listing' as an alternative, providing clear context, though it doesn't explicitly state 'use this instead of listing when you have a query'. Exclusions are not mentioned but the comparison to listing gives sufficient guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_semantic_model_connect_databaseA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), so the bar for additional behavioral disclosure is lower. The description adds minimal behavioral context beyond the connection action—it does not mention effects like whether an existing connection is overwritten or if the operation can be undone. However, given the low complexity, this is adequate but not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence (12 words) that front-loads the action verb and resource. Every word contributes value, and there is no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with two well-documented parameters, no output schema, and existing annotations, the description is nearly complete. It states the exact operation and its purpose. A minor gap is that it does not mention any prerequisites (e.g., that both IDs must reference existing entities), but the low complexity and schema coverage make this a minor omission.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with both parameters ('database_id' and 'rag_config_id') having clear descriptions in the schema. The description does not add significant extra meaning beyond the schema, but it reinforces the purpose by linking the two parameters to the connection action. Baseline 3 is appropriate when the schema carries the parameter semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Connect') with a clear object ('a database to a RAG config') and states the purpose ('for semantic-model table documentation'). It clearly distinguishes this from sibling tools like lyzr_semantic_model_list_tables or lyzr_semantic_model_save_documentation by focusing on the connection 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/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use the tool by stating its purpose, which is to enable semantic-model table documentation. It does not explicitly mention alternatives or exclusions, but the context is clear that this is the prerequisite step before documentation-related operations. Sibling tools with names like 'list_tables' and 'save_documentation' reinforce this implicit usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_semantic_model_list_documentation_agentsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, covering safety semantics. The description adds no further behavioral context, such as return format, pagination, or what fields are included in the list, so it does not enhance beyond annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no extraneous information. Every word contributes meaning, making it highly concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple (zero parameters) and annotations provide a clear safety profile. However, without an output schema, the description does not specify what the returned list contains or its structure. For a simple list tool, this is adequate but not fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the baseline is 4. The description does not need to explain parameters, and the empty schema combined with the description suffices for correct invocation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'List semantic-model documentation agents' uses a specific verb (list) and resource (semantic-model documentation agents), clearly distinguishing it from generic agent listing tools like lyzr_list_agents. The qualifier 'semantic-model' differentiates it from other list operations in the sibling set.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no explicit guidance on when to use this tool versus alternatives (e.g., lyzr_list_agents or lyzr_kb_list_documents). Usage is implied by the tool name and zero-parameter nature, but no context or exclusions are stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_semantic_model_list_tablesA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds the scoping detail ('connected database', 'RAG config'), which implies prerequisites, but doesn't mention return format or behavior when the database isn't connected.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no redundant words. It states the action, object, and context efficiently.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple listing operation with only two parameters and strong annotations, the description covers purpose and context well. It does not specify the return format, but that is likely obvious (list of table names), and the existence of lyzr_semantic_model_connect_database as a sibling implies a prerequisite that could be explicitly stated but is inferable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage with descriptions for both parameters ('Database id', 'RAG config id'). The description doesn't add extra meaning beyond restating these parameters, so we rely on the schema's baseline. The wording 'connected database for a RAG config' loosely maps to the parameters but doesn't elaborate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and resource ('table names'), and scopes it to 'a connected database for a RAG config'. It clearly differentiates from sibling tools like lyzr_semantic_model_table_preview (data preview) and lyzr_semantic_model_list_documentation_agents.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use: when you need table names for a connected database used in a RAG config. It provides clear context but doesn't explicitly mention alternatives or exclusions. No other list-table sibling exists, so no alternative is needed.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_session3_deleteA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description adds the word 'permanently', which conveys irreversibility beyond the annotation's raw destructive flag. It also clarifies the deletion is by id, which is useful context. However, it does not mention potential cascading effects on related data (e.g., messages, branches), which would have enriched the behavioral picture.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that is front-loaded with the verb 'delete' and resource. Every word contributes to meaning, with no filler or repetition. Ideal length for a one-parameter destructive operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete tool with strong annotations (destructive, idempotent, readOnly=false), the description is adequately complete. It conveys the core action and the resource. It does not explicitly address what happens if the session doesn't exist or whether related data is removed, but the idempotentHint partially covers idempotency, and the absence of an output schema makes return-value documentation unnecessary. Minor gaps around cascading effects keep this from a 5.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides 100% coverage for the single parameter, describing session_id as 'Session id to delete'. The tool description adds 'v3 session by id', but this reuses information already present in the tool name/title and does not provide new semantic details about the parameter (e.g., format, how to obtain a valid v3 session id). Baseline of 3 is appropriate since schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Permanently delete a v3 session by id' clearly identifies a specific action (delete), the resource (v3 session), and the key (by id). It distinguishes itself from the sibling lyzr_session_delete by explicitly noting 'v3', and the title reinforces this. This is a precise, unambiguous statement of purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage through the phrase 'by id' and 'v3 session', but does not explicitly state when this tool should be chosen over alternatives like lyzr_session_delete or lyzr_session_update. It provides no contextual conditions, prerequisites, or exclusions. Since the v3 scoping is in the name/title, the description adds little beyond what is already structured.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_sharing_check_accessA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, establishing the safe, non-mutating nature. The description adds context about 'via their org' and 'required access level', which is useful. But it does not disclose return format or behavior on insufficient access. With annotations carrying the safety burden, a score of 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, well-structured sentence that is front-loaded with the action ('Check') and clearly communicates scope. No filler or repetitive information. It earns a 5.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is low complexity with 5 parameters and no output schema. The description explains what the tool checks and the org-based logic, and annotations cover read-only/idempotent behavior. Missing is an explicit statement of the return type (e.g., boolean), but for a simple check tool this is a minor gap. Slightly above minimum viable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage for all 5 parameters, including detailed descriptions and an enum for required_access. The description adds a little context by explaining the org-based check, but it does not need to compensate for schema gaps. Baseline 3 is appropriate when the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Check whether a user (via their org) has the required access level to a resource' states a specific verb ('check') and resource (access level to a resource). It distinguishes itself from siblings like lyzr_sharing_list_accessible (which lists accessible resources) and lyzr_sharing_reconcile_indexes (index maintenance) by clearly focusing on a single access-check operation for a given user, org, and resource.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly conveys use case: verifying a user's access level to a specific resource. It implies the check is done through the user's org. However, it does not explicitly name alternatives (e.g., lyzr_sharing_list_accessible) or state when not to use this tool. Since it gives clear context without exclusions, it earns a 4.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_sharing_create_groupA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate this is a mutating, non-idempotent operation with potential open-world effects. The description adds that the group is rooted at a resource and controls access, which clarifies intent but does not disclose additional behavioral traits such as required permissions, failure modes, or side effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that is front-loaded with the action and resource, containing no unnecessary words or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a create operation with a complete parameter schema and no output schema, the description sufficiently captures the core action and purpose. It could be more detailed about the group's relationship to agents/superflows or default access levels, but these are covered in the schema; overall it is complete enough for an agent to select and invoke the tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so parameters are already well-documented. The description adds minimal parameter-level meaning ('rooted at a resource' hints at root_resource_id/type) but does not elaborate beyond the schema, so a baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Create') and the resource ('a sharing group'), and adds specificity with 'rooted at a resource' and 'controlling who can access it.' This distinguishes it from sibling tools like update_group, delete_group, and share_group.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use the tool (to establish a new access-control group) and clarifies the group's root. However, it does not explicitly mention alternatives or exclusions, though the context is clear enough among the sharing siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_sharing_delete_groupA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and readOnlyHint=false, so the description's 'Permanently delete' reinforces and adds irreversibility nuance. However, it does not disclose side effects such as what happens to associated resources, permissions, or error behavior. The description adds some value beyond annotations but is not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence ('Permanently delete a sharing group by id.') that is front-loaded with the action and contains zero waste. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete tool with one parameter, no output schema, and annotations covering destructive/idempotent behavior, the description is sufficient. It fully conveys the operation. It could optionally mention how to obtain the group_id (e.g., via list_groups) but this is not essential for such a straightforward tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with the parameter group_id described as 'Sharing group id'. The description's 'by id' adds no new meaning beyond the schema. Baseline 3 is appropriate since the schema fully documents the parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Permanently delete a sharing group by id.' The verb 'delete' and resource 'sharing group' are specific, and the tool is distinct from sibling tools like lyzr_sharing_create_group, lyzr_sharing_update_group, and lyzr_sharing_list_groups. It fully clarifies what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Although no explicit alternatives are named, the description implies clear usage: use when you need to permanently remove a sharing group. The tool name and sibling context make the purpose obvious, providing clear context without exclusions. Not a 5 because it lacks an explicit 'use X instead' statement.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_sharing_list_accessibleA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, which cover the safety profile. The description adds the 'via their org' scoping nuance but does not disclose additional behavioral details such as pagination, result format, or what 'accessible' includes. No contradiction 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, immediately informative sentence. It front-loads the verb and object, avoids filler, and contains no unnecessary wording.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple three-parameter read-only list operation with strong annotations, the description is complete enough. It clearly communicates the operation's scope, though it does not spell out return-value structure or pagination, which are not critical for this basic list action.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for all three parameters, each with a clear one-line description. The tool description does not add parameter-specific meaning beyond 'given type', which is already implied by the schema. Thus it neither helps nor hurts beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the action ('List') and the specific resource scope ('resources of a given type ... shared access to'), with the added context that access is via the user's org. This distinguishes it from generic listing tools and sibling sharing tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use this tool: to list resources of a given type that a user has shared access to via their org. It does not explicitly mention alternative tools or when-not-to-use scenarios, but the stated scope is unambiguous.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_simple_chat_completionsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate the operation is not read-only, non-idempotent, and non-destructive. The description adds the key behavioral trait that this is 'OpenAI-compatible', which hints at the expected request/response format, and notes the lack of an agent. It does not disclose details like rate limits, authentication requirements, or streaming behavior, but with annotations present, the description provides adequate supplementary 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence that conveys the essential purpose and key distinguishing feature. It is front-loaded with the core action ('OpenAI-compatible chat/completions endpoint') and adds only the critical clarification about not requiring an agent. No redundant or filler text.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's moderate complexity (7 parameters) and the absence of an output schema, the description does enough to guide invocation by establishing the OpenAI-compatible interface and the no-agent differentiation. The schema comprehensively documents all parameters. It could be more complete by mentioning how this relates to other chat/completions variants (v4, agent-based), but the current description is sufficient for selecting and invoking this tool in most cases.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with all 7 parameters having clear descriptions such as 'The model name', 'Optional session id', and 'Sampling temperature'. The tool description adds no additional parameter-level meaning, so the baseline of 3 applies. The description's focus on 'model/provider' does echo the model and provider_id parameters, but not beyond what the schema already states.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies this as an OpenAI-compatible chat/completions endpoint with a specific verb/action ('chat/completions') and the resource (model/provider). It explicitly distinguishes itself from siblings by noting it operates 'without a pre-created agent', which is a specific and useful differentiator against the many agent-based chat tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description states when to use this tool: when you want to select the model/provider directly without needing a pre-created agent. This implies a clear usage context and contrasts with agent-based alternatives. However, it does not explicitly enumerate when NOT to use it or mention alternative tools like lyzr_agent_chat_completions, so it stops short of a full 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_start_taskA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare non-read-only, non-idempotent, and non-destructive behavior. The description adds the crucial async nature and the return of a task_id for polling, but does not mention side effects beyond task submission, error behavior, or execution guarantees. This is adequate but not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences, no fluff. It front-loads the action and result in a compact, scannable format.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity and full schema coverage, the description provides enough to understand the core flow: submit a task, get an ID, poll for status. It lacks detail on failure modes or timeouts, but for a straightforward async submission tool, it is largely complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers all parameters with descriptions, so the baseline is 3. The tool description adds no additional parameter semantics beyond what the schema provides; it only explains the overall flow.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Submit'), the resource ('a long-running task to a Lyzr agent'), and the key output ('Returns a task_id to poll with lyzr_get_task_status'). This distinguishes it from synchronous chat tools like lyzr_chat and the subsequent polling tool lyzr_get_task_status.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description indicates this is for long-running tasks and that status must be polled, giving clear context for when to use it. It does not explicitly state when not to use it or name alternative tools, but the contrast with polling is implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_stream_chatA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate non-readonly behavior. The description adds that the call streams progress and returns the full response, which is useful. However, it doesn't disclose potential side effects such as conversation persistence or external calls, which the openWorldHint hints at.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences with no redundancy; the key facts are front-loaded. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple and the schema fully documents parameters. The description covers purpose, streaming behavior, and return. It lacks an explicit return format or edge-case guidance, but given no output schema, it provides enough for an agent to understand the tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers all 4 parameters with descriptions, so the description adds no additional parameter semantics. Baseline 3 is appropriate given the 100% schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies a specific verb ('Send'), an object ('a Lyzr agent'), and a distinguishing channel ('streaming endpoint'). It also notes the behavior of streaming progress and returning the full response, which differentiates it from the sibling 'lyzr_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/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It clearly implies the streaming use case as opposed to non-streaming alternatives, but does not explicitly contrast with 'lyzr_chat' or 'lyzr_start_task'. The context is understandable, yet exclusions and alternatives aren't explicitly stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_update_artifactA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already convey safety profile (not read-only, not destructive, idempotent). The description adds the scoping constraint (user/session) but doesn't disclose behavioral details such as whether fields are fully replaced or merged, beyond what the schema already states. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, front-loaded sentence that efficiently states the operation and scope. No fluff, every word contributes to understanding the tool's purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given 8 optional fields, 3 required params, and no output schema, the description provides enough context for an update operation: it identifies the entity, the action, and the scope. It doesn't mention return values, but the schema and annotations fill in most gaps. Slightly more detail about merging/overriding semantics could improve it.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the description doesn't need to add parameter meaning. The description's mention of 'fields' is generic; all parameter details are already in the schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Update') and resource ('fields on an existing artifact'), clearly distinguishing it from create/get/delete/list siblings. Adding 'scoped to a user and session' further clarifies the intended operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'existing artifact' implies it should be used when the artifact already exists and needs modification, not for creation or retrieval. It provides clear context but does not explicitly name exclusions or alternatives like 'use create_artifact for new artifacts'.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_world_model_dashboard_overviewA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true. The description's 'Fetch' is consistent with these hints. It adds minimal behavioral context (the aggregation scope) but does not describe what fields the summary contains or any possible limitations. With annotations covering the safety profile, this is adequate but not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that front-loads the verb and quickly states the resource and scope. No unnecessary words or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple, zero-parameter read-only aggregate fetch, the description provides the core information needed: it returns an overall dashboard summary across all world models. It does not specify the exact structure of the summary, but given the tool's simplicity and the annotations, the description is sufficiently complete, though it could benefit from noting what metrics are included.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the empty input schema fully covers the parameter surface. The baseline for 0 parameters is 4. The description correctly implies no inputs are needed, and there is no parameter information to add.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Fetch' and clearly identifies the resource as the 'overall World Model dashboard summary across all world models'. This distinguishes it from the sibling tool 'lyzr_world_model_dashboard_by_world_model', which likely returns a per-world-model dashboard. The scope is explicit.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'across all world models' implies this is for aggregate data, and the existence of a per-world-model sibling suggests an alternative, but the description does not explicitly state when to use this tool over that one or provide exclusions. Guidance is implied rather than directly stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_world_model_list_by_agentA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety and side-effect expectations. The description adds the relationship 'built from a given source agent,' which is useful but largely mirrors the schema parameter description. It does not contradict annotations and provides minimal additional 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single focused sentence that communicates the core operation and the key filtering condition. It is concise, with no redundant phrases, and front-loads the verb and resource.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list operation with one parameter and clear annotations, the description is nearly complete. It does not explain what a 'world model' is or what the return shape looks like, but given the lack of an output schema and the simplicity of the operation, the description is adequate for an agent to select and invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% (the sole parameter agent_id has a description: 'The source agent id'). The description's phrase 'built from a given source agent' aligns with the schema but adds no new parameter information. Baseline 3 is appropriate when the schema fully documents parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') with a clear resource ('world models') and a scoping qualifier ('built from a given source agent'). This distinguishes it from sibling tools like lyzr_world_model_create, lyzr_world_model_get, and lyzr_world_model_list_scenarios, clearly indicating a filtered read operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: it lists world models associated with a specific source agent, so an agent knows when to invoke it. However, it does not explicitly mention exclusions or alternatives (e.g., lyzr_world_model_get for a single model, or dashboard overview), which keeps it from a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_delete_a2a_agentA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description emphasizes 'Permanently delete,' which adds irreversibility context beyond the destructiveHint annotation. It also clarifies deletion is by ID, but does not discuss permissions or side effects. Annotations already cover destructive/read-only nature, so the added 'permanent' context is a meaningful bonus.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence with no filler. It front-loads the action ('Permanently delete'), includes the specific resource ('A2A agent record'), and the parameter identifier ('by id'). Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple single-parameter delete operation, the description is complete. It conveys the action, target, and identifier method. Annotations cover destructiveness and idempotence, and no output schema is expected for a delete operation. No significant gaps remain.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage for the single parameter agent_id, which is self-explanatory ('The A2A agent id to delete'). The description's 'by id' repeats the schema, adding no new semantic detail. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states a specific verb ('delete'), a specific resource ('A2A agent record'), and the method ('by id'). It distinguishes itself from sibling delete tools by specifying 'A2A agent' rather than generic agents.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for deleting a single A2A agent by ID, but does not explicitly state when to choose this over alternatives like lyzr_delete_agent or lyzr_bulk_delete_agents. No exclusions or alternative guidance is provided, so usage context is only implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_delete_lyzr_aci_toolA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations (destructiveHint=true, readOnlyHint=false, idempotentHint=true) already declare the operation's destructive and non-idempotent nature. The description adds the crucial detail 'permanently,' which clarifies that deletion is irreversible—context beyond the annotations. It does not contradict the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, well-structured sentence with a clear verb, resource, qualifier, and parameter reference. No redundant words; it is maximally concise while retaining essential information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete operation with one fully documented parameter, the description provides all necessary context: it states the action, the target resource, the permanence, and the identifier. Annotations cover the destructive and idempotent behavior. No output schema exists, so return behavior is not required.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema description covers 100% of the parameter ('The provider id to delete'). The tool description repeats this with 'by provider id,' providing minimal additional meaning. Since schema coverage is complete, the baseline of 3 is appropriate; the description adds no significant new parameter insight.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('delete') and resource ('Lyzr ACI tool') with an important qualifier ('permanently') and the identifier ('by provider id'). It clearly distinguishes this from sibling tools like lyzr_delete_aci_connection or lyzr_delete_aci_configuration by naming the exact resource type.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage by stating the resource and identifier, but it does not explicitly mention when to use this tool instead of alternatives, nor any exclusions. For example, it doesn't clarify that this is for Lyzr ACI tools specifically versus other delete operations, though the name and resource type provide some context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_agentA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) already convey that this is a safe, non-destructive read operation. The description adds minimal behavioral context beyond the schema, but doesn't disclose return format or error behavior. This is acceptable given the strong annotation coverage, but not exceptional.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, compact sentence that fits the essential information: action, resource, and required parameter. No wasted words or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple get-by-id tool with a single required parameter, strong read-only annotations, and complete schema coverage. The description is sufficient for an agent to select and invoke it correctly. Return details are not specified, but no output schema exists and the complexity is low, so the description meets the bar.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 100% coverage; agent_id is described as 'The agent_id to fetch'. The description adds no extra meaning beyond the schema, so a baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Fetch'), the resource ('details of a single Lyzr agent'), and the key parameter ('by its agent_id'). The word 'single' differentiates it from lyzr_list_agents, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the use case: you must already have an agent_id to fetch a specific agent. It doesn't explicitly state when not to use it or mention alternatives like list_agents, but the context is clear enough for an agent to decide.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_agent_stale_connectionsA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds the interpretation that 'stale' means needs reauthorization, which is helpful context. It does not disclose return format or pagination, but the safety profile is covered by annotations, so a moderate score is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence with no wasted words. It front-loads the key action and resource and immediately clarifies the meaning of 'stale'.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with two fully described parameters and comprehensive annotations, the description is sufficient. It clearly identifies the tool's purpose and parameter scope, matching the completeness of high-quality filtered list tools.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptions for both user_id and agent_id. The description does not add additional parameter-level details beyond what is in the schema, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and clearly identifies the resource as 'an agent's stale tool connections', and clarifies that 'stale' means connections needing reauthorization. This distinguishes it from sibling tools like get_agent or credential list tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies when to use this tool: when you need to identify an agent's connections that require reauthorization. However, it does not explicitly mention alternatives or when not to use it, such as referencing get_agent for general agent info or credential tools for all connections.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_list_feature_flags_adminA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. The description adds minimal context by stating the output includes 'gating configuration' but does not disclose other behaviors like required admin permissions or pagination. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence with no filler. It front-loads the verb 'List' and immediately specifies the resource and what is included, making it optimally concise.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter list tool with strong annotations, the description adequately explains the purpose and what the output contains ('all feature flags with their gating configuration'). Without an output schema, this is sufficient for an agent to understand the return value expectation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has zero parameters, so schema coverage is 100% and no parameter documentation is needed. The baseline for zero-parameter tools is 4, and the description does not need to add anything.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'List' with a clear resource ('feature flags') and adds relevant detail ('gating configuration'). This distinguishes it from sibling 'get' tools and conveys the scope of the operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for listing all feature flags but does not explicitly mention alternatives such as lyzr_get_feature_flag_admin or lyzr_get_feature_flags, nor does it provide when/when-not guidance. It relies on the tool name 'admin' to differentiate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_list_mcp_serversA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe read nature is known. The description adds 'registered for the account' as contextual scope but does not disclose other behavioral traits such as pagination or return format. It provides marginal value beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler. Every word earns its place, conveying action, resource, and scope efficiently.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only list tool with strong annotations, the description is complete: it states what is listed and the scope. No output schema exists, but the tool's simplicity and the name itself make the return value self-evident.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0 parameters and 100% schema coverage, there is nothing for the description to clarify about parameters. The baseline for zero parameters is 4, and the description's 'registered for the account' confirms no filters are needed, which is adequately meaningful.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'List' with the resource 'MCP servers' and the scope 'registered for the account.' It clearly distinguishes from sibling tools like list_mcp_server_tools and list_mcp_server_resources, which target different resource types.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: when you need to enumerate MCP servers for the account. However, it does not explicitly mention when not to use it or name alternative tools, unlike the high-caliber example that references a search alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_rai_list_policiesA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and idempotentHint=true, which cover the safety and side-effect profile. The description adds the contextual scope 'your', indicating a user-scoped list, but does not add further behavioral details such as pagination or return format. With annotations present, this is a reasonable baseline.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler. Every word adds meaning: 'List', 'your', 'Responsible-AI guardrail policies'.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a no-parameter, listing tool with strong annotations, the description is fully complete. It states the exact operation and subject, and there is no hidden complexity requiring additional context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema is empty with zero parameters, so the description does not need to explain parameter semantics. Per the rubric, a tool with 0 parameters receives a baseline of 4. The description correctly indicates no parameters are required.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and a specific resource ('Responsible-AI guardrail policies'), clearly distinguishing this tool from sibling tools like lyzr_rai_create_policy, lyzr_rai_delete_policy, and lyzr_rai_get_policy. It leaves no ambiguity about what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage — list when you want to see your responsible-AI policies — but does not explicitly state when to use it versus alternatives like lyzr_rai_get_policy for a single policy. There are no exclusions or alternative recommendations, so it is adequate but not explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_bulk_delete_workflowsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds the critical nuance 'permanently', clarifying the irreversibility of the action—valuable context beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, front-loaded sentence: 'Permanently delete multiple workflows by id.' Every word contributes, with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete tool with strong annotations and a 1-parameter schema, the description is sufficient. It omits return-value details, but that is not critical given the tool's simplicity and the absence of an output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the property description 'Workflow ids to delete' already explains flow_ids. The main description's 'by id' adds no new meaning beyond the schema, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('delete'), resource ('workflows'), scope ('multiple'), and method ('by id'). It distinguishes itself from the single-delete sibling 'lyzr_delete_workflow' by emphasizing 'multiple'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'multiple workflows by id' implies batch deletion, giving clear context for when to use it. However, it does not explicitly mention the alternative for single deletion (lyzr_delete_workflow), so it stops short of full when/when-not guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_delete_artifactA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already disclose destructiveHint=true and readOnlyHint=false. The description adds 'permanently' to emphasize irreversibility and 'scoped to a user and session' to highlight required context, providing value beyond the annotations. It does not mention error outcomes, but the annotation coverage makes this acceptable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that front-loads the action ('Permanently delete') followed by the resource and scope. It contains zero filler words and is appropriately concise for the tool's simplicity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple delete operation with three well-documented parameters and no output schema. The description, combined with annotations, covers the essential aspects: permanence, scoping, and destructive nature. It could mention return values or not-found behavior, but these are not critical for a delete tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3. The description adds minimal detail beyond the schema, only reinforcing that deletion is by id and scoped to user/session. It does not introduce any new parameter-specific semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'permanently delete' and identifies the resource as 'an artifact by id', which clearly distinguishes it from sibling tools like get, update, or list artifacts. It also adds scoping to a user and session, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use this tool: whenever an artifact must be permanently removed. It does not explicitly name alternatives or exclusions, but the delete operation is self-evident and the scoping to user/session clarifies applicability.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_artifactA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the scoping constraint but does not describe return format, error behavior, or pagination. This is similar to baseline levels where annotations carry most of the transparency burden.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence, front-loaded with the action and resource, and contains no filler. Every word adds value, making it appropriately concise.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple get operation with good annotations and a complete schema, the description is sufficient. It identifies the resource, scope, and that it returns a single artifact. It does not detail return format, but that is typically self-evident for a fetch tool and is not required given the simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with per-parameter descriptions like 'Artifact id' and 'User id'. The description adds meaning by stating 'scoped to a user and session', clarifying that user_id and session_id are scope constraints and artifact_id is the identifier. This relationship is not explicit in the schema alone.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Fetch' with a clear resource ('a single artifact by id') and explicit scoping ('scoped to a user and session'). This distinguishes it from siblings like list_artifacts or update_artifact, which have different purposes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies when to use this tool: when you need one artifact by ID, and you know the user and session context. It does not explicitly name alternatives or exclusions, but the scope is clear enough for a single-get tool. The context of user/session filtering is provided, which is valuable for selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_chat_task_statusA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description's safety burden is lower. It adds the context that this is a polling operation and that it returns both status and result, but it doesn't elaborate on response specifics or edge cases. No contradictions with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single concise sentence that front-loads the action and states the companion tool. No filler or redundant repetition of schema information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple polling tool with one parameter and no output schema, the description covers the essential workflow (submit then poll) and the purpose. It doesn't detail the response format, but the title and description together provide sufficient context for correct usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema describes task_id only as 'The chat task id', but the description adds valuable provenance by specifying that the task was submitted via lyzr_submit_chat_task. This helps the agent correctly source the id, exceeding what the schema alone provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Poll') and the specific resource ('status/result of a chat task'), explicitly linking it to the companion tool lyzr_submit_chat_task. This distinguishes it from other status tools like lyzr_get_task_status.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description specifies when to use this tool: after submitting a chat task via lyzr_submit_chat_task. It doesn't explicitly mention alternatives or exclusions, but the context is clear enough for an agent to understand the intended workflow.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_feature_flagsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, and the description aligns with these. It adds context that flags are 'resolved', meaning effective values after evaluation, not raw definitions, which is useful behavioral information beyond what annotations provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence with no redundant words. It immediately communicates the core function and scope, making it easy for an agent to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (no parameters, no output schema), the description is mostly adequate. However, it does not explain the return format or value types (e.g., a map of flag names to booleans), which would be helpful since no output schema exists. Still, the purpose is reasonably clear.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, and the schema coverage is 100% (empty). The description effectively conveys that no additional inputs are needed, and the 'current caller' is implicitly derived from the execution context. This meets the baseline for no-parameter tools.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does 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 'resolved feature flags applicable to the current caller'. This distinguishes it from admin-oriented siblings like lyzr_list_feature_flags_admin and lyzr_get_feature_flag_admin, making the tool's purpose 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/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'applicable to the current caller' implicitly suggests this is for runtime flag resolution, but there is no explicit guidance on when to use this versus the admin flag tools or other related tools. It implies usage context but lacks explicit alternatives or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_task_statusA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing the safe, read-only nature. The description adds value by explaining that the tool returns both status and result when complete, which is not captured in annotations. No contradictions with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that directly states the purpose without any fluff. Every word adds value, and it is appropriately concise for the simplicity of the tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (one parameter, strong annotations, no output schema), the description is fairly complete. It clarifies the return semantics (status and result) and implies the polling use case. Could be slightly more explicit about the fact that result is only present on completion, but the parenthetical 'when complete' covers it.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% for the single parameter task_id, with the schema description explicitly stating 'The task_id returned by lyzr_start_task.' The tool description does not need to add further parameter detail, so the baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Check the status and (when complete) result of a long-running Lyzr task.' The verb 'Check' specifies the action, and the resource is precisely the task status/result. It distinguishes itself from sibling tools like lyzr_start_task (which starts tasks) and other status tools by focusing on Lyzr tasks specifically.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage after starting a task, especially with the parameter description 'The task_id returned by lyzr_start_task', which clearly indicates the workflow. It does not explicitly mention alternatives or exclusions, but the context is clear and the pairing with lyzr_start_task is obvious.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kbsync_credential_listA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety and idempotency are covered. The description adds a scope distinction but no additional behavioral details such as pagination or output format. It provides minimal extra value beyond annotations, but is not contradictory.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that states the purpose and includes a crucial disambiguating caveat. No unnecessary words, and the key information is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only list tool with no output schema, the description provides the essential information for selection and invocation. It does not describe the exact fields returned, but the tool's simplicity and annotations compensate for that gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has zero parameters, so the baseline is 4. The description clarifies exactly what the list contains (KB Sync connector credentials), which is sufficient since there is nothing to document about parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'List' with a clear resource 'KB Sync connector credentials', and the parenthetical explicitly distinguishes it from the general RAG credentials system. This prevents confusion with sibling tools like lyzr_credential_list or other credential-related tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context by noting that these credentials are 'distinct from the general RAG credentials system', which helps an agent decide when to use this tool. However, it does not explicitly name alternative tools, but the distinction is enough to guide selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kg_train_text_taskA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses the async execution model and the return of a task id for polling, which goes beyond the annotations (readOnlyHint=false). It adds meaningful behavioral context not present in structured metadata. No contradictions with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Single 19-word sentence that front-loads the primary action and includes critical details (async, task id). Every word earns its place with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has no output schema, the description covers the essential return type (task id) and the async behavior. It doesn't mention how to poll, but the sibling lyzr_kg_task_status tool exists. The description is adequate for a straightforward async ingestion tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All 6 parameters have schema descriptions (100% coverage), so the baseline is 3. The tool description does not add any parameter-specific meaning, but the schema descriptions are sufficient for understanding the parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Ingest text into the v4 knowledge graph as an async task'. It identifies the specific resource (v4 knowledge graph) and distinguishes from sibling tools like lyzr_kg_train_text by noting the async nature and return of a task id.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description establishes that this is the async variant ('as an async task') and that the caller must poll the returned task id. This clearly signals when to use this tool, though it does not explicitly mention alternatives or when-not-to-use. The context is clear but exclusions are absent.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_memory_addA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare this as a non-read-only, non-idempotent operation. The description adds that it stores in 'Cognis memory' and requires at least one owner/agent/session identifier, but doesn't disclose side effects like whether messages are appended or existing memory affected. It doesn't contradict annotations, but 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences, first states the core action, second the critical constraint. No filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple create operation with a well-specified schema and annotations, the description covers the purpose, the key requirement, and the basic usage context. It doesn't explain return values or behavior when multiple identifiers are supplied, but these are not essential for a basic call. Given the high schema coverage and annotations, this is complete enough.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3. The description adds a critical cross-parameter constraint ('At least one of owner_id/agent_id/session_id is required') that is not encoded as a schema requirement. This meaningfully helps the agent construct valid calls.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('Store') on a specific resource ('Cognis memory') with a clear scope ('conversation messages'). It distinguishes from sibling memory operations (search, list, get, update, delete) by using 'add' in the name and 'store' in the description. The identifier requirement adds precision.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly indicates this tool is for persisting conversation messages, which is the appropriate use case. It doesn't explicitly name alternatives like memory_update or memory_delete, but the context is unambiguous. The requirement of at least one identifier provides practical usage guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_parse_imageA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate non-read-only and non-destructive behavior. The description adds modest context by mentioning OCR/VLM and 'text chunks,' but it does not disclose potential side effects, resource costs, or whether parsing is stateless. This is adequate given the annotation coverage but not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, well-formed sentence that front-loads the core purpose. Every word contributes meaning, with no repetition or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having 7 parameters, the schema fully documents each one, and the output schema is absent so no return-value explanation is needed. The description sufficiently captures the tool's role ('image file' + 'text chunks') and the explicit mention of OCR/VLM provides enough behavioral context for an agent to select and invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Since the schema covers 100% of parameters, the baseline is 3. The description adds value by clarifying that the input must be an image file (not just any file) and that the output will be text chunks, which complements the generic schema descriptions for file_content_base64 and chunking parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb ('Parse'), the resource ('image file'), and the outcome ('into text chunks'), making it immediately distinguishable from sibling parse tools for other formats. The mention of 'OCR/VLM' further specifies the mechanism 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 Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context that this tool is for image files, implicitly distinguishing it from parsing tools for PDFs, Word documents, text files, etc. However, it does not explicitly list alternatives or say 'use X instead for non-image files,' so it stops short of full explicit guidelines.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_rag_source_auth_sharepoint_authorizeA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes beyond the annotations by explaining that the tool starts a sign-in flow and returns a redirect URL. It does not contradict the readOnlyHint (starting a flow is not a mutating operation) and adds useful behavioral context about the immediate result.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single declarative sentence that is front-loaded with the action, resource, and outcome. No redundant words or irrelevant details.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description adequately covers the tool's role and output for a simple two-parameter tool. It could mention next steps (e.g., checking auth status), but the overall purpose is sufficiently clear without an output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptions for both parameters (rag_id and redirect_url). The description adds minimal extra meaning beyond the schema, simply echoing that a URL is returned. Baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Start' with the specific resource 'SharePoint sign-in flow for a knowledge base's source auth' and notes it returns a URL. This differentiates it from sibling tools like lyzr_rag_source_auth_status (status check) and lyzr_rag_source_auth_aci_handoff (handoff).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: use this to begin the SharePoint sign-in flow for a knowledge base. It does not explicitly list exclusions or compare against sibling tools, but the intended usage is unambiguous from the wording.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_report_usage_by_agentA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate readOnlyHint=false and idempotentHint=false, and the description adds valuable context that the operation is asynchronous and returns a job_id that requires polling. This tells the agent that invoking this tool will create a background job rather than returning immediate results, which is behavioral information beyond the annotation flags.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences long, front-loaded with the core purpose, and contains no redundant or irrelevant information. Every word earns its place, making it highly efficient for an agent to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For an async request tool with a comprehensive schema and annotations, the description covers the essential workflow: making the request, receiving a job_id, and polling for status. It does not explain the contents of the report, but that is not necessary given the schema and the existence of lyzr_report_get_status.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for all 8 parameters, including details about timeframes, date formats, and grouping options. The description text itself contributes no parameter-specific semantics beyond what the schema already documents, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Request'), object ('an async usage report'), and grouping ('broken down by agent'), distinguishing it from sibling usage report tools by its agent-level focus. It also clearly communicates the async nature and the next step (polling), 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 Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly states the async workflow: request, get job_id, poll with lyzr_report_get_status. This provides clear context for how to use the tool. However, it does not directly mention alternatives (e.g., usage_by_model, usage_by_sub_account) or exclusion criteria, though the tool name and phrase 'by agent' imply when it should be used.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_report_usage_by_modelA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Discloses the async nature and the need to poll with a separate tool, which is critical behavioral context beyond the annotations. Annotations (readOnlyHint=false, idempotentHint=false) are consistent with this description, and no contradiction 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two well-structured sentences deliver the core action and follow-up step without any fluff. Front-loaded and efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Covers the essential async request flow and directs the user to the polling tool. With the schema fully documenting parameters, the description is sufficient; mentioning the report's exact content beyond 'by model' is not necessary given the name and schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with detailed descriptions for all 7 parameters, so the description does not need to repeat them. The description adds no additional parameter semantics beyond the tool's overall purpose.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Request'), the resource ('async usage report broken down by model'), and the key behavior (returns a job_id, poll with lyzr_report_get_status). It effectively distinguishes from sibling report tools by explicitly targeting usage by model.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides clear context on when to use this tool (when a usage-by-model report is needed) and the required follow-up workflow (polling). It does not explicitly name alternatives or exclusions, but the guidance is unambiguous.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_report_usage_by_sub_accountA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses the async nature and the return of a job_id, which is critical behavior beyond what annotations specify. Annotations already indicate non-read-only; the description adds workflow detail, though it doesn't cover permissions or report content specifics.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences with no fluff. The first sentence states the primary purpose, the second gives the essential workflow. Perfectly front-loaded and concise.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For an async job tool with a rich schema, the description covers the core workflow (request, get job_id, poll). It doesn't explain the report's output format or potential need for permissions, but that is not critical given the schema and sibling tool reference.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the parameters are well documented in the schema. The description does not add additional parameter context, which is acceptable given the baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Request', the resource 'async usage report broken down by sub-account', and the key behavior 'Returns a job_id'. It distinguishes itself from sibling report tools by specifying the sub-account breakdown and explicitly linking to the polling tool.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It clearly implies usage for sub-account usage reporting and provides the necessary follow-up action ('poll with lyzr_report_get_status'). It does not explicitly exclude other report types, but the name and context differentiate it well enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_report_usage_by_userA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already disclose non-read-only, non-idempotent, open-world behavior, and the description adds the key behavioral detail that the call is asynchronous and returns a job_id to poll. This adds context beyond the annotations — no contradiction; readOnlyHint=false is consistent with creating a background job resource.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with the purpose and followed by the essential async follow-up. Every word earns its place; there is no padding and no repetition of schema content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple async job-request tool with no output schema, the description fully covers the return value (job_id) and next step (poll with lyzr_report_get_status). It could specify org scoping or conditional param requirements, but the schema handles parameter semantics and the core flow is completely explained.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all five parameters and their enums are already fully documented in the schema. The description adds no parameter-level detail, which matches the baseline-3 rule for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Request') paired with a concrete resource ('async usage report broken down by user'), immediately communicating the tool's function. It clearly distinguishes from sibling report tools via the 'by user' dimension and orients the agent to the async pattern by naming the polling companion, lyzr_report_get_status.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description conveys the essential usage workflow: call this tool to request the report, receive a job_id, then poll with lyzr_report_get_status. It does not explicitly name alternatives like lyzr_report_usage_by_model or lyzr_report_usage_by_sub_account, but the by-user scope plus the async polling instruction give clear contextual guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_semantic_model_save_documentationA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already convey that this is not read-only and not destructive. The description adds the synchronous behavior, which is a key operational trait not covered by annotations. Additional detail about overwrite semantics or return values is not provided but is not strictly necessary given the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence (12 words) that is front-loaded with the key action and scope. No filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description together with the rich schema provides enough information to understand the tool's purpose and inputs. It lacks details on the return value or error behavior, but for a save operation with fully documented parameters, this is acceptable. The synchronous distinction adds context for selecting the right tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers 100% of parameters with descriptions. The tool description does not add any extra parameter context, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (save), the resource (table/column descriptions and table preview), and the synchronous nature, which differentiates it from the sibling tool 'lyzr_semantic_model_save_documentation_task'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly notes that this is synchronous, which is a clear usage signal. However, it does not explicitly mention the alternative asynchronous 'save_documentation_task' or when to prefer one over the other.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_semantic_model_save_documentation_taskA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations indicate this is a write operation (readOnlyHint false) and non-destructive, and the description adds important async behavior: it returns a task_id rather than the result, and points to the polling tool. It does not mention overwrite semantics or possible side effects on existing documentation, but the provided context is sufficient given the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences with the main action, the async qualifier, and the polling instruction; no redundancy or low-value prose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a background task tool with no output schema, the description adequately conveys the invocation model (submit and get a task_id) and names the follow-up tool. It could be more explicit about error handling or whether the save overwrites existing descriptions, but the essential usage is documented.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already describes all four parameters with 100% coverage, including the nested structure of 'descriptions'. The description adds only a high-level mapping of inputs (table/column descriptions and preview) without new meaning, so baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Save' and specifies the resource ('table/column descriptions and a table preview') as well as the background-task nature, which differentiates it from the synchronous sibling lyzr_semantic_model_save_documentation. This gives the agent a precise understanding of the tool's function.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It clearly states the tool runs as a background task and directs the agent to poll with lyzr_semantic_model_get_task_status using the returned task_id. However, it does not explicitly contrast this with the synchronous save_documentation sibling or state when one should be preferred over the other.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_session3_treeA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and idempotentHint, so the safe, non-mutating nature is covered. The description adds context by specifying 'full branch tree' and 'v3 session', and the parameter schema further adds that session_id can be 'any node in the tree', which is a useful behavioral detail. It doesn't cover return format, but with annotations present the description provides meaningful additional scoping.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is one concise sentence, front-loaded with the verb and key resource. Every word earns its place, with no redundant information or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having only 1 parameter and no output schema, the description is adequate for a simple read-only retrieval tool. It identifies the input and the general output (full branch tree) without needing to explain return fields. Some ambiguity remains about what exactly the tree contains (nodes, messages, metadata), but given the simplicity and sibling context, it is sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: the only parameter, session_id, is described as 'Session id (any node in the tree)' in the schema. The tool description adds no additional parameter-level meaning beyond what the schema already conveys. Therefore, the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Get the full branch tree rooted at a v3 session' uses a specific verb (Get) and resource (full branch tree) with clear scope (rooted at a v3 session). It contrasts well with sibling tools like lyzr_session3_list_branches (which lists branches) and lyzr_session3_ancestry (which likely traces ancestors), making its purpose distinct and easily understood.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The context is clear: use this tool when you need the full branch tree from a session node. It doesn't explicitly name alternatives or exclusion conditions, but the 'full branch tree' wording implies it is for complete tree retrieval rather than listing branches or getting a single session. This meets the 'clear context, no exclusions' bar.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_sharing_reconcile_indexesA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the description does not need to restate these. It adds the scope 'all sharing indexes' but does not explain side effects, runtime expectations, or whether it is safe to run concurrently. The description adds some value beyond annotations but lacks depth.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence of 9 words, front-loaded with the action ('Trigger') and object. It contains no filler and every word contributes to meaning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, no-output-schema trigger tool, the description is adequately complete. It states the action and scope. However, it could briefly mention intended use (e.g., 'run periodically to fix inconsistencies') or expected outcome to fully contextualize the tool for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and schema coverage is 100% (empty schema). Baseline for zero-parameter tools is 4. The description does not need to add parameter semantics, and none is provided.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'trigger' and clearly identifies the resource ('all sharing indexes') and the action ('reconciliation pass'). It distinguishes from sibling sharing tools (e.g., lyzr_sharing_check_access, lyzr_sharing_list_groups) by focusing on an internal maintenance operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The context is clear: this is a maintenance operation for reconciling sharing indexes. However, it does not explicitly state when to use it vs. alternatives or mention any prerequisites or exclusions. For a zero-parameter trigger tool, the implied usage is adequate but not explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_submit_chat_taskA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds valuable behavioral context beyond annotations by disclosing the async/non-blocking nature and the need to poll for results. Annotations already indicate a write operation (readOnlyHint=false), and the description complements this without contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no redundant content. It communicates the action, target, and return value efficiently.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the core flow (submit, get task_id, poll) and is largely complete given the detailed schema. Minor gaps exist: it doesn't explicitly name the polling tool (lyzr_get_chat_task_status) or clarify the relationship between 'message' and 'messages', but these are not critical for basic usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All parameters have descriptions in the schema (100% coverage), so the tool description doesn't need to add parameter details. It doesn't, and the baseline of 3 applies because the schema carries the load for parameter semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states the tool submits a chat message to an agent as an async task and returns a task_id for polling. This distinguishes it from synchronous chat siblings like lyzr_chat and lyzr_stream_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/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly mentions 'async task' and 'returns a task_id to poll', providing clear context for when to use this tool over synchronous alternatives. However, it does not explicitly name alternatives or state when not to use it, so it falls short of full guideline coverage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_widget_streamA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes beyond annotations by disclosing the streaming behavior and the server-side fixed target. Since annotations only declare non-read-only and non-idempotent, this added context is valuable and not contradicted by the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences long, front-loaded with the main action and resource, followed by a key constraint. Every word earns its place with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple 2-parameter tool, the description covers the core behavior (send and stream) and important constraints (fixed target, no credentials). It lacks detail on the streamed response format, but this is a minor gap given the tool's simplicity and the rich sibling context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides descriptions for both parameters (100% coverage). The tool description adds no parameter-specific information beyond what the schema already contains, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool sends a message to a pre-configured embeddable widget agent and streams back the response. It distinguishes itself from sibling chat tools (e.g., lyzr_chat, lyzr_stream_chat) by emphasizing the fixed server-side agent and lack of agent_id/credentials.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly states no agent_id or credentials are accepted, which clarifies when this tool is appropriate (for pre-configured widget agents) and when it is not (any scenario requiring agent selection). However, it does not name specific alternative tools for those other scenarios, so it stops short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_org_llm_fallbacksA
  4.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds no additional behavioral context (e.g., return format, edge cases, permissions), but also does not contradict the annotations. A neutral score is appropriate given the strong annotation coverage.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence of eight words, using precise language without any filler. It front-loads the verb and resource, making it instantly scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is inherently simple: no parameters, read-only, and the description fully states what it retrieves. With strong annotations and low complexity, no additional detail is needed for an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so there is no parameter description burden. The schema description coverage is 100% by virtue of having no properties, and the description's 'organization's' implies the scope. The baseline of 4 is earned for this parameter-free tool.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Get' and clearly names the resource 'organization's configured LLM fallback chain'. This distinguishes it from the sibling update tool (lyzr_update_org_llm_fallbacks) as the read counterpart.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies read-only retrieval of the fallback chain, which is appropriate for this getter tool. However, it does not explicitly name the sibling update tool or state when not to use it, so it falls short of fully explicit alternative guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_kbsync_connector_listA
  4.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate the operation is read-only, idempotent, and open-world. The description adds the behavioral detail that it lists all connectors, but does not provide additional context such as pagination or return format.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single sentence that is direct and free of any filler. It perfectly captures the tool's purpose without unnecessary detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple zero-parameter list operation with strong read-only annotations, the description is sufficiently complete. It clearly states the scope ('all') and the resource, which is all an agent needs to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the description does not need to explain parameter semantics. The baseline for 0-param tools is 4, and the description adds no conflicting information.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific action ('List') on a specific resource ('KB Sync connectors'). It distinguishes itself from sibling tools like lyzr_kbsync_connector_get (single connector) and lyzr_kbsync_connector_create (create).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context that this tool lists all connectors, which implies when to use it. It does not explicitly mention alternatives, but no exclusions are needed for a simple list operation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_world_model_deleteA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide destructiveHint=true and idempotentHint=true. The description adds the explicit qualifier 'Permanently', which clarifies irreversibility beyond the annotation. This is useful contextual information beyond what structured data provides.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, direct sentence of seven words that gets straight to the point. No filler or repetition. The action, resource, and scope are all front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete operation with one parameter, full schema coverage, and annotations covering destructiveness and idempotency, the description is sufficiently complete. It clearly states the action and target, and no output schema is needed for a standard delete response.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers 100% of the parameter with a description ('The world model id to delete'). The description repeats 'by id' but adds no new semantic information beyond the schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Permanently delete a world model by id' uses a specific verb (delete), specifies the resource (world model), and scopes by id. It clearly distinguishes this from sibling tools that delete sub-resources like personas or test cases.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies this is the tool for deleting a world model by id, which is distinct from sibling tools for deleting related sub-resources. It does not explicitly state exclusions or alternatives, but the context is clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lyzr_get_modulesA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnly, idempotent, and openWorld hints. The description adds behavioral context by explaining that modules are 'resolved' for the caller, implying access-based filtering, and lists the content (nav + footer). This goes beyond the annotations and clarifies 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is one short sentence (11 words), directly states the purpose, and includes the key qualifiers ('resolved', 'nav + footer', 'current caller'). No unnecessary words or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple zero-parameter getter, the description adequately explains what is returned (nav + footer modules) and for whom. It lacks an explicit return structure, but given the tool's simplicity and no output schema, this is not a critical gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, and the schema coverage is trivially 100%. With no parameters to document, the description is not required to add parameter details; a baseline of 4 is appropriate since there is no ambiguity.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific action ('Get') and a specific resource ('resolved sidebar modules'), with scope ('for the current caller'). This distinguishes it from siblings like 'lyzr_list_modules_admin' and 'lyzr_get_module_admin', which target admin use cases.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the usage context by specifying 'for the current caller', indicating this is for retrieving the caller's own modules, not an admin or bulk operation. However, it does not explicitly mention alternatives or exclusions, so it stops short of full guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.