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

No annotations are present, so the description carries the full burden of disclosing side effects, but it only states the action without mentioning durability, possible failure on duplicate values for unique indexes, blocking behavior, or reversibility. For a schema-mutating operation this is a notable gap.

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

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

The description is a single, front-loaded sentence that states the essential action with no wasted words. It is appropriately sized relative to the schema's existing parameter documentation.

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

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

The schema fully documents the parameters, but with no output schema and no annotations, the description leaves behavioral and return expectations unstated. It is minimally adequate for invoking the tool, yet incomplete regarding outcomes and failure conditions.

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

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

Schema description coverage is 100%, with both collection and indexDefinition already well described in the input schema, including nested fields like unique and nullsNotDistinct. The description adds no extra parameter meaning but does not need to because the schema carries the detail.

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

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

The description names a specific verb ('Add') and resource ('an index to a collection schema'), which clearly identifies the operation and distinguishes it from the inverse sibling baasix_remove_index. No ambiguity about what the tool does.

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

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

The description gives no guidance on when to add an index versus alternatives, or any context such as performance considerations or prerequisites. It does not mention the inverse sibling or when a unique/standard index should be chosen, leaving usage entirely to inference.

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

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

With no annotations provided, the description carries the full burden. 'Check' implies a read-only operation with no side effects, which is useful, but the description does not disclose behavior such as response format, error handling when unauthenticated, or whether token validity checks trigger network calls.

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

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

A single, front-loaded sentence with zero wasted words. Every word contributes to stating the tool's purpose.

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

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

Adequate for a very simple 0-parameter status check, but since no output schema exists, the description could usefully state what the tool returns (e.g., boolean vs. status object) and could mention its relationship to auth lifecycle siblings. These are gaps, though minor given the tool's simplicity.

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

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

The tool has zero parameters, so the description has no parameter semantics to add. The baseline of 4 applies: nothing is missing on this front.

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

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

The description states a specific verb ('Check') and precise resources ('authentication status and token validity'). It clearly distinguishes this from sibling tools like baasix_login, baasix_logout, and baasix_refresh_auth, which perform actions rather than read state.

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

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

No guidance is given on when to use this tool versus related siblings such as baasix_get_current_user or baasix_refresh_auth, and there are no exclusions or conditional recommendations. The usage context is only implied by the name and description, not stated.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get' implies a read-only operation, but the description does not state what metrics are returned, whether the operation is expensive or cached, what happens when optional parameters are omitted, or whether permissions are required.

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

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

The description is one short, parseable sentence with no filler, and the key subject ('collection statistics') is front-loaded. Minor redundancy exists since 'analytics' largely overlaps with 'statistics', but overall it is appropriately concise.

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

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

With no output schema and no annotations, the description omits the shape of the returned statistics, the default scope when collections is omitted, and how timeframe affects the results. This is enough to guess the tool's purpose but not enough for an agent to invoke it confidently.

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

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

Schema description coverage is 100%, so the schema already documents both timeframe and collections parameters. The description adds no additional meaning about how these parameters affect the statistics returned.

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

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

The description uses a clear verb ('Get') and names a specific resource ('collection statistics and analytics'), making it identifiable as a read/analytics tool. However, 'analytics' is broad and it does not explicitly distinguish itself from sibling tools like baasix_generate_report or baasix_server_info.

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

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

There is no guidance on when to use this tool versus alternatives. An agent must infer from the name that it is the appropriate choice for collection-level statistics, with no comparison to baasix_list_items, baasix_get_item, or baasix_generate_report.

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

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

No annotations are provided, so the description carries full responsibility for behavioral disclosure. 'Create' only implies mutation; it does not state whether creation validates against a schema, auto-generates IDs, overwrites existing data, requires authentication, or what side effects occur.

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

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

The description is a single short sentence with no filler and front-loads the verb and object. It is concise, though the brevity comes at the cost of useful behavioral detail.

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

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

Without annotations or an output schema, the description does not tell the agent what happens after calling the tool, such as the returned item/ID, error behavior, or prerequisites like an existing collection/schema. For a mutating operation, this is incomplete.

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

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

Schema description coverage is 100%, since both 'data' and 'collection' have descriptions in the schema. The description adds only generic context that the item belongs to a collection, so it provides little 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.

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 clear resource ('a new item in a collection'), which distinguishes it from sibling item operations like update_item, delete_item, and list_items. It is not a pure tautology because it clarifies the item belongs to a collection, though it is still very close to the tool name.

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

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

There is no guidance about when to use this tool versus alternatives. It does not mention that a schema/collection must already exist, that this is the write counterpart to get/list/update/delete, or any conditions that would make this tool the right choice.

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

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

With no annotations provided, the description carries the full burden of disclosing behavior. It does a good job explaining the semantics of conditions, relConditions, and fields with concrete examples. However, it does not disclose side effects of creating a permission, such as whether it takes effect immediately, whether it can override existing permissions, or whether it might alter access control behavior in ways that could lock users out.

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

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

The description is well-structured with clear section headers (ACTIONS, FIELDS, CONDITIONS, RELCONDITIONS, EXAMPLE) and front-loaded with the core purpose. It is longer than average but every section contributes useful information. A small deduction because the example block repeats some information from the schema and the structure could be slightly tighter.

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

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

Given the complexity of this permission creation tool (7 parameters, nested objects, no output schema), the description is largely complete. It explains the important non-obvious concepts: field whitelisting, row-level security conditions, and related record filtering, each with examples. It does not mention the return value or any permission required to call the tool, but these are minor gaps for an AI being able to construct a valid request.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by providing concrete JSON examples for conditions (e.g., {"published": {"eq": true}}), relConditions (e.g., {"reviews": {"approved": {"eq": true}}}), and fields (e.g., ["name", "price"]), which clarifies the expected structure for nested objects. It does not explicitly walk through defaultValues, but the schema already covers that sufficiently.

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

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

The description opens with 'Create a new permission for role-based access control,' which combines a specific verb (create), a specific resource (permission), and the domain context (role-based access control). This clearly distinguishes it from sibling tools like baasix_update_permission, baasix_delete_permission, and baasix_list_permissions, so an agent can immediately know which tool to pick.

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

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

The description explains how to structure a permission but never states when to use this tool versus the many sibling permission tools (update, delete, get, list). There is no explicit guidance about selecting this tool for creation over others, nor any mention of prerequisites or scenarios such as 'use this to grant a role access to a collection.' The intent is only implicit through the verb 'create.'

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

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

With no annotations, the description carries the full load and does so well: it discloses auto-indexing on foreign keys, junction table naming rules, virtual reverse behavior for O2M, and the default onDelete behavior. It does not mention authorization requirements or whether creation is reversible, but the behavioral side effects are unusually well documented.

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

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

The description is long but every section earns its place given the complexity of five relationship types. It is front-loaded with the core purpose, then organized by relationship types, auto-indexing, junction tables, and examples, with no filler or repeated schema content.

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

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

For a no-output-schema tool with no annotations, this is quite complete: it explains side effects, naming conventions, indexing, and provides runnable examples. It stops short of describing the return value, error conditions, or preconditions like target collection existence, which would round out the picture.

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

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

Schema coverage is 100%, so the baseline is already solid. The description adds substantial meaning beyond the schema: it explains that 'name' creates a fieldName_Id field plus index, shows what 'through' controls with a max length, clarifies 'alias' as the reverse relation name, and gives full examples with default onDelete behavior.

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

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

Description states a clear action ('Create a relationship between collections') and goes beyond a bare verb by enumerating all five relationship types with concrete examples. The name is distinct among siblings like update_relationship and delete_relationship, and the description reinforces that it creates, not modifies or removes.

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

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

The description makes it clear this tool is for creating relationships and provides detailed context for when each relationship type fits. However, it never explicitly contrasts with update_relationship or delete_relationship, so an agent must infer when to choose the create tool over its siblings.

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

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

With no annotations present, the description carries the burden of behavioral disclosure. It does this well by explaining concrete effects such as 'timestamps: true adds createdAt/updatedAt', 'paranoid: true enables soft deletes', and how different field types map to storage types like VARCHAR or JSONB. It does not mention error behavior, auth requirements, or what happens if a collection already exists.

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

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

The description is long but well-organized into clear sections: FIELD TYPES, DEFAULT VALUE TYPES, VALIDATION RULES, SCHEMA OPTIONS, and EXAMPLE. The opening sentence states the purpose immediately, and every section earns its place by providing syntax-level detail needed to construct a valid payload.

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

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

For a creation tool with a complex nested schema parameter and no output schema or annotations, the description is largely complete. It specifies field types, defaults, validation rules, options, and an example. Missing details include return value/response format, behavior on duplicate collections, and auth/tenant expectations, but the core payload construction is fully covered.

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

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

The input schema already documents both parameters and has 100% coverage, so the baseline is 3. The description adds substantial meaning for the `schema` parameter by enumerating field types, default value types, validation rules, and schema options, plus a full example. The `collection` parameter is not enriched beyond the schema description, and the relationship between `collection` and the schema's `name` field is not clarified.

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

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

The opening sentence states a specific verb and resource: 'Create a new collection schema in Baasix.' The word 'new' distinguishes it from update, delete, or read schema operations, and the tool name aligns clearly with this purpose.

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

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

The description clearly implies this tool is for creating new schemas, but it never explicitly says when to use it versus alternatives like baasix_update_schema or baasix_list_schemas. There are no usage exclusions or prerequisites stated, so the agent must infer when this tool is the right choice.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. 'Delete' implies destructiveness, but the description does not state whether deletion is permanent, reversible, or what happens to related data or references.

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

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

The description is three words with no wasted content. Every word contributes to the meaning, and the essential operation is front-loaded.

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

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

The tool is very simple with one well-documented parameter and no output schema, so the minimal description may be adequate for basic invocation. However, without annotations or mention of return behavior, reversibility, or failure modes, it lacks full operational context for an agent.

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

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

The schema fully documents the only parameter 'id' as 'File ID', and the description adds no additional parameter semantics. Since schema coverage is 100%, the baseline of 3 is appropriate.

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

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

The description 'Delete a file' states a specific verb and resource, making the core operation unmistakable. It is clear but does not explicitly differentiate itself from sibling file-related tools like baasix_get_file_info or baasix_list_files, though the delete verb already implies the distinction.

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

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

There is no guidance on when to use this tool versus alternatives, such as baasix_delete_schema or baasix_delete_item, nor any mention of prerequisites or side effects. The usage context is left entirely to the agent's inference 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.

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

Annotations are absent, so the description carries the full burden of behavioral disclosure. It only states the action without mentioning whether deletion is permanent, whether it cascades to related data, what happens if the item does not exist, or any authorization requirements. This is a thin disclosure for a destructive mutation.

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

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

A single, front-loaded sentence with no wasted words. It clearly communicates the operation in an efficient manner, and the description earns its place without redundancy.

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

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

Given the absence of annotations and an output schema, the description is too minimal to fully prepare an agent for the call. It omits side effects, return behavior, error conditions, and any collection-specific semantics, making it incomplete even for a simple delete operation.

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

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

Schema description coverage is 100%, so both parameters (collection and id) are already documented in the schema. The description adds no additional meaning beyond mapping 'item' and 'collection' to the parameters, so the baseline of 3 applies.

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

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

The description states a specific verb ('Delete') and resource ('an item from a collection'), clearly matching the required parameters. The noun 'item' implicitly differentiates it from sibling delete tools like baasix_delete_schema, baasix_delete_file, and baasix_delete_relationship, but it does not explicitly name them.

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

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

No guidance is provided about when to use this tool versus alternatives, such as baasix_delete_schema or baasix_delete_relationship. There are no prerequisites, exclusions, or conditions mentioned, leaving the agent with only the tool's name and generic description to infer usage.

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

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

No annotations are provided, so the description must carry the behavioral disclosure burden. It only repeats that the operation is a delete and does not state whether deletion is permanent, cascades to dependent roles or items, requires special permissions, or what happens when the ID does not exist. This adds no behavioral context beyond the tool name.

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

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

The description is technically short, but it is under-specified rather than appropriately concise. "Delete a permission" is essentially a repetition of the tool name and contains no useful additional content, so brevity here does not reflect good structure.

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

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

With no annotations and no output schema, even a simple delete operation should state the effect, return behavior, or failure mode. The description provides none of this, leaving the agent to infer the consequences of a destructive call. This is inadequate for a permission-deletion tool.

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

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

The input schema documents the single required "id" parameter as "Permission ID" with 100% coverage. The description adds no additional meaning about ID format, source, or validation. Since schema coverage is high, the baseline is 3, and the description neither helps nor hurts parameter understanding.

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

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

The description is "Delete a permission," which restates the tool name baasix_delete_permission and adds no information about scope, effect, or confirmation. It names a verb and resource but does not distinguish or elaborate beyond what the tool name already conveys.

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

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

No context is provided about when to use this tool versus sibling permission tools like baasix_get_permission, baasix_update_permission, or baasix_list_permissions. There are no prerequisites, exclusions, or alternative routing, so the agent receives no usage guidance.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that a relationship is deleted, which implies destructiveness, but it does not disclose whether the operation is permanent, whether it cascades or validates, whether permissions are required, or what happens if the relationship 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.

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

The description is short and front-loaded, but it is under-specified rather than genuinely concise. It simply restates the tool name in sentence form and contains no additional useful information to justify its place.

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

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

For a destructive tool with no annotations and no output schema, this description is incomplete. It does not explain what a relationship is in this system, what sourceCollection and fieldName refer to semantically, or what consequences deletion has. The schema describes parameter names but cannot compensate for the missing behavioral and operational context.

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

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

The input schema has 100% description coverage because both fieldName and sourceCollection are described. The description itself adds no parameter semantics, but the schema already documents the parameters adequately, 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.

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

The description 'Delete a relationship' is essentially a restatement of the tool name 'baasix_delete_relationship' in natural language. It names the target resource but adds no detail about what kind of relationship, what scope it applies to, or what effect it has, so it does not help an agent beyond the name itself.

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

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

There is no guidance on when to use this tool versus alternatives such as baasix_create_relationship, baasix_update_relationship, or even baasix_delete_item. No conditions, 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.

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

With no annotations, the description carries the full disclosure burden. It only says 'Delete', which implies destructive behavior, but it does not mention irreversibility, cascading effects on collections/items, permissions required, or what is returned after deletion.

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

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

The description is a single four-word sentence with no filler; every word contributes to the core meaning. Its brevity is appropriate for a one-parameter delete operation.

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

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

Although the parameter schema fully covers the input and the operation is simple, the description omits consequences of deletion and the return behavior. No output schema exists and no annotations offset this gap, so an agent lacks important context for a destructive tool.

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

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

The single parameter 'collection' is already fully documented in the schema as 'Collection name', so the description adds no additional semantic detail beyond that. 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.

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

The description names a precise verb ('Delete') and a specific resource ('collection schema'), which distinguishes it from siblings such as baasix_create_schema, baasix_update_schema, and baasix_get_schema. An agent can immediately identify the schema-deletion operation.

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

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

The description implies the tool is used when a collection schema should be removed, but it does not explicitly state when to use it versus related schema operations, prerequisites, or destructive conditions. Context from the sibling set helps, but no direct guidance is provided.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Export all schemas as JSON' and does not mention whether the operation is read-only, whether it returns a file or inline JSON, whether it requires authentication, or whether it has side effects. The output format is disclosed, but other 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.

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

The description is a single, clear, front-loaded sentence with no filler. Every word adds meaning: 'Export' indicates action, 'all schemas' defines scope, and 'as JSON' defines the format.

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

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

For a zero-parameter tool with no output schema, the description is mostly sufficient: it communicates the action, scope, and format. It could be enriched by explaining what 'export' returns (e.g., an array vs. an object) and whether it includes relationships, but these are relatively minor gaps for such a simple operation.

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

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

The tool has zero parameters and the schema coverage is 100%, so there is nothing for the description to add about input semantics. The mention of 'as JSON' provides some useful information about the output format, which partially compensates for the lack of an output schema.

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

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

The description states a specific verb ('Export'), a resource ('all schemas'), and an output format ('as JSON'). It clearly distinguishes itself from siblings like baasix_list_schemas (which likely lists metadata) and baasix_get_schema (singular) by emphasizing the bulk export of all schemas.

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

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

There is no guidance on when to use this tool versus alternatives such as baasix_list_schemas, baasix_get_schema, or baasix_import_schemas. The description does not state any exclusions, prerequisites, or conditions, leaving usage entirely implied.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does not clarify whether generating a report is read-only, whether it creates a stored artifact, or what kind of response the agent should expect. 'Generate reports' is ambiguous about side effects and output.

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

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

A single focused sentence with no wasted words. It front-loads the main action and scope, making it easy for an agent to scan and retain.

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

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

For a tool with 4 parameters, a nested dateRange object, no annotations, and no output schema, this description is too thin. It does not explain the return format, how grouping and aggregation interact, or any constraints on filter/dateRange values. The agent is left without enough context for reliable invocation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds the notion of aggregation beyond what the schema's groupBy field says, but it leaves filter criteria, date range format, and aggregation behavior underspecified.

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

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

The description names a clear verb (Generate), resource (reports for a collection), and core capability (grouping and aggregation). It does not explicitly differentiate from siblings like baasix_collection_stats or baasix_list_items, 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.

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

No guidance is given on when to prefer this tool over baasix_list_items or baasix_collection_stats, and there are no exclusions, prerequisites, or alternative tool mentions. The grouping/aggregation hint implies a use case, but the description does not state it directly.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a read operation but does not mention session requirements, behavior when no user is logged in, or possible error cases. This is minimal transparency for a tool that depends on auth context.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes to conveying the tool's purpose.

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

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

This is a simple getter with one optional parameter, so a short description can be acceptable. However, with no output schema and no annotations, the description does not clarify the return shape, whether authentication is required, or how the 'fields' parameter affects the result. These are meaningful gaps for an agent deciding to call it.

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

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

The single parameter 'fields' is already fully described in the schema as 'Specific fields to retrieve', giving 100% schema coverage. The description adds no additional parameter detail, 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.

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 identifies the resource: current user information, including role and permissions. It is reasonably distinct from sibling tools like baasix_auth_status or baasix_get_user_tenants, though it does not explicitly contrast itself with them.

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

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

The description provides no guidance on when to use this tool versus the many related auth/user sibling tools, nor does it mention prerequisites such as being logged in. The intended usage is only implied by the tool's purpose.

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

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

With no annotations, the description carries the safety burden; 'Get' signals a read-only operation, which is useful behavioral context. However, it does not state what the returned 'detailed information' includes, whether authentication is required, or how missing/invalid IDs are handled.

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

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

The sentence is short and front-loaded with the action, and there is no filler or repetition. It loses one point because 'detailed information' remains vague, making the sentence concise but not information-dense.

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

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

For a one-parameter read tool, the description plus 100% schema coverage is minimally sufficient to call it: provide a file ID and expect file information. But with no output schema and no annotation safety profile, the absence of return-value detail and ID provenance keeps it from being more complete.

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

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

Schema coverage is 100% and the only parameter id is already documented as 'File ID'. The description adds 'specific file' but no extra semantics, so it falls 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.

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

The description names a concrete verb ('Get') and resource ('detailed information about a specific file'), scoping the operation to a single file. This distinguishes it from siblings like baasix_list_files (listing) and baasix_delete_file (deletion).

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

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

It provides no guidance on when to call this tool instead of baasix_list_files or baasix_get_item, and no mention that the file ID likely comes from a prior list call. The agent must infer usage entirely from the name and surrounding tools.

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

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

No annotations are supplied, so the description is the only safety signal. 'Get' clearly indicates a read-only retrieval, and 'optionally including related data' adds behavioral context beyond the schema. It does not mention not-found behavior or auth requirements, but the read operation carries low risk.

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

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

One sentence with no filler; every phrase conveys the operation's scope and the optional relation feature. It is well front-loaded and easy to parse.

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

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

For a simple read tool, the schema plus the description covers invocation. Return format and not-found behavior are not described and no output schema exists, so agents must infer the response shape, but the core call is unambiguous.

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

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

All three parameters are documented in the schema with 100% coverage, so the baseline is 3. The description repeats the conceptual role of id, collection, and fields but adds no syntax or default details beyond what the schema already provides.

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

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

States a clear verb+resource: 'Get a specific item by ID from a collection'. The qualifier 'specific... by ID' distinguishes it from baasix_list_items, though it does not name a sibling explicitly.

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

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

The phrase 'by ID from a collection' gives clear context for when to retrieve a single item, but it does not explain when to prefer baasix_list_items for multiple results or when to include related data. Usage is implied rather than explicitly contrasted with alternatives.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It only indicates a read-style operation ('Get') and gives no detail about return values, error behavior, authentication requirements, or what happens if the ID 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.

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

The description is a single clear sentence with no filler or redundancy. It front-loads the action and resource, and every word contributes meaning.

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

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

For a simple get-by-ID operation with one fully documented parameter, the description is largely sufficient. It does not describe the return shape or not-found behavior, but since there is no output schema and the operation is simple, the core invocation context is adequate.

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

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

Schema description coverage is 100%: the only parameter, 'id', is already described as 'Permission ID' in the schema. The description's 'by ID' simply reinforces the schema 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.

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

The description states a specific verb and resource: 'Get a specific permission by ID'. It clearly identifies the operation's target and scope, and the phrase 'specific' helps separate it from list-style siblings, 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.

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

The phrase 'by ID' implies this tool is appropriate when a caller already has a permission ID and needs that one permission. However, it does not explicitly state when to prefer this over baasix_list_permissions or baasix_get_permissions, nor does it mention any exclusions.

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

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

No annotations are provided, so the description carries the behavioral burden. 'Get permissions for a specific role' conveys a read-only retrieval intent, but it does not disclose whether the role must exist, what the response shape is, or how errors are handled. This is adequate for a simple getter 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.

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. Every word contributes to understanding what the tool does.

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

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

For a single-parameter read-only retrieval tool with no output schema, the description is sufficient to guide invocation: the agent knows it needs a role name. It could be more complete by noting that available roles can be found via baasix_list_roles, but that is not essential for correct basic use.

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

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

Schema description coverage is 100% and the role parameter already has a clear description ('Role name'). The tool description adds little beyond restating the role's purpose, 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.

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

The description states a specific verb ('Get'), a clear resource ('permissions'), and a scope ('for a specific role'). This distinguishes it from baasix_list_permissions and baasix_get_permission, 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.

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

The description implies the tool should be used when permissions for a particular role are needed, but it gives no explicit guidance about when to prefer sibling tools such as baasix_get_permission or baasix_list_permissions. No exclusions or alternatives are mentioned.

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

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

No annotations are provided, so the description must carry behavioral disclosure. It only restates what the name implies ('get schema') and does not describe the return value, read-only guarantee, required permissions, or behavior when the collection 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.

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 states the action, the resource, and the scope in minimal words, which is ideal for quick agent scanning.

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

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

For a one-parameter read-only tool, the description is minimally sufficient to invoke it correctly. However, with no output schema, it does not explain what 'detailed schema information' actually contains (fields, indexes, types, etc.), leaving a clear gap in the agent's understanding of the expected result.

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

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

The only parameter, 'collection', is fully described in the schema as 'Collection name', giving 100% schema description coverage. The description adds the word 'specific' but provides no additional format, example, or constraints beyond what the schema already states, 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.

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 resource ('detailed schema information') scoped to 'a specific collection'. It distinguishes from the sibling baasix_list_schemas by emphasizing a single collection, though it does not explicitly name or contrast that sibling.

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

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

The phrase 'for a specific collection' implies the tool should be used when a particular collection is already known, rather than when enumerating all schemas. However, it does not explicitly say when not to use it or suggest baasix_list_schemas for discovery of collections.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely restates the tool name and provides no detail about read-only behavior, default return behavior when the key is omitted, error handling, 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.

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

The description is three words with no filler and is front-loaded with the action and resource. It is appropriately concise for a simple getter, though it could have used the space to add one or two clarifying details.

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

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

The tool is simple with one optional, fully documented parameter, so a minimal description is partially acceptable. However, the behavior when the key is omitted or invalid is not stated, and since there is no output schema, the agent is left without enough detail to fully predict the result.

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

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

The input schema fully describes the only parameter ('key'), with 100% schema description coverage, so the baseline applies. The description itself adds no additional meaning 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.

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

The description uses a specific verb ('Get') and identifies a clear resource ('application settings'), so the basic purpose is unambiguous. It does not explicitly differentiate itself from siblings like baasix_update_settings or baasix_server_info, but the resource is distinct enough to be recognized as a settings retrieval tool.

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

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

There is no guidance about when to use this tool versus alternatives such as baasix_update_settings or baasix_get_schema. The description only states what the tool does, leaving the agent to infer appropriate usage from the tool name and siblings.

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

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

No annotations are provided, so the description carries the burden of disclosing behavior. The verb 'Get' clearly indicates a read-only operation, but it does not mention what happens if the ID does not exist, whether the response is the full template content or metadata, or any other non-obvious behavior. This is a minimal but not misleading disclosure.

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

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

The description is a single, front-loaded sentence that states the action, resource, and identifier in the most direct way possible. There is no filler 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.

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

The tool has only one parameter and no output schema, so the description should clarify what the caller receives in return. It names the resource and the lookup key but does not describe the return value or error behavior, leaving a notable gap for an agent that must rely solely on this description.

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

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

The input schema already documents the only parameter as 'Template ID (UUID)' with 100% coverage. The description's 'by ID' adds no new semantic 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.

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 ('email template'), and scopes it by 'ID', making it clear this is a single-item fetch. This clearly distinguishes it from sibling tools such as baasix_list_templates and baasix_update_template without needing to read their schemas.

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

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

The description does not explicitly state when to use this tool over alternatives like list_templates or update_template. The intended usage is implied by the phrase 'by ID' — use it when you already have a specific template UUID — but no explicit context, exclusions, or alternative routing is provided.

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

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

The verb 'Get' implies a read-only operation, and 'for the current user' signals user-scoped, authentication-dependent behavior. With no annotations present, the description carries the burden, but it does not disclose potential behaviors like returning an empty list, requiring an active session, or error cases if no tenant is available.

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

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

The entire description is one short, front-loaded sentence with no filler, redundant phrasing, or unnecessary detail. Every word contributes to conveying the tool's purpose.

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

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

For a parameterless read-only getter, the description is nearly complete: it identifies the resource and the user scope. Still, because there is no output schema, a slightly more explicit statement of the return value, such as 'returns a list of tenant objects available to the current user,' would remove the only remaining ambiguity.

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

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

The tool has zero parameters and the input schema fully documents this with 100% coverage, so there is nothing for the description to add. The baseline of 4 for a zero-parameter tool applies here because parameter semantics are trivially satisfied.

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

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

The description uses a specific verb ('Get') plus a clear resource ('available tenants') and a scope qualifier ('for the current user'), so an agent knows exactly what the tool returns. It is also distinguishable from sibling tools like baasix_switch_tenant and baasix_get_current_user, which involve tenant switching or user profile retrieval rather than listing tenants.

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

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

The phrase 'for the current user' implies this tool should be used to discover which tenants the authenticated user can access, and it is naturally used before a tool like baasix_switch_tenant. However, it does not explicitly state when to prefer it over alternatives, nor does it mention prerequisites such as being logged in.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, but 'Import schemas from JSON data' reveals only the input format. It does not state whether the import overwrites, merges, or validates existing schemas, whether it requires authentication, or what happens on conflict — significant gaps for a potentially 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.

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

The description is one front-loaded sentence with no wasted words: verb, resource, and input format in order. It is slightly under-specified for the complexity of an import operation, where one more sentence on behavior would earn its place, but as written it is efficiently sized.

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

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

For a tool with no annotations, no output schema, and a nested-object parameter, the description is too thin. It omits what happens to existing schemas on import, the expected JSON structure, and any link to baasix_export_schemas as the natural source of such payloads, leaving an agent unable to predict side effects or validate input.

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

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

Schema description coverage is 100% — the single schemas parameter is documented as 'Schema data to import' — so the baseline is 3. The description adds only a marginal hint that the payload is JSON; for an object parameter with nested structure, it does not elaborate the expected shape (map vs array, required schema fields), but the schema itself carries the parameter-level burden.

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

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

The description states a specific verb and resource ('Import schemas') with an input format ('from JSON data'), so an agent can tell this is a bulk-load operation rather than a per-schema create/update. However, it does not explicitly differentiate itself from siblings like baasix_create_schema or connect itself to its inverse baasix_export_schemas, leaving the distinction to inference from the tool name.

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

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

The description gives no guidance on when to choose this tool over alternatives such as baasix_create_schema, baasix_update_schema, or baasix_export_schemas. There is no statement of when not to use it, no mention of where the JSON payload should come from, and no reference to sibling tools.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies read-only listing but does not state pagination behavior, response format, result limits, or any side effects. The description adds minimal behavior beyond the name and schema.

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

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

The description is concise and front-loaded, with no wasted words. However, its brevity comes at the cost of operational detail, making it efficient but minimally informative.

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

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

There is no output schema, no annotations, and a nested filter object, so the description carries a heavy burden. It does not explain return values, pagination details, filter semantics, or how this differs from sibling file-related tools.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-specific detail beyond what the schema already provides; the 'optional filtering' phrase only reinforces the filter parameter without explaining its structure or accepted criteria.

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

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

The description states a specific verb ('List') and resource ('files'), and mentions metadata and optional filtering. It distinguishes from sibling file operations like delete_file and get_file_info, though it does not explicitly differentiate from other list-style tools.

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

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

There is no guidance on when to use this tool versus alternatives such as get_file_info or list_items. The phrase 'optional filtering' hints at usage but provides no context, prerequisites, or exclusion criteria.

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

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

With no annotations, the description carries the behavioral burden. It does so by documenting filter operator families, dynamic variables like $CURRENT_USER and $NOW, and concrete filter examples, which disclose how the query behaves beyond the schema. It does not mention auth, rate limits, or side effects, but the 'Query' framing makes the read-only nature reasonably clear.

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

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

The description is long, but it is densely structured with clear sections for operators, dynamic variables, and examples. Every section adds operational value, and the one-sentence summary is front-loaded, making the length appropriate for a tool with 11 parameters and complex query semantics.

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

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

For a tool with 11 parameters, no annotations, and no output schema, the description covers query construction well but omits the response shape, pagination metadata, and any explicit relationship to sibling sort behavior. An agent may invoke the tool correctly but lacks a complete picture of what the returned payload will look like.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds substantial meaning to the filter and relConditions parameters by enumerating operator groups, dynamic variables, and real filter examples. This goes well beyond the schema's terse parameter descriptions and directly helps an agent construct valid complex queries.

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

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

The description clearly states the operation ('Query items from a collection') and its major capabilities (filtering, sorting, pagination, relations, aggregation), so the purpose is obvious. It does not explicitly disambiguate from sibling tools like baasix_get_item or baasix_sort_items, though 'list_items' and the query framing imply the distinction.

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

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

The description gives clear context for when to use the tool: querying and listing items from a collection with complex filters, pagination, and relations. It does not provide explicit when-not-to-use guidance or name alternatives, but the rich filter/operator documentation makes the intended usage readily apparent.

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

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

No annotations are provided, so the description carries the full burden. It conveys that the operation is a read-style list scoped to the authenticated user, and does not claim any destructive behavior. However, it does not disclose details like whether listin notifications alters seen status, return structure, or any side effects.

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

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

The description is a single clear sentence with no filler. The core action and resource are front-loaded, 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.

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

For a simple listtool with three fully documented optional parameters and no required fields, the description provides the essential resource and scope. It lacks some optional context like default ordering or return shape, but the schema and the nature of the operation make the tool adequately callable.

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

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

The input schema already describes all three parameters with 100% coverage, including defaults. The description adds no additional parameter-level meaning beyond the auth scope, so it meets the baseline of 3 without exceeding it.

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

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

The description uses a specific verb ('List') and a clear resource ('notifications') scoped to the authenticated user. This distinguishes it from notification-related siblings like baasix_send_notification and baasix_ark_notification_seen, which involve different actions.

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

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

The phrase 'List notifications for the authenticated user' implies its basic use case, but it does not explicitly state when to choose it over alternatives, nor does it mention exclusions or context like pagination behavior. 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.

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention pagination behavior, default limits, sort semantics, or what the response structure looks like, even though the schema parameters suggest pagination and sorting exist.

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

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

The description is very short and front-loaded with the core purpose. It earns a high score for being concise, though it sacrifices useful behavioral context for brevity.

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

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

With no annotations, no output schema, a nested filter object, and multiple permission-related sibling tools, this description is too minimal to be fully actionable. The agent gets no information about return shape, filter syntax, pagination defaults, or how this tool differs from related read tools.

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

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

The schema covers all four parameters with descriptions, so the baseline is 3. The description adds no additional meaning beyond saying 'optional filtering', which weakly overlaps with the filter parameter but does not explain its structure or allowed values.

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

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

The description clearly states the verb and resource: 'list all permissions' with optional filtering. However, it does not differentiate this tool from the similarly named sibling 'baasix_get_permissions', which may be seen as overlapping in purpose.

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

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

There is no explicit guidance on when to use this tool versus alternatives like baasix_get_permissions or baasix_get_permission. The optional filtering capability is mentioned but not expanded with examples or context, leaving the agent to infer use cases.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. The verb 'List' clearly marks this as a read-only retrieval operation, and 'all available' signals no filtering. However, it does not mention return format, authentication requirements, or pagination behavior; for a zero-parameter list tool these are minor but present gaps.

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

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

The description is a single, front-loaded sentence with no filler. 'List all available roles' says exactly what the tool does and nothing more, making it an appropriately concise definition.

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

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

For a zero-parameter list tool with no nested objects and no output schema, the description is nearly complete. The verb 'List' and the phrase 'all available roles' sufficiently frame the call. The only minor omission is the exact shape of the returned role objects, but that is largely implicit for a list operation.

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

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

The tool takes zero parameters and the input schema shows an empty properties object with 100% coverage, so there is no parameter meaning for the description to add. The baseline for a zero-parameter tool is 4, and the description meets that baseline.

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

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

States the exact operation and resource: 'List all available roles.' The resource 'roles' is distinct from all sibling tools, so an agent can differentiate it from list_permissions, list_schemas, and other listing tools without opening schemas.

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

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

The description provides clear context: this is the tool to call when a complete listing of all available roles is needed. There are no role-specific sibling tools to contrast against, so explicit exclusions are unnecessary. It stops short of a full 5 because it doesn't explicitly mention any related alternatives.

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

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

No annotations are provided, so the description must carry the behavioral disclosure burden. The verb 'Get' implies a read-only operation, but the description does not explicitly state that it does not modify data, nor does it mention any access requirements or return-page behavior. The behavior is simple enough that the lack of explicit detail is not fatal.

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

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

The description is a single efficient sentence with no filler. It front-loads the core action and resource, then mentions the two noteworthy capabilities: search and pagination.

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

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

For a low-complexity listing tool, the description plus the fully documented input schema are nearly sufficient for an agent to invoke it correctly. The main gap is that there is no output schema and no explicit statement about what the returned paginated result looks like, but this is unlikely to block correct invocation for a simple list operation.

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

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

The input schema already provides complete descriptions for all four parameters (page, sort, limit, search), so the schema coverage is 100%. The description adds only the high-level notion of 'optional search and pagination' but no detail beyond what the schema already documents, so it stays at the baseline.

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

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

The description clearly states the verb ('Get') and resource ('all available collections/schemas in Baasix'), and mentions optional search and pagination. It does not explicitly name or distinguish sibling tools like baasix_get_schema, but the scope word 'all' makes the listing intent clear.

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

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

The phrase 'Get all available' implies this is the right tool for enumerating schemas or finding schemas via search, and pagination parameters signal handling large result sets. However, it never explicitly states when to use this tool instead of a single-schema tool like baasix_get_schema, leaving the routing decision to inference.

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

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

No annotations are provided, so the description carries full behavioral burden. 'List all' and 'filtering' indicate a read-style operation and scope, but it does not mention pagination behavior, return shape, or side-effect safety beyond what the tool name implies.

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

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

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

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

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

For a simple list tool, the schema covers all input parameters and the description conveys the essential purpose. However, without annotations or an output schema, and with no mention of pagination results or alternative single-template retrieval, the definition leaves some contextual gaps for an agent.

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

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

Schema description coverage is 100%, so the baseline is 3. The description only adds 'email templates' and 'optional filtering', while the schema already documents page, limit, and filter semantics with an example.

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

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

The description names a specific verb and resource: 'List all email templates'. It clearly distinguishes from single-template operations like baasix_get_template, and 'all' emphasizes the plural scoped behavior.

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

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

The description implies use for fetching template lists and mentions optional filtering, but it does not explicitly direct agents to alternatives such as baasix_get_template for retrieving a single template. The usage context is inferable but not stated.

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

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

With no annotations and no output schema, the description carries the full behavioral burden, but it only says 'login user' and gives no indication of whether a token, cookie, or session is returned, how authMode affects behavior, or what errors occur. This is a significant gap for an authentication operation.

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

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

The description is one short, front-loaded sentence with no filler words. It is concise, though perhaps too sparse to fully support a 4-parameter authentication tool.

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

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

Given no annotations, no output schema, and a large sibling set of auth-related tools, the description is not complete enough. It omits return behavior, session semantics, authMode differences, tenant handling, and any guidance on error or success outcomes.

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

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

The input schema already documents all four parameters with descriptions, so schema coverage is 100%. The description restates that email and password are used but adds no additional meaning about authMode, tenant_Id, defaults, or formatting.

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

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

The description clearly states the operation: 'Login user with email and password'. This is a specific verb and resource, and the credential method distinguishes it from auth siblings like register_user, send_magic_link, and logout.

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

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

The description implies this tool is for authenticating an existing user with email and password, but it does not explicitly state when to choose it over alternatives such as send_magic_link, register_user, or refresh_auth. No exclusions or alternative routing are provided.

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

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

No annotations are present, so the description carries the full behavioral burden. It discloses the core state change (logging out) but does not mention token invalidation, idempotency, whether an active session is required, or error behavior.

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

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

A single, front-loaded sentence with no wasted words. It states the action and scope immediately and is appropriately sized for a parameterless operation.

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

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

For a zero-parameter action the description is sufficient to know when and how to invoke it. However, with no annotations or output schema, it leaves return value and session-state side effects unstated, which is a noticeable gap.

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

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

The tool accepts zero parameters and the schema is empty, so there is no parameter meaning to add; the baseline of 4 applies. The phrase 'current user' clarifies the implicit scope of the operation.

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

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

Uses a specific verb ('Logout') with a clear resource ('the current user'), and the action is distinct from auth siblings like baasix_login, baasix_auth_status, and baasix_refresh_auth. It does not explicitly state what it is not, but the meaning is unambiguous.

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

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

Provides clear context: use this tool to end the current user's session. It does not name alternatives or exclusions, but the appropriate usage is obvious from the action and sibling context.

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

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

No annotations are provided, so the description carries the full burden of explaining behavior. It communicates that a state mutation occurs, but it does not disclose whether marking is idempotent, affects unread counts, requires specific permissions, or returns a result.

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

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

The description is a single efficient, verb-first sentence with no wasted words. It is appropriately sized for a one-parameter tool, though it provides no additional structural framing or context.

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

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

For a simple one-parameter tool, the description plus full schema coverage is minimally viable. However, with no annotations and no output schema, it leaves gaps around usage context, side effects, and expected result that an agent would benefit from knowing.

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

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

Schema coverage is 100%, so the schema already documents the only parameter 'id' as a Notification ID. The description adds no parameter-level meaning beyond that, 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.

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

The description clearly states a specific verb and resource: it marks a notification as seen. It is understandable and distinguishable from siblings like list_notifications and send_notification, though it mostly rephrases the tool name without adding extra scope or detail.

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

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

There is no guidance on when to use this tool, what precedes it, or how it relates to alternatives such as list_notifications or send_notification. The use case is only implied by the name and description, not explicitly laid out.

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

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

With no annotations, the description carries the full behavioral burden. 'Get list' signals a read-only retrieval and the description adds useful scoping, but it does not disclose authentication needs, edge-case behavior such as an empty result, or any other side effects or limitations.

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

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

The description is a single front-loaded sentence with no filler: the verb comes first, followed by the resource, the distinguishing filter, and the included data. Every word earns its place.

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

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

There is no output schema and no annotation coverage, so the description is the agent's only guide to what the tool returns. It names the main output concepts but leaves the shape of 'action configurations' and any list-level behavior unspecified, which is a moderate gap for an otherwise simple zero-parameter tool.

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

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

The tool has zero parameters and the schema coverage is effectively complete, so there is no parameter detail for the description to add. The description still reinforces the fixed scope of the result set: only collections with realtime enabled and their action configurations.

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

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

The description clearly states the operation ('Get list'), the resource ('collections'), the filter ('with realtime enabled'), and the included data ('their action configurations'). This distinguishes it from siblings like baasix_realtime_status and baasix_realtime_config, which concern realtime status or configuration rather than listing the collections themselves.

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

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

There is no explicit guidance about when to use this tool versus alternatives, no exclusions, and no mention of sibling tools. The use case is only implied by the description itself, so an agent must infer when this is the right call among the many related realtime and collection tools.

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

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

No annotations are provided, so the description carries the full burden. The verb 'Check' clearly signals a read-only diagnostic operation, and the return list explains exactly what configuration values will be reported. It does not mention permissions or failure modes, but for a zero-parameter read-only config check this is a minor gap.

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

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

The description opens with a one-sentence purpose and then provides a compact, scannable bullet list of return fields. Every line adds value with no repetition or filler.

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

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

For a zero-parameter inspection tool with no output schema, the description fully covers what an agent needs: the action, the expected walLevel, and the names and meanings of all returned config fields. No critical usage or interpretation information is missing.

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

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

The tool has zero parameters and the schema description coverage is effectively 100%, so no parameter-level guidance is needed. Instead, the description usefully documents the meaning of the returned fields, which compensates for the lack of an output schema.

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

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

The description states a specific action and resource: 'Check PostgreSQL replication configuration for WAL-based realtime.' The bulleted return fields make the purpose concrete and distinguish it from sibling realtime tools like baasix_realtime_enable or baasix_realtime_status, which are about enabling or checking status rather than inspecting replication configuration.

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

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

The description implies use as a diagnostic before or during realtime setup, especially with 'Should be logical for realtime to work,' but it never explicitly says when to use this tool versus alternatives such as baasix_realtime_status or baasix_realtime_enable. The usage guidance is inferable, not stated.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only states the basic action. It does not mention whether disabling realtime is reversible, whether existing realtime subscribers are affected, whether configuration is removed or paused, or what the response/outcome looks like. This is a notable gap for a state-changing tool.

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

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

The description is a single clear sentence with no filler, and the action is front-loaded. It is appropriately concise for a one-parameter operation, though it could have been stronger by including missing usage and side-effect context.

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

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

For a low-complexity tool with one fully documented required parameter, the description and schema are syntactically sufficient for an agent to invoke the tool correctly. However, the absence of annotations and output schema leaves operational context and impact behavior unstated, so completeness is adequate but not strong.

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

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

Schema description coverage is 100%, and the collection parameter is already described as 'Collection name to disable realtime for.' The description adds no additional parameter meaning beyond what the schema provides, so the baseline 3 is appropriate.

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

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

The description uses a specific verb ('Disable') and a clear target ('realtime for a collection'), which immediately identifies the operation. It also distinguishes itself from sibling tools such as baasix_realtime_enable and baasix_realtime_status by making the opposite action explicit.

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

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

There is no guidance about when to use this tool versus baasix_realtime_enable or other realtime-related tools, and no prerequisites or conditions are mentioned. The only usage signal comes from the sibling tool names, so the description itself offers no when/when-not advice.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose that the config is stored in the schema definition and that broadcasts happen via WebSocket, which is useful. However, it does not mention idempotency, overwrite behavior, permissions, reversibility, or what happens to existing realtime configuration when this tool is called.

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

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

The description is compact: three sentences with the core action front-loaded and no filler. The second and third sentences earn their place by explaining the broadcast effect and where the configuration is stored.

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

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

For a simple enable operation with fully described parameters, this is adequate. It is missing an expected return/output description and any explicit relation to sibling realtime tools, which matters more because there is no output schema and no annotations to fill those gaps.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's mention of 'specific actions to broadcast' loosely maps to the actions parameter, but it adds little beyond the schema's own descriptions and does not clarify replicaIdentityFull beyond what the schema already states.

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

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

States a specific action and resource — 'Enable realtime for a collection' — and adds a concrete observable effect: changes are broadcast via WebSocket when data is modified. It is clearly distinct from siblings like baasix_realtime_disable and baasix_realtime_status, 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.

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

The intended use is implied by the verb 'Enable', but the description gives no explicit when-to-use guidance, no prerequisites, and no comparison to related tools such as baasix_realtime_config or baasix_realtime_disable. An agent must infer the correct context from the tool name and schema.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states that the tool 'returns information about' a set of status details, implying a read-only operation with no side effects. However, it does not explicitly disclose whether the status is fetched live, requires authentication, or could fail under certain replication states. The described behavior is adequate but not deeply transparent.

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

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

The description is compact and well-structured: an opening sentence states the primary purpose, followed by a focused bullet list of exactly what is returned. Every bullet adds meaningful detail, and there is no filler or redundant phrasing. It is appropriately sized for a no-parameter status tool.

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

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

For a zero-parameter read-only status tool with no output schema, the description provides a sufficiently complete picture of the returned information by enumerating the major categories. It does not specify the exact response format or data types, but the bullet list gives an agent enough context to understand what the tool offers. Slight additional detail about response shape would make it fully complete.

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

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

The tool has zero parameters, and the input schema reflects that perfectly with an empty properties object. There is no parameter meaning for the description to add, so the baseline of 4 applies. The description appropriately focuses on return values rather than input semantics.

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

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

The description clearly identifies the tool as retrieving realtime service status with specific bullet points about WAL configuration, replication slots, publications, and enabled collections. The verb 'Get' and resource 'status of the realtime service' are specific. It does not explicitly distinguish from sibling tools like baasix_realtime_config or baasix_realtime_collections, but the status-focused phrasing is largely unambiguous.

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

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

The description provides no guidance about when to use this tool versus alternatives such as baasix_realtime_config, baasix_realtime_collections, or baasix_realtime_enable/disable. There are no exclusions, preconditions, or contextual hints beyond the inference that a user wants status information. This leaves the agent to determine the appropriate selection on its own.

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

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

With no annotations, the description carries the burden, and it does reveal that the tool forces a token refresh and supports only email/password auth. It does not disclose side effects such as invalidation of the existing token, failure modes, or whether a new token is returned, which would be useful for a mutation-like auth operation.

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

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

The description is a single front-loaded sentence with no filler. Every word adds information: the action, the target, and the auth-method constraint.

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

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

For a zero-parameter tool this is mostly adequate: it states the operation and constraint. But without an output schema or annotations, an agent is left guessing about the return value and side effects, and there is no mention of when to choose this over the sibling auth tools.

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

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

The tool has zero parameters and schema description coverage is 100%, so there are no parameter semantics for the description to add. Per the baseline for zero-parameter tools, this is appropriately handled.

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

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

The description identifies a specific operation ('Force refresh') on a specific resource ('authentication token'), and adds the constraint that it only works for email/password auth. It is clear about what the tool does, though it does not explicitly distinguish itself from sibling auth tools such as baasix_login or baasix_auth_status.

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

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

The 'only works for email/password auth' clause gives an implicit exclusion for other auth methods. However, it does not state when an agent should refresh instead of logging in, checking status, or getting the current user, so guidance is implied rather than explicit.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Register a new user' only restates the core operation and adds no context about side effects, authentication behavior, invite token handling, tenant requirements, or response format. This is insufficient for a mutation tool with no annotation safety signals.

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

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

The description is very brief and front-loaded, but it is under-specified rather than concisely informative. For a tool with 8 parameters, nested objects, and no annotations, a single sentence simply restating the action does not provide enough structure or context to guide an agent.

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

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

Given the tool's complexity—8 parameters, a nested tenant object, inviteToken, authMode, no output schema, and no annotations—the description is severely incomplete. It does not explain when registration succeeds, what happens after registration, how multi-tenant mode affects the call, or how invite tokens fit in. An agent cannot confidently invoke this tool based solely on the description and schema.

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

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

Schema description coverage is 100%, so every parameter already has a description in the schema. The tool description adds no additional meaning about how parameters interact, such as the relationship between inviteToken and registration or between authMode and the response. Per the baseline, a 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.

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

The description uses a specific verb and resource: 'Register a new user.' It clearly identifies the operation and differentiates it from login, send invite, and verify invite. However, it does not explicitly contrast itself with those siblings or state its exact scope, so it falls just short of a 5.

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

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

The description gives no guidance on when to use this tool versus alternatives like baasix_login, baasix_send_invite, or baasix_verify_invite. It also does not mention scenarios such as invite-based registration, tenant setup, or authMode selection. There is no exclusion or alternative routing.

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

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

There are no annotations, so the description alone must disclose side effects, required privileges, and whether this invalidates or rebuilds the cache. It only states the action and says nothing about consequences, idempotency, authentication requirements, or impact on other sessions. This is a significant gap for an administrative action.

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

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

The description is a single, front-loaded sentence with no filler. It is as compact as the tool's low parameter complexity allows.

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

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

Despite low signature complexity, there is no output schema and no annotations, and the description does not say what a successful reload looks like or when it should be used. For a state-affecting administrative action, a one-phrase description is not fully complete.

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

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

The input schema has zero parameters and schema description coverage is 100%, so there is nothing the description needs to add about parameters. The zero-parameter baseline of 4 applies here.

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

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

The description names a specific action (reload) and a specific resource (the permission cache), which distinguishes it from permission CRUD siblings like list_permissions or update_permissions. It is not merely a restatement of the name because it clarifies the target is the cache rather than the permission records themselves.

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

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

No guidance is provided for when to use this tool versus alternatives. With siblings such as update_permissions, refresh_auth, and get_permissions, an agent has no way to know that this should be called after permission changes or when stale cache is suspected. 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.

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It communicates a destructive action via 'Remove', but does not mention persistence, irreversibility, schema-wide effects, permissions, or error behavior.

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

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

The description is a single concise sentence with no filler. The primary action and object are front-loaded.

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

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

For a simple two-parameter destructive operation with complete schema coverage, the description is adequate. However, because there is no output schema and no annotations, a bit more detail on effects or implications would improve completeness.

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

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

Schema description coverage is 100%, so parameters are already fully documented. The description adds minimal semantic context by mapping 'index' and 'collection schema' to the parameters, but does not go beyond the schema.

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

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

The description states a clear action ('Remove') and a clear resource ('an index from a collection schema'). It is semantically distinct from sibling baasix_add_index, though it does not explicitly name the sibling.

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

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

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no explicit exclusions. The description only restates the action, 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.

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

With no annotations, the description carries the full burden of disclosing side effects, permissions, or email-sending behavior. 'Send an invitation to a user' reveals nothing about whether an email is dispatched, whether an invite record is created, or whether it is idempotent.

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

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

The description is a single, front-loaded sentence with no filler or redundant wording. Every word contributes to stating the core action.

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

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

This is a mutation tool with no annotations and no output schema, yet the description does not explain what the call returns, what side effects occur, or how the invite links to verification or registration. Schema covers parameter semantics, but the larger operation context is missing.

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

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

Schema description coverage is 100%, and each parameter (link, email, role_Id, tenant_Id) already has a clear description in the schema. The tool description adds no parameter-level meaning, but the high schema coverage meets the baseline.

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

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

The description clearly states the verb 'Send' and the resource 'an invitation to a user', so the basic action is understandable. However, it does not differentiate this tool from siblings like baasix_send_magic_link or baasix_verify_invite, both of which can be invitation-related.

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

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

No guidance is provided on when to use this tool versus alternatives such as send_magic_link, register_user, or verify_invite. The description only states the action and offers no exclusions, prerequisites, or contextual cues.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only states the action 'Send' without explaining side effects, whether a code can be returned in the response, whether an existing user is required, or any rate-limit/expiration behavior. This is a meaningful gap for a side-effecting authentication tool.

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

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

The description is a single efficient sentence with no wasted words. It is appropriately short for a simple operation, though it sacrifices useful behavioral context for brevity.

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

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

For a tool with no output schema and no annotations, the description is incomplete. It does not clarify what happens after sending, whether the code is returned to the caller or only emailed, or whether there are preconditions like an existing user. An agent would need to guess at the expected outcome.

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

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

Schema description coverage is 100%, so the schema already documents all parameters clearly. The description adds a slight semantic tie between 'link or code' and the mode parameter, but does not materially enrich the parameter meaning beyond the schema.

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

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

The description uses a specific verb ('Send') plus a concrete resource ('magic link or code') and states the purpose ('for authentication'). It is clear enough to distinguish from most sibling tools, though it does not explicitly differentiate itself from baasix_send_invite.

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

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

No guidance is given about when to use this tool versus alternatives such as baasix_login, baasix_register_user, or baasix_send_invite. The intended triggering condition and prerequisites are left entirely to inference.

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

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

No annotations are provided, so the description carries the full behavioral burden. It merely states the action and does not disclose whether notifications are persisted, whether delivery is synchronous, what side effects occur, 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.

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

The description is a single concise sentence with no filler. It is easy to parse, though it sacrifices useful context for brevity.

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

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

Given no annotations, no output schema, and related sibling tools in the notification domain, the description is too sparse. It does not explain what happens after sending, how to verify delivery, or how this differs from sending invites/magic links.

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

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

Schema description coverage is 100%, so the parameters are already documented in the schema. The description adds no extra meaning beyond the schema, which matches the baseline of 3.

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

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

The description uses a specific verb ('Send') and resource ('notification') and names the recipients. It is clear on its own, though it does not explicitly differentiate from sibling tools like baasix_send_invite or baasix_send_magic_link; the word 'notification' provides partial distinction.

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

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

No guidance is given about when to use this tool versus alternatives such as baasix_send_invite, baasix_send_magic_link, or baasix_list_notifications. There are no exclusions, prerequisites, or selection criteria.

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

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

With no annotations, the description must carry the burden of behavioral disclosure. The verb 'Get' communicates read-only intent, which is valuable, but the description does not state whether authentication is required, what 'health status' covers, or that the operation is side-effect free. It provides partial transparency only.

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

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

The description is a single, front-loaded sentence with no filler. Every word adds meaning, and the structure is optimally concise.

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

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

Despite being simple, the description would be more complete if it outlined the expected response fields (e.g., version, uptime, db status) and any auth prerequisites. Since no output schema exists, the agent is left guessing at the return shape. That said, for a 0-parameter health probe it is barely sufficient.

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

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

The tool has zero parameters, so there is nothing to document. The baseline of 4 applies, and the description adds no parameter semantics, which is acceptable since no inputs exist.

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

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

The description names a specific verb ('Get') and resource ('Baasix server information and health status'), making the tool's function immediately recognizable. It is clear, though it does not explicitly differentiate itself from sibling status tools like baasix_auth_status or baasix_realtime_status, so an agent must infer the distinction.

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

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

No guidance is given about when to choose this tool over alternatives such as baasix_auth_status or baasix_realtime_status. The purpose phrase implies use for server-level health checks, but there are no explicit exclusions or alternative recommendations. This is adequate for such a simple tool, but relies on inference.

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

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

There are no annotations, so the description carries the full burden. It discloses only the core move/sort behavior and does not state whether the reorder is permanent, whether permissions are required, how other items are affected, or what the response/error behavior looks like. For a mutating tool this is a significant gap.

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

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 and adds a helpful clarifying parenthetical. There is no wasted text.

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

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

The schema covers all required parameters, but the description does not clarify how 'after' should be achieved given that the 'to' parameter only mentions 'move before.' It also lacks return/error behavior and mutation effects. For a simple three-parameter tool, this is adequate but has clear gaps.

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

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

Schema description coverage is 100%, so the baseline applies. The description adds only the general 'before/after' relationship between item and to, without providing additional format, constraint, or behavioral detail beyond the schema. The 'after' behavior is not represented by any parameter.

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

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

The description states a specific verb and resource: 'Sort items within a collection,' and clarifies the mechanism with 'move item before/after another.' This clearly distinguishes it from sibling tools like add_index or item CRUD operations.

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

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

The phrase 'Sort items within a collection' implies when it should be used, but there is no explicit guidance on when to prefer this over alternatives or when not to use it. It does not name sibling tools or exclusions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. 'Switch' weakly implies a state change, but the description does not disclose whether the switch affects subsequent operations, whether authentication is required, what happens on an invalid tenant ID, or whether the change persists. For a context-mutating operation, this is a significant gap.

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

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

A single, front-loaded sentence with no wasted words. The size is appropriate for a one-parameter tool, though it could have packed in a pointer to get_user_tenants or a note on side effects without becoming bloated.

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

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

Although the parameter surface is minimal, this is a stateful context-switching operation with no annotations and no output schema, so the description must carry more weight. It fails to explain where valid tenant IDs come from (get_user_tenants), what 'tenant context' affects, or what a successful or failed switch looks like. An agent lacks enough information to call it confidently.

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

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

Schema description coverage is 100%, so the schema already documents tenant_Id as 'Tenant ID to switch to.' The description adds no additional meaning about the parameter—such as its format (e.g., UUID), where to obtain it, or constraints. Baseline 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.

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

The description states a specific verb ('switch') and resource ('tenant context'), and the intent is clear: change the active tenant for subsequent operations. It is not a tautology and is distinguishable from sibling tenant-related tools like get_user_tenants or login, though it does not explicitly name what it is not.

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

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

No guidance is given about when to use this tool versus alternatives. It does not mention that get_user_tenants should be consulted first to discover valid tenant IDs, nor does it explain that this tool changes the context for later calls. An agent is left to infer the invocation pattern entirely.

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

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

With no annotations, the description must carry the full behavioral burden. It discloses that the operation mutates an existing item, but does not explain whether 'data' is a partial update or a full replacement, what happens if the item is missing, authorization requirements, or any side effects. This is too thin for a write operation.

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

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

The description is a single clear sentence with no filler or repetition. It is front-loaded and easy to parse, though it is so minimal that it leaves behavioral and usage gaps for other dimensions.

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

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

For a mutation tool with three required parameters, no annotations, and no output schema, the description is incomplete. It does not convey merge/replace semantics, return behavior, error conditions, or the need for a previously fetched item. An agent could guess the arguments but lacks key context for correct invocation.

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

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

Schema description coverage is 100%, so each parameter already has a basic description. The tool description adds no meaning beyond the schema—it does not clarify the expected shape of nested 'data' or how it relates to the collection. This is acceptable but not additive.

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

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

The description clearly names the action ('Update') and the resource ('an existing item in a collection'), which distinguishes it from create/get/list/delete item tools. However, it does not explicitly differentiate it from sibling update tools or state the intended scope beyond the obvious.

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

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

There is no guidance on when to use this tool versus alternatives like baasix_create_item or baasix_update_template. It only states the basic action and implies the item must already exist, but provides no exclusions, prerequisites, or routing hints.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates this is a mutant operation, but it does not explain whether fields are partially updated or fully replaced, what happens to omitted fields, what permissions are required, or what side effects may occur.

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

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

The description is a single concise sentence with no wasted words. It is efficient and front-loaded, though it sacrifices useful detail for brevity.

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

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

For a tool with 8 parameters, no output schema, no annotations, and a close sibling named update_permissions, this description is not complete enough. It does not tell the agent about update semantics, the contents of nested objects, or how to distinguish this tool from similar permission-related tools.

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

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

Schema description coverage is 100%, so the schema already documents all eight parameters. The description adds no additional parameter 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.

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

The description clearly states a specific verb and resource: 'Update an existing permission.' It is easy to understand what the tool does, but it does not distinguish this singular tool from its sibling 'baasix_update_permissions,' which could update multiple permissions.

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

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

There is no guidance about when to use this tool versus alternatives like create_permission, delete_permission, or the plural update_permissions. The description gives no context for when this should be preferred, no prerequisites, and no exclusions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only restates the operation as 'Update permissions for a role.' It does not explain whether the permissions object replaces existing permissions, merges with them, or requires the role to already exist, nor does it mention any 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.

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 contains no filler, though it is perhaps too terse to fully support correct invocation.

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

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

For a mutating tool with no annotations and no output schema, this description is incomplete. It does not clarify the shape of the nested permissions object, whether the update is additive or destructive, or how the result is reported, making it difficult for an agent to invoke confidently.

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

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

Schema description coverage is 100%, so the schema already documents both parameters by name. However, the parameter descriptions are minimal ('Role name' and 'Permissions object'), and the main description adds no additional meaning about the expected structure or format of the permissions object.

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

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

The description uses a specific verb ('Update') and a clear resource ('permissions for a role'), making the basic operation understandable. However, it does not explicitly distinguish this from sibling tools like baasix_update_permission, baasix_create_permission, or baasix_reload_permissions, leaving some ambiguity about the exact scope.

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

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

The description provides no guidance on when to use this tool versus alternatives such as create_permission, update_permission, or reload_permissions. There are no stated prerequisites, exclusions, or context signals to help an agent decide between the many permission-related sibling tools.

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

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

With no annotations, the description must disclose behavioral traits, but it only repeats the verb 'update' that is already in the tool name. It does not state whether the operation is destructive, whether updateData replaces or merges existing values, what side effects occur, or what the response indicates. This is effectively a placeholder for behavioral disclosure.

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

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

The description is a single short sentence with no redundancy, but the brevity is under-specification rather than effective conciseness. It front-loads the action but provides no information about parameters, behavior, or outcomes, so the sentence does not help an agent correctly construct a tool invocation.

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

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

The tool has three required parameters including a nested object, no output schema, and no annotations, yet the description explains almost nothing about how to invoke it. An agent cannot determine the expected structure of updateData, how sourceCollection and fieldName locate the relationship, what errors may occur, or what a successful update returns. This definition is below the minimum viable level of completeness.

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

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

Schema description coverage is 100%, so the baseline is 3 even though the description itself adds no parameter meaning. The descriptions in the schema are minimal—'Update data for the relationship' is self-referential—but the rule credits the schema for parameter documentation. The tool description does not clarify how sourceCollection and fieldName identify the relationship or what shape updateData should take.

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

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

The description is essentially a paraphrase of the tool name—'Update an existing relationship' restates baasix_update_relationship without adding meaningful specification. It does not define what a 'relationship' is, which fields can be updated, or how the update is applied. The qualifier 'existing' offers only minimal differentiation from create/delete siblings.

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

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

The description gives no guidance on when to use this tool versus baasix_create_relationship or baasix_delete_relationship, nor any prerequisites or conditions. The word 'existing' implicitly suggests it is not for creating relationships, but no explicit when-to-use or when-not-to-use context is provided.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Update an existing collection schema' conveys only that this is a mutation operation, with no mention of whether it replaces or merges the schema, whether data is affected, whether validation occurs, or what the consequences are.

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

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

The description is a single concise sentence with no redundancy. It is front-loaded and easy to parse, though its brevity contributes to missing behavioral and usage context.

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

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

For a mutation tool with no annotations and no output schema, this description is incomplete. It does not explain update behavior, potential destructive impact on data, whether the new schema fully replaces the old one, or any prerequisites beyond the two parameters.

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