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

No annotations are provided, so the description carries the behavioral burden. It clearly states what the tool does (adds a Milvus connection) and what becomes available (ctx.MILVUS), but it does not disclose side effects such as whether an existing ctx.MILVUS is overwritten, whether the endpoint must already exist, or any additional configuration or permission requirements.

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

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

Two short sentences deliver the core purpose and the resulting context variable. Every word earns its place, and the key information is front-loaded.

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

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

For a single-parameter tool, the description is largely adequate, but it omits important operational context: whether the endpoint must already exist, how connection credentials are supplied, and whether calling this tool is idempotent or replaces an existing Milvus connection. Given the sibling context includes action_new and auth_setup, those prerequisites should have been mentioned.

Complex tools with many parameters or behaviors need more documentation. 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 for the only parameter `endpoint`, including format and examples. The description adds no extra parameter-level detail, but with full schema coverage this is acceptable 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 uses a specific action ('Add') with a concrete resource ('Milvus vector DB connection') and a clear target ('to an endpoint's context'). It also names the resulting context variable ('Provides ctx.MILVUS'), making it easy to distinguish from the sibling action_add_* 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?

The description implies usage through the name and target: use this when you need to attach a Milvus vector DB to an endpoint's context. However, it does not explicitly contrast with sibling tools like action_add_postgresql or action_add_redis, nor does it state any prerequisites such as the endpoint already existing.

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

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

No annotations are provided, so the description must carry the full burden of disclosing side effects. Beyond stating that it 'adds' a connection and exposes two context variables, it omits whether the operation is idempotent, what happens if a connection already exists, whether authentication or secrets are required, or any error conditions. For a state-changing tool, this is a significant transparency gap.

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

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

Two short, purposeful sentences without any filler. The primary action is stated first, and the concrete outcome (the ctx variables) follows immediately. Every word earns its place, and the structure makes the tool's function immediately scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 is minimal but still incomplete. It doesn't explain how the MongoDB connection is established (e.g., connecting string, secret reference), whether any setup or special permissions are needed, or what the returned result looks like. Given the sibling tools for other databases, an agent might not know if additional configuration (like a secret) is required beforehand.

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

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

The schema already documents the endpoint parameter thoroughly with a pattern and example, achieving 100% coverage. The description adds no further parameter detail, which is acceptable given the schema's completeness, but it also doesn't reinforce the format or relationship between the endpoint and the MongoDB connection. Baseline 3 is appropriate.

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

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

The description clearly states a specific verb ('Add') and a specific resource ('MongoDB connection'), and it names the concrete effect ('Provides ctx.MONGODB_CLIENT and ctx.MONGODB'). This distinguishes it unambiguously from sibling tools like action_add_postgresql or action_add_s3, which handle other resource types.

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

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

The description implies usage context (use this when you need a MongoDB connection in an endpoint's context) but does not explicitly state when to avoid it or mention alternatives. It doesn't discuss prerequisites such as whether a secret must exist or whether the endpoint must already be created, which would help an agent decide between this and the secret-related tools nearby.

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 that a connection is added and that ctx.POSTGRESQL becomes available, but it does not disclose whether this is idempotent, whether it replaces an existing PostgreSQL connection, whether it creates persistent configuration, or whether any permissions or prerequisites are needed.

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

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

The description is two short sentences with no filler. The core action is front-loaded, and the added context of 'Provides ctx.POSTGRESQL' is direct and useful.

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

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

The tool is simple with a single well-documented parameter and no output schema, so the description covers the basic purpose and effect. However, it omits important context such as whether the connection is persistent, whether existing PostgreSQL connections are replaced, and whether any post-condition behavior beyond providing ctx.POSTGRESQL should be expected.

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

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

The schema already documents the only parameter 'endpoint' with a precise pattern, required status, and an example, giving 100% schema description coverage. The description adds no additional parameter semantics, but none are needed given the schema's thoroughness.

Input schemas describe structure but not intent. Descriptions should explain 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 ('Add'), a clear resource ('PostgreSQL connection'), and a target ('endpoint's context'), plus the resulting effect ('Provides ctx.POSTGRESQL'). This clearly differentiates it from sibling tools like action_add_milvus, action_add_s3, action_add_redis, and action_add_mongodb.

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

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

The description implies when to use the tool: when you need to add a PostgreSQL connection to an endpoint's context. However, it does not explicitly state when not to use it or mention alternatives, so the agent must infer the choice based on the tool name and the 'ctx.POSTGRESQL' effect.

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 disclosure burden. It states that this is a mutating operation ('Add Redis to one endpoint'), names the exact context bindings created, and discloses security-relevant design details: opaque random tokens, server-side storage, prefix-safe keys, bounded TTL, and no JWT or signing secret. It does not mention edge cases like overwriting existing Redis bindings, but the core behavioral profile is 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?

Three sentences carry distinct, valuable information: what the tool does, when to use it vs auth_setup, and how the underlying authentication tokens work. There is no filler, and the primary action 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?

For a simple single-parameter tool with no output schema, the description is sufficiently complete: it explains the effect, the relevant usage constraints, and the security model. It could add return-value or idempotency details, but these are non-critical for selecting and invoking the tool correctly.

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

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

Schema description coverage is 100%, and the endpoint parameter already has a precise format description. The tool description adds conceptual context about ctx.REDIS and ctx.REDIS_PREFIX but does not need to explain the endpoint syntax further. Baseline 3 is appropriate because 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 opens with a specific verb and resource: 'Add Redis to one endpoint as ctx.REDIS and ctx.REDIS_PREFIX.' This clearly distinguishes it from sibling actions like action_add_s3 or action_add_postgresql by naming the target binding and 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 explicitly tells the agent when to avoid this tool for authenticated pages and to 'use auth_setup to configure the complete set atomically.' It also clarifies the per-endpoint purpose of action_add_redis, giving concrete routing guidance between the two 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 provided, the description carries the full burden. It discloses the side effect (adding a connection and providing ctx variables) and adds a clear behavioral contract: never call list_buckets, and verify read/write via put_object/get_object with content comparison and delete_object in ctx.S3_DATA. This goes well beyond the schema, though it omits any mention of auth requirements or reversibility.

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

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

Two sentences, both substantive. The first states purpose and resulting context variables; the second provides critical safety and verification guidance. No filler, no repetition of schema content, and the most important constraints 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 single-parameter setup-style tool with no output schema and no annotations, the description is remarkably complete. It explains what the tool does, what state it creates, and how to verify the connection works. The only missing information, such as return value or auth prerequisites, is mitigated by the explicit verification procedure.

Complex tools with many parameters or behaviors need more documentation. 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, endpoint, already has 100% schema description coverage with a regex, rule about segments, and an example. The description adds the context that the endpoint is the target of the S3 connection, but it does not need to repeat the schema details. Baseline 3 is appropriate given the schema already documents the parameter fully.

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

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

The description names a specific verb and resource: 'Add a bucket-scoped S3 connection to an endpoint's context.' It also lists the concrete context variables provided (ctx.S3_CLIENT, ctx.S3_DATA, ctx.S3_WEB, ctx.S3_PUBLIC), which makes the tool's function concrete and distinguishes it from sibling tools like action_add_milvus or action_add_postgresql.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 context for use is clear: it is for adding an S3 connection to an endpoint. However, the description does not explicitly say when to choose this tool over alternatives or when not to use it. The 'Never call list_buckets; verify read/write...' guidance is operational, not tool-selection guidance, so it only partially covers this dimension.

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 must disclose behavioral traits. It states that the secret must exist in .env, which is a useful prerequisite, but it does not describe side effects (e.g., whether the secret replaces an existing one, whether the operation is reversible), any authentication requirements, or the response format. For a mutating operation, this is minimal 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 conveys the core purpose and a key precondition. There is no extraneous information, and the structure is clear and efficient.

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

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

The tool is simple with two parameters and a well-documented schema, but the description omits usage context such as when to prefer this over secret_bind, and behavioral details like side effects or error conditions. Although the prerequisite is helpful, the overall guidance is minimal for an agent to call it correctly in all situations.

Complex tools with many parameters or behaviors need more documentation. 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 describes both parameters well. The description adds a prerequisite (must exist in .env) which is an environmental constraint rather than parameter semantics. It does not further explain the meaning of 'secret' or 'endpoint' beyond what the schema provides, so it meets the baseline for high schema coverage.

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

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

The description clearly states the action: 'Add a secret to an endpoint's context.' It specifies the verb (add), the resource (secret), and the target (endpoint's context). It distinguishes itself from sibling tools like action_add_s3 or action_add_redis which add different resources, and from secret_bind/unbind which likely operate on bindings. The prerequisite about .env also adds specificity.

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

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

There is no explicit guidance on when to use this tool versus alternatives such as secret_bind or secret_unbind. The description only states a precondition (secret must exist in .env) but does not explain scenarios or indicate when not to use it. With several secret-related siblings, the lack of decision-making guidance leaves the agent to infer the appropriate context.

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

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 the tool executes `ops invoke` and returns JSON, without noting that invoking an action may have side effects, require permissions, or fail in non-obvious ways.

Agents need to know what a tool does to the 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 sentence front-loads the action and return type, then names the command being executed. There is no filler or redundant restatement of schema fields.

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

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

For a simple two-parameter tool with full schema coverage, the mechanics are sufficiently described. However, invoking an API action is potentially side-effecting, and the description gives no guidance on when it is safe or appropriate, leaving a meaningful gap.

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

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

Schema coverage is 100%, and the schema already documents both endpoint and params, including an example for the key=value format. The description adds no new semantic detail beyond restating 'endpoint and key=value parameters'.

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

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

States a specific verb ('Invoke') and resource ('an API action'), and names the underlying `ops invoke` mechanism. The action_* siblings are creation/add/setup tools, so invoke is clearly distinct.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 executing an existing API action, but it never explicitly says when to use it versus creating/adding actions. No alternatives or exclusions are mentioned, so the agent must infer context from sibling names.

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 reveal a concrete filesystem effect (creating a folder with __main__.py and a module file), which is useful. However, it does not describe whether the operation is destructive, whether it fails if the endpoint already exists, or what permissions/setup are required beyond the schema parameters.

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

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

The description is two short sentences with no filler. The primary purpose is front-loaded in the first sentence, and the second sentence adds a precise implementation detail about what is created. Every sentence earns its place.

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

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

For a simple scaffold tool with a rich input schema covering both parameters, the description plus schema is largely sufficient to invoke the tool correctly. It could be improved by noting the relationship to sibling tools and any failure behavior if the endpoint already exists, but these are not essential for the basic intended usage.

Complex tools with many parameters or behaviors need more documentation. 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 fully documents both 'endpoint' and 'public' with patterns, types, defaults, and examples. The description adds no additional parameter-level meaning, so the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource: 'Create a new API endpoint' and names exactly what is produced ('action folder with __main__.py and module file'). This clearly differentiates from sibling tools that add resources to existing actions (e.g., action_add_milvus), since the focus is on creating the initial endpoint scaffold.

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

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

No explicit guidance is given about when to use this tool versus alternatives. The description does not mention that action_add_* tools are for extending an existing action, nor does it state any prerequisites or conditions that would route an agent to action_invoke or auth_setup. Usage must be inferred entirely 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It adds one useful side-effect: 'Skips if the library is preinstalled.' However, it does not describe other effects such as whether the requirements file is appended in place, whether existing entries are replaced, or what happens when the endpoint is invalid or 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 two short sentences with no filler. The core action is front-loaded and the preinstalled-skip exception is a meaningful behavioral note that earns its place.

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

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

For a simple two-parameter mutation tool with no output schema or annotations, this is minimally viable: it states the purpose and one important side-effect. Still, it leaves gaps around prerequisites, failure behavior, and what a successful call returns or changes beyond the requirements.txt update.

Complex tools with many parameters or behaviors need more documentation. 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 clearly. The description only reuses the word 'library' and adds no additional format, relationship, or edge-case semantics beyond what the schema 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 states a specific verb ('Add') and resource ('library to an endpoint's requirements.txt'), making the tool's purpose immediately clear. This also distinguishes it from sibling tools that add services or secrets rather than Python libraries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 usage is implied: use this tool when you need to add a library to an endpoint's requirements.txt. However, the description provides no explicit when-to-use or when-not-to-use guidance, no alternatives, and no prerequisites such as whether the endpoint must already exist.

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

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

With no annotations, the description carries the full burden and delivers substantial detail: atomic application, .env non-interference, bcrypt password verification, random opaque tokens, prefix-safe Redis keys, bounded TTL, Redis-derived identity, and logout deletion. It does not fully specify file-level side effects or idempotency, but the critical behavioral traits are well covered.

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

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

The description is information-dense with no filler and is front-loaded with its purpose and scope. It is somewhat long, but every sentence contributes a meaningful constraint or 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?

Given the complexity of the operation and the absence of an output schema and annotations, this description is unusually complete: it defines all three endpoint categories required by the schema, states security requirements, and clarifies what the tool will and will not do. Minor gaps such as prerequisites and error/return behavior prevent a 5.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by mapping token_endpoints to issuers, protected_endpoints to validators/me/session, and logout_endpoints to revocation, while also explaining the token storage and TTL semantics.

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

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

The description opens with a specific verb ('add'), resource ('Redis session wiring'), and scope ('complete authentication surface'), explicitly naming token issuers, token validators, and logout. This clearly distinguishes it from sibling infrastructure tools like action_add_redis and action_add_secret by focusing on authentication wiring and forbidding JWT/app signing secrets.

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

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

It gives clear context for when the tool applies: it wires Redis sessions across login/registration, protected endpoints, and logout, and never touches .env. It does not explicitly name alternative sibling tools or state 'use this tool instead of X', so it falls just short of a 5.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the atomicity (all-or-nothing) and the fact that it operates on an existing secret, creating a ctx.<SECRET> binding. However, it does not mention what happens if the secret doesn't exist, whether existing bindings are overwritten, or any permission requirements. These are important side-effect details for a mutation tool.

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

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

The description is a single, well-structured sentence with no waste. It front-loads the key action ('Atomically bind') and packs in all essential context: the secret is existing, multiple endpoints, and the resulting binding name. 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?

For a two-parameter tool with no output schema and no annotations, the description covers the core operation well. It explains the atomicity, the source (existing secret), the target (multiple endpoints), and the naming convention. Missing details like failure handling or overwrite behavior are minor given the tool's simplicity and the strong schema coverage.

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

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

Schema coverage is 100%, so both parameters are documented in place. The description adds semantic value by clarifying that 'secret' refers to an existing .env secret and that 'endpoints' receive the secret as ctx.<SECRET>. This goes beyond the schema's syntactic descriptions, helping an agent understand the domain meaning.

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

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

The description states a specific verb ('bind'), a specific object ('one existing .env secret'), a target ('multiple OpenServerless endpoints'), and the resulting representation ('as ctx.<SECRET>'). It clearly distinguishes from sibling tools like secret_unbind and action_add_secret by focusing on the atomic binding action.

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

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

The description implies usage: you have an existing secret and want to attach it to multiple endpoints. However, it doesn't explicitly mention when not to use it or contrast it with alternatives like action_add_secret or secret_unbind. For an agent, the 'existing' qualifier hints at prerequisites, but no explicit routing guidance is given.

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 behavioral disclosure burden. It explicitly states that the tool does not read or return the secret's value, which is a significant safety-related behavior. The verb 'Report' also implies a read-only operation, though it could more explicitly state that no bindings are modified.

Agents need to know what a tool does to the 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, information-dense sentence with no redundant words. It front-loads the primary action ('Report whether a secret exists and is bound') and then adds the key limitation ('without reading or returning its value'). Every part earns its place.

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

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

For a simple check tool with fully documented parameters, the description covers the essential behavior and the most important constraint. It lacks an explicit mention of what the response shape is, especially when 'endpoints' is omitted, but 'Report whether' sufficiently implies a status or boolean-style result.

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

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

Schema description coverage is 100%, so the input schema fully documents the 'secret' and 'endpoints' parameters, including format rules for endpoints. The description adds only minor conceptual context ('selected endpoints') beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('Report') and resource ('whether a secret exists and is bound to selected endpoints'), clearly distinguishing it from sibling mutation tools like secret_bind, secret_unbind, and action_add_secret. It also adds the important scope limit 'without reading or returning its value', which tells an agent exactly what the tool is and is not for.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 a use case—checking secret existence and binding status—but gives no explicit guidance on when to choose this tool over secret_bind, secret_unbind, or action_add_secret, nor any exclusions or prerequisites. An agent is left to infer the appropriate context from sibling names rather than being told.

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 reveals two meaningful traits: the operation is atomic, and it does not delete the underlying secret value. This goes beyond the schema by informing the agent about side effects and transactional guarantees. It could be richer (e.g., error behavior or what happens if no binding exists), but for a two-parameter tool the disclosure is solid.

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

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

The description is a single, well-structured sentence that front-loads the verb and object, then adds the atomicity and safety qualifiers. Every word earns its place, with no filler or redundant restatement.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 tool with a detailed schema and no output schema, the description covers the essential behavioral context: what is removed, from where, atomically, and what is preserved. It does not describe return values or error conditions, but these are not critical for correct invocation 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?

Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-specific guidance beyond the schema; it merely restates the general operation. The schema already documents 'secret' as the bound parameter name and lists valid endpoint formats, so no significant semantic gap exists.

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

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

The description uses a specific verb ('remove') and resource ('generated secret binding'), and defines the exact scope: multiple OpenServerless endpoints. It also includes a key qualifier, 'without deleting the secret value', which clearly distinguishes unbinding from secret deletion. This is unambiguous even without consulting the schema.

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

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

The description implies its use case: when a secret binding must be removed from endpoints while keeping the secret value intact. However, it does not explicitly state when to prefer this over sibling tools like secret_bind or secret_status, nor does it mention any exclusions or prerequisites. Clear context is present, but no explicit when-to-use or alternative guidance.

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