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

No annotations are present, so the description carries the full burden of behavioral disclosure. It only restates the mutation ('create') and does not explain persistence behavior, default status, required permissions, validation rules, or the response. This is insufficient 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, efficient sentence with no filler and the verb front-loaded. It is appropriately brief for a straightforward create operation, though it is so sparse that it sacrifices useful guidance.

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

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

For a create operation with 6 parameters, 4 required fields, enum constraints, no output schema, and no annotations, a one-line description is inadequate. The agent lacks information about required field semantics, type combinations, status default behavior, or what the create call returns.

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

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

Schema description coverage is 0%, so the description must compensate by explaining parameter meanings; it names none. Required parameters like resourceId, type, startDate, and endDate are left entirely to the schema. The description adds no semantic value beyond the parameter names already present in the schema.

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

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

The description states a clear verb and resource: 'Create a new absence.' It also distinguishes itself from sibling tools like boond_absences_search, boond_absences_get, and boond_absences_update via the create operation. It lacks additional scoping details, but the purpose is unambiguous.

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

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

Usage is only implied by the tool name and the imperative 'Create'; there is no explicit guidance about when to use this over alternatives or any prerequisites. The intended use case—creating a new absence—is reasonably inferable, but no conditions or exclusions are provided.

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

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

With no annotations, the description carries the full burden. 'Get' clearly implies a read-only operation, which is accurate, but it does not disclose what happens if the ID is not found, whether there are rate limits, or what the response format is. For a simple getter, this is adequate but not rich.

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

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

The description is a single, tight sentence with no filler. It front-loads the action and scope 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 get-by-ID tool, the description fails to mention what is returned (e.g., the absence object) and does not address error cases. With no output schema and no annotations, the agent is left without essential details about the expected response, making the description incomplete for a tool this simple.

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 has one parameter 'id' with zero description coverage. The tool description adds only 'by ID', which does not elaborate on the ID's format, source, or any constraints beyond the schema's minLength. Since schema coverage is 0%, the description should compensate but does not provide meaningful added information.

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

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

The description 'Get an absence by ID' clearly states a specific verb and resource, and the ID parameter anchors it as a single-record retrieval. It is distinguishable from its search sibling by the explicit 'by ID' scope, though it does not name the 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?

No guidance is provided on when to use this tool versus the search alternative (boond_absences_search). The description does not mention that one would typically search first to obtain the ID, nor does it state any exclusions or prerequisites. This leaves 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?

No annotations are provided, so the description must carry the behavioral burden. 'Search' implies a read-only operation, but the description does not explicitly confirm this, nor does it disclose pagination behavior, default return size, or how filters combine. It also does not mention whether an empty filter set returns all absences or requires at least one criterion.

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 action and the key filter dimensions. It contains no fluff and is appropriately sized for a simple search operation, though it sacrifices 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?

With 7 optional parameters, no annotations, and no output schema, the description is too sparse. It does not explain the response format, pagination, or the effect of combining multiple filters. An agent would not know if a search without filters returns all absences or requires at least one filter, nor what fields are returned. This is insufficient for a tool with this many options.

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

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

Schema description coverage is 0%, so the description must compensate. It names the filter categories (resource, date range, status, type) that map to resourceId, startDate/endDate, status, and type, but it does not explain parameter formats (e.g., date-time syntax), default values, or the meaning of each enum. The description adds minimal value beyond the schema property names.

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 verb ('search') and a resource ('absences') and enumerates the filter dimensions (resource, date range, status, type). It distinguishes from other _search tools by the resource type, but it does not explicitly differentiate from boond_absences_get (which likely retrieves a single absence) or from other search tools with similar patterns.

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 vs. alternatives. It does not state that this is the primary way to list absences, nor does it mention when to prefer boond_absences_get for a single record. The context implies a list/search purpose, but the description offers no explicit conditions or exclusions.

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

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 merely says 'Update an existing absence.' It does not state whether the update is partial, whether it modifies all fields or only provided ones, what validations apply, who can perform it, or what response to expect.

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 extremely short and front-loaded, which is structurally clean, but it is under-specified for a tool with 7 parameters and no annotations. Conciseness is achieved at the expense of essential information.

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

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

Given 7 parameters, no output schema, no annotations, and 0% schema description coverage, the description is far too sparse. An agent has no idea what fields are updatable, what the required id means contextually, or what happens after the call succeeds.

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

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

Schema description coverage is 0%, and the description adds zero meaning to any of the 7 parameters. It neither maps simple parameters to intent nor clarifies nuanced fields like status or type beyond what the schema enums already show.

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 action ('Update') and the resource ('an existing absence'), and the word 'existing' distinguishes it from create, search, or get operations for absences. It is concise and unambiguous, though it does not enumerate what aspects of the absence can be updated.

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 siblings like boond_absences_create, boond_absences_search, or boond_absences_get. It implies the absence must already exist but gives no prerequisites, workflow context, 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Create a new account' implies a write operation, but it does not state whether the account is immediately active, whether email verification is required, whether duplicate usernames/emails are rejected, or what the response contains. The description adds no behavioral context beyond the obvious 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?

The description is extremely short and front-loaded, which is good for conciseness, but it is under-specified. A single sentence with no additional context is not a well-structured description; it is merely a label. It earns a 3 because it is not verbose, but it fails to provide useful structure or 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 tool has 4 parameters, 3 required, no output schema, and no annotations, the description is incomplete. An agent needs to know what an 'account' is in this domain, what the required fields mean, and what happens after creation. The description provides none of this, making it inadequate 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 0%, so the description must compensate for the schema's lack of parameter documentation. The description does not mention any parameters, leaving the agent to infer that username, email, role, and status are the relevant fields. The schema provides enums for role and status, but the description adds no meaning about how these fields interact or which are required beyond the schema's required list.

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 'Create a new account' states a clear verb and resource, but it does not distinguish this tool from the many other create tools in the sibling list, nor does it clarify what kind of 'account' is being created (e.g., user account, login account, client account). It is minimally clear but lacks specificity.

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

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

No guidance is provided on when to use this tool versus alternatives. The sibling list includes boond_accounts_search, boond_accounts_get, and boond_accounts_update, but the description does not mention them or any conditions for choosing this create tool. The agent must infer usage from the name alone.

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

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 says 'Get an account by ID' which implies a read-only operation, but it does not mention side effects, error behavior, authorization requirements, or return format. This is minimal and leaves too much to inference.

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 extremely concise and front-loaded, containing six words with no fluff. It states the core action and scope immediately, which is ideal for quick agent parsing.

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 tool with one parameter, this is minimally adequate. However, there is no output schema or description of the return value, and the description does not address potential errors (e.g., not found) or response shape. Given the lack of annotations, a bit more context would improve completeness.

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

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

Schema description coverage is 0%, so the description must compensate for the undocumented 'id' parameter. It adds 'by ID', which is nearly redundant with the schema property name and the tool name. It does not clarify what type of ID, whether it is a path or query parameter, or any format constraints beyond the schema's minLength.

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 ('Get an account') and clarifies the scope ('by ID'), which distinguishes it from the sibling search tools like boond_accounts_search. However, it does not explicitly differentiate from boond_banking_accounts_get, and the word 'account' could be ambiguous in this context.

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

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 boond_accounts_search for listing or boond_accounts_get when you have an ID. The description simply states the action without providing contextual selection criteria or exclusions.

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

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. 'Search' implies a read-only operation, but the description does not disclose pagination behavior, result scope, authentication needs, or what data is returned. This is a significant gap for an unannotated 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 brief and contains no wasted words or repetition. It front-loads the core action and resource. However, it is so short that it sacrifices substantive guidance, so it is not a perfect conciseness score.

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 three undocumented parameters, no annotations, and no output schema, the description is incomplete. An agent would not know what criteria are supported, how pagination works, what a successful response looks like, or how this search differs from sibling searches.

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

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

Schema description coverage is 0%, so the description must compensate. It hints that the 'query' parameter accepts a username or criteria, but it does not explain query syntax, how 'criteria' are expressed, or what 'page' and 'limit' control. Two of the three parameters are effectively undocumented.

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

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

The description states a specific action ('search') and resource ('accounts'), and adds a concrete searchable field ('username'). It is clear enough, but 'criteria' is vague and it does not distinguish this from sibling search tools or from boond_accounts_get beyond the verb.

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 boond_accounts_get, boond_accounts_create, or the many other _search tools. There is no mention of prerequisites, typical use cases, or when a different tool would be more appropriate.

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 exist, so the description carries the full burden of behavioral disclosure. 'Update' implies mutation, but the description does not state whether this is a partial or full update, what happens to unspecified fields, whether re-authentication is needed, or any side effects. This is a significant gap 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, front-loaded sentence with no filler or repetition. It is concise and easy to parse, though the brevity sacrifices informative content. No structural issues.

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 five parameters, no output schema, and no annotations, this one-sentence description is severely under-specified. An agent cannot know which parameters are intended to be updated together, whether all fields are optional besides id, the effect on the account, or the expected response. This is grossly inadequate for safe invocation.

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

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

Schema description coverage is 0%, and the description adds no parameter information at all. The schema itself provides field names and enums, but the description does not clarify semantics like whether 'status' and 'role' are limited to the enum values, whether 'id' must identify an existing account, or if updating one field preserves others. The description fails to compensate for the schema's lack of textual guidance.

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 and resource: 'Update an existing account.' It distinguishes the operation (update vs. search/get/create) and names the resource, which is sufficient to identify what the tool does. However, it doesn't mention which fields are updatable or any specifics beyond the generic verb-resource pairing.

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 boond_accounts_create or boond_accounts_get. No conditions, prerequisites, or exclusions are provided. The agent must infer usage solely from the name and sibling list.

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

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 disclosing behavioral traits. It only says 'Create a new action,' which conveys a mutating create operation but not side effects, permissions, required context, or what happens on success or failure. There is no contradiction with annotations because none 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. It is front-loaded and appropriately sized for a straightforward create tool, 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 create tool with complete schema coverage, the description is minimally viable: it names the operation and resource, and the schema covers invocation. However, with no annotations and no output schema, there is no information about the returned object, error behavior, or any business-specific constraints tied to creating an action.

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 seven parameters with 100% coverage, so the description does not need to repeat them. The description adds no additional parameter-level meaning beyond what the schema provides, which matches 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 uses a specific verb and resource: 'Create a new action.' This identifies the operation and distinguishes it from sibling create tools for other resources like candidates, contracts, or invoices. It does not explain what an 'action' represents in the domain, so it stops short of a 5.

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

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

The verb 'Create' and the resource 'action' imply this tool is for creating a new action, and the schema reinforces that only 'name' is required. However, there is no explicit guidance about when to use this over boond_actions_update, boond_actions_search, or how this create differs from other resource creates.

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 an action' only restates the operation and does not disclose that deletion is permanent/irreversible, what consequences may occur, or whether special authorization is required.

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

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

The description is three words, front-loads the verb, and contains no filler or redundant phrasing. It earns its place, though the resulting lack of detail is captured in 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 destructive one-parameter tool with no annotations and no output schema, the description is too thin. It omits the irreversible nature of the delete, any response behavior, and confirmation/caution guidance, leaving an agent without enough context about consequences before invoking.

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 fully documents the sole 'id' parameter with minLength and 'Action ID', so the description adds no additional parameter meaning. Since schema coverage is 100%, the baseline of 3 applies despite the description being minimal.

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 ('Delete') and resource ('action'), and the destructive verb distinguishes it from sibling tools like boond_actions_create, update, get, and search. However, it is nearly a direct restatement of the tool name and adds no clarifying detail about scope or 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?

No guidance is provided about when to use this tool vs alternatives, whether the action must already exist, or any caveats about deletion. The intended use case is only implied by the verb 'delete', and no exclusions or prerequisites are mentioned.

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

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

With no annotations provided, the description must carry the full burden of behavioral disclosure. It only states 'Get', implying a read operation, but does not specify whether it returns the full object, handles missing IDs, or requires special permissions. This leaves significant uncertainty for a tool with zero annotation coverage.

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

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

The description is a single short sentence, which is concise but lacks structure. It is not tautological and does state the core operation, but it does not front-load any additional context or provide a logical flow. It is minimally adequate for a simple getter.

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

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

There is no output schema, so the description should explain what the tool returns. It does not mention the response shape, potential errors, or side effects. For a simple read tool, this is a notable gap; an agent cannot fully predict the outcome without additional knowledge.

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 the sole parameter 'id' with 100% coverage. The description adds no extra meaning about the parameter, such as format constraints or usage nuances. Since schema coverage is high, baseline 3 is appropriate; the description neither compensates nor detracts.

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

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

The description 'Get an action by ID' clearly states a verb (Get), a resource (an action), and the key identifier (ID). It distinguishes from siblings like boond_actions_search, create, update, and delete by specifying a direct fetch operation. However, it does not elaborate on what an action is or what the response contains, slightly limiting clarity.

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 like boond_actions_search. There is no mention of scenarios (e.g., when you already have the ID) or exclusions (e.g., use search when filtering). The agent must infer usage from the name alone.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only implies a read-only search operation but does not mention pagination behavior, result limits, how 'query' interacts with the filters, or what is returned. The schema supplies defaults (page=1, limit=20) but the description adds no behavioral context beyond the word 'Search'.

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 maximally concise—four words, front-loaded, with no wasted phrasing. However, the brevity borders on under-specification for a 6-parameter tool, trading informativeness for compactness.

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 6 parameters, no annotations, no output schema, and a large sibling family, the description is incomplete. It does not explain what results look like, how filters combine with query, or how this search relates to boond_actions_get/create/update/delete, so an agent has insufficient context 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 all six parameters (page, limit, query, status, priority, projectId) are already documented in the schema. The description's 'by criteria' vaguely alludes to the filter parameters but adds no meaning beyond what the schema already provides, which lands 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 states a clear verb ('Search') and resource ('actions'), so an agent can identify this as the action-search tool among many search siblings without opening the schema. However, 'by criteria' is generic and adds no specificity about what distinguishes this search from the other *_search tools beyond the resource name.

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

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

No guidance is given on when to use this tool versus alternatives like boond_actions_get (fetch a single action) or the other search tools. There are no prerequisites, exclusions, or conditions 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 provided, the description carries the full burden of behavioral disclosure. It only says 'update,' which implies mutation but reveals nothing about partial vs. full updates, permission requirements, idempotency, or side effects. This is a significant gap for a tool with no annotation safety hints.

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 only four words and is front-loaded, but it is too terse for a tool of this complexity. It omits essential information such as whether fields are optional, how the update behaves, and what response to expect. It is under-specified rather than genuinely concise.

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

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

For a tool with seven parameters, no annotations, and no output schema, the description is severely incomplete. It provides no usage context, no behavioral details, and no information about return values. An agent would have to rely entirely on the schema and naming conventions, leaving too much room for incorrect 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 coverage is 100%, so all seven parameters are documented in the schema. The description adds no information about parameters, which is acceptable given the high coverage, landing at the baseline score 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 states a specific verb ('update') and a clear resource ('action'), which distinguishes it from sibling tools like create, get, search, and delete. It is concise and unambiguous, though it adds no extra scope or nuance beyond the basic 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?

No guidance is provided on when to use this tool versus alternatives. There is no mention of requiring an existing ID, differences from create/delete, or any prerequisites. The agent must infer that this is for modifying an existing action, which is implicit but not explicitly stated.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. 'Create a new agency' only states the basic action; it does not disclose potential side effects, permission requirements, irreversibility, or data validation behavior. This is a significant gap 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, clear sentence with no wasted words. It is front-loaded and compact, earning its place by stating the core purpose. However, it is perhaps too sparse, as it sacrifices helpful 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?

Given the lack of annotations and output schema, the description does not adequately prepare the agent to use the tool correctly. It does not explain required parameters (e.g., 'name' is mandatory), expected return values, or error handling. The tool is relatively simple, but the description still leaves many contextual gaps.

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

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

Schema description coverage is 0%, and the description adds no information about the parameters (name, city, address, country). It does not compensate for the missing schema documentation, leaving the agent to infer parameter meaning solely from names. This is insufficient for correct invocation.

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 'Create a new agency' clearly identifies the action (create) and the resource (agency), distinguishing it from sibling tools like boond_agencies_search, get, and update. However, it does not provide any additional scoping or special meaning beyond the tool name, so it lacks the specificity that would warrant 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 provided on when to use this tool versus alternatives. The description does not mention that this is for inserting a new agency rather than updating an existing one, nor does it reference sibling tools for different operations. Usage must be inferred entirely from the tool name.

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

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

No annotations are provided, so the description carries full behavioral burden. 'Get an agency by ID' communicates read-only intent, which is useful, but it omits any detail about not-found behavior, authorization requirements, response shape, or potential side effects.

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

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

The description is a single concise sentence with no wasted words or repetition. The key scoping detail ('by ID') is present and 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 read-by-ID tool with one required parameter and no output schema, this description is largely complete for invocation. It lacks error-handling and return-value details, but those are less critical for a straightforward fetch 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 0%, but the description explicitly maps 'by ID' to the single required id parameter, adding meaning beyond the bare schema. For a one-parameter get tool, this is sufficient compensation for the missing schema descriptions.

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 resource ('an agency') and uniquely identifies the operation by ID, making it clear this is a single-record fetch rather than a search or mutation. This distinguishes it from sibling tools like boond_agencies_search, boond_agencies_create, and boond_agencies_update.

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 the alternatives. It is only implicitly clear that it should be used when you already have an agency ID, but no explicit alternatives, exclusions, or contextual triggers 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?

There are no annotations, and the description does not disclose pagination behavior, query matching semantics, result shape, or any side effects. It does not contradict annotations, but the description leaves all behavioral disclosure to the schema.

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

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

The description is a single front-loaded sentence with no filler. It is concise, though this brevity comes at the cost of necessary 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?

With no annotations, no output schema, and 0% schema description coverage, the agent has almost no information about return values, filtering semantics, or pagination behavior. A one-line description is insufficient for a search tool with three parameters and no structured guidance elsewhere.

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

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

Schema coverage is 0%, and the description only hints that 'query' matches by name or criteria. The page and limit parameters are left entirely unexplained beyond their schema types/defaults.

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 the action ('search') and resource ('agencies'), making the tool's basic purpose clear and distinguishing it from sibling tools for other resources. However, 'by name or criteria' is vague about what criteria are supported.

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 for when to use this search rather than boond_agencies_get or the create/update tools. The word 'search' implies list/filter usage, but no explicit usage context or exclusions are provided.

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

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

No annotations are present, so the description carries the full burden. It only says 'Update an existing agency' and does not disclose whether this is a partial or full update, what fields are overwritten, whether the operation is reversible, or what response to expect. 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 front-loaded sentence with no fluff or repetition. It is efficient, though arguably under-specified for the behavioral information an agent needs.

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 operation mutates data and there are no annotations or output schema, the description is incomplete. It does not explain update semantics, side effects, or any prerequisites. For a low-complexity flat schema this is still a notable omission.

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

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

Schema description coverage is 0%, so the description must compensate, but it provides no parameter-level meaning. The field names (id, city, name, address, country) are self-explanatory, yet the description does not clarify which fields are updated, whether they are optional, or how the id selects the target agency.

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 verb ('Update') and a resource ('an existing agency'), and the word 'existing' weakly distinguishes it from the create tool. However, it adds little beyond the tool name and does not differentiate from the broader CRUD family beyond the update 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?

No guidance is given for when to use this tool versus boond_agencies_create, boond_agencies_search, or boond_agencies_get. The phrase 'existing' implies use on already-created agencies, but there are no explicit conditions, exclusions, or alternative recommendations.

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

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 operation implied by the tool name and gives no information about not-found behavior, errors, response shape, or whether the operation is read-only beyond the word 'Get'.

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 five words long, front-loaded, and free of redundant text. It is efficient for a simple retrieval operation, though it stops just short of including helpful context such as what is returned.

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 get operation, the description is minimally usable: an agent knows to pass an alert ID. However, with no annotations and no output schema, it leaves gaps around response contents and failure behavior, which a slightly fuller description could easily address.

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 only defines id as a required string with minLength 1 and no description. The phrase 'by ID' reinforces that the parameter is the alert identifier, which adds a little meaning, but it does not specify the ID format, source, or any additional constraints.

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

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

The description states a specific action ('Get') and resource ('an alert') and includes 'by ID', which distinguishes it from search-style siblings without explicitly naming them. It is clear and unambiguous about the operation's goal.

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 instead of boond_alerts_search or boond_alerts_update, and no mention of prerequisites or exclusions. The only implicit cue is that the caller has an alert ID, but that is not stated as a usage rule.

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 reveals only that the tool performs a search, and omits important behavioral traits such as pagination behavior, result ordering, query syntax, or whether the operation is read-only. It is not misleading, but it adds almost no behavioral insight 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 extremely short and contains no waste, but this is under-specification rather than effective conciseness. It provides only a single high-level sentence and offers no structured or progressive detail 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 three parameters with no schema descriptions, no annotations, and no output schema, the description is insufficient for reliable invocation. It does not explain query format, supported criteria, pagination defaults, or what the search returns. The description needs substantially more context to be complete.

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

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

Schema description coverage is 0%, and the description does not compensate. The phrase 'by criteria' vaguely points toward the query parameter but does not explain what kind of query string is expected, how page and limit operate, or how they relate to the search. The description adds essentially no meaning beyond the raw schema.

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

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

The description states a specific verb ('Search') and a specific resource ('alerts'), which is enough to identify the core operation and distinguish it from boond_alerts_get and boond_alerts_update. However, 'by criteria' is vague and does not specify what criteria are supported or how they are expressed.

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 about when to use this tool versus alternatives. It does not mention boond_alerts_get for retrieving a single alert, nor does it clarify whether this tool is appropriate for all alert searches. The intended use is only implied by the generic phrase 'Search alerts by 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?

No annotations are provided, so the description carries full responsibility for disclosing behavioral traits. It states that the tool updates status and mentions 'resolved,' but it does not explain side effects, whether the resolved flag can be set to false, authentication/authorization requirements, idempotency, or the shape of the response. For a mutation tool with zero annotation coverage, 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, front-loaded sentence with no filler. It is concise and immediately states the tool's action, though it omits needed 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 that the tool has two parameters, no output schema, and no annotations, the description is under-specified. An agent cannot tell what the tool returns, what happens if resolved is omitted, or whether the operation is reversible. The description is adequate only for the narrowest interpretation of marking an alert resolved.

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

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

With 0% schema description coverage, the description must compensate. It clarifies that 'resolved' relates to the alert status and suggests the typical use case of marking as resolved, but it does not explain the full semantics of the boolean (e.g., false meaning un-resolved) or the id parameter. This is partial compensation.

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 'Update' and identifies the resource as 'alert status,' with the parenthetical 'mark as resolved' clarifying the intended operation. This clearly distinguishes it from sibling tools like boond_alerts_search and boond_alerts_get, which are read operations, and from update tools on other resources.

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 statement about when to use this tool versus alternatives, nor any exclusions. The purpose is implied by the name and description, but no guidance is given about prerequisites (e.g., fetching the alert first) or when not to use it.

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

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It only restates the operation as a read/get without mentioning side effects, error behavior, authentication requirements, rate limits, or return format. Minimal value beyond the tool name itself.

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 phrase with zero wasted words. Every word ('Get', 'an app', 'by ID') earns its place and directly conveys the core 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 simple one-parameter getter with no output schema, the description covers the essential invocation correctly. However, it lacks any context on what an 'app' is, how the ID is obtained, what the response contains, or when to choose this over other retrieval tools. Adequate for the simplest case but with clear gaps.

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

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

Schema has 0% description coverage, so the description must compensate for the lone 'id' parameter. Saying 'by ID' provides only a weak link between the parameter and its role as an app identifier, but no format, source, or validation details are given beyond the schema's minLength constraint.

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

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

The description states a specific verb ('Get') and resource ('an app'), with the parameter scope 'by ID'. It clearly distinguishes this tool from siblings like boond_apps_search, boond_apps_install, and boond_apps_uninstall without needing to open 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?

No guidance is given on when to use this tool versus the many sibling tools, particularly boond_apps_search. The agent is left to infer that 'get by ID' is for retrieving a single known app, while search is for finding apps, but the description does not state this.

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 disclosure burden. 'Install an app by ID' conveys a mutating action but does not mention side effects, reversibility, permissions, idempotency, or behavior when the app is already installed.

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 wasted words. It is appropriately concise for a simple tool, even though it sacrifices behavioral and usage 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?

With no annotations, output schema, or parameter documentation, the description is too sparse for an agent to invoke the tool with full confidence. It omits prerequisites, expected outcomes, and the relationship to sibling search/get/uninstall tools, which is a significant gap for a mutating 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 0%, and the description only adds that the `id` parameter is an app identifier. It does not explain the ID format, where to obtain it, or whether it refers to an app catalog ID versus an installation instance ID, so the added meaning is minimal.

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 ('Install') and resource ('app'), and the qualifier 'by ID' specifies the selection mechanism. This clearly distinguishes it from sibling tools such as boond_apps_uninstall, boond_apps_get, and boond_apps_search.

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, such as whether an app must first be found via search/get, or how install differs from uninstall. No 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?

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does not state that the operation is read-only, whether it supports pagination (despite page/limit parameters), what the response structure is, or any search syntax/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 very short and front-loaded, but 'or criteria' is vague and the brevity comes at the cost of essential usage detail. It is not verbose, but it is under-specified for reliable tool selection and 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 tool with three parameters, no output schema, and no annotations, the description is materially incomplete. It leaves the agent without enough information to construct a correct search call, interpret results, or choose between this and sibling search tools.

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

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

Schema description coverage is 0%, and the description adds minimal meaning beyond the schema. It implies 'name or criteria' relates to the query parameter but does not explain how query works, how page/limit behave, or what 'criteria' includes, leaving the agent to guess.

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

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

The description states a clear verb ('Search') and resource ('apps'), and mentions the searchable basis ('name or criteria'). It distinguishes from get/install/uninstall operations on apps, though 'criteria' is somewhat vague and does not explicitly differentiate from every other resource-specific search 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?

No guidance is provided about when to use this tool versus alternatives such as boond_apps_get or other resource searches. It does not mention intended use cases, prerequisites, 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?

No annotations are present, so the description carries the full burden of behavioral disclosure. It only states the action itself and does not reveal that uninstalling is likely destructive, irreversible, or may have side effects on associated data.

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

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

The description is a single sentence with no wasted words. It front-loads the action and the target, making it easy to scan.

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

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

For a destructive operation with no annotations and no output schema, the description is too sparse. An agent gets no information about side effects, permissions, idempotency, or what happens after a successful uninstall.

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 has 0% description coverage, and the description only says 'by ID', which largely restates the required 'id' property. It does not explain what kind of ID is expected, where to find it, or any format requirements beyond the schema's minimal string type.

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 ('Uninstall'), a clear resource ('an app'), and the identifying mechanism ('by ID'). This clearly distinguishes it from sibling tools like apps_install, apps_get, and apps_search.

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 it should be used to reverse an installation, nor does it contrast with apps_install or explain prerequisites or consequences.

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 must carry the behavioral burden. 'Get' conveys a read-only single-record retrieval, but there is no disclosure of errors, permissions, or response behavior, and no output schema compensates.

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 six words with no filler; the action and resource are front-loaded. It is as concise as the tool's simplicity 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?

For a simple one-parameter fetch this is minimally adequate, but the absence of annotations, output schema, and any routing to boond_banking_accounts_search leaves the agent without guidance on return shape, error cases, or how to discover a valid ID.

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

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

Schema description coverage is 0%, so the description must compensate. 'By ID' maps directly to the single required `id` parameter and confirms it is the account identifier, but it adds no format, source, or lookup-detail beyond the schema's property name.

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 ('Get') and resource ('banking account'), with the lookup criterion 'by ID'. It clearly identifies what this tool returns, though it does not explicitly contrast itself with the sibling boond_banking_accounts_search.

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 'by ID' phrasing implies this tool is for fetching one known banking account rather than running a search, but it never names boond_banking_accounts_search as the alternative or states when to choose it. Usage context is only implicit.

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. 'Search' implies a read-only operation, but pagination, filtering, ordering, and return format are not mentioned. This is a significant gap for a search 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 extremely concise, front-loaded, and contains no filler. It is more under-specified than verbose, but as a concise statement it is appropriately short.

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 search with no output schema, the description provides minimal context but leaves out expected result shape and behavioral details. Given the ambiguity with sibling tools and lack of annotations, the description is not complete enough for confident 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?

The tool has zero parameters, so the empty schema is fully documented and the description adds no parameter semantics. Since there are no parameters to explain, the baseline score of 4 applies.

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

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

The description states a clear verb ('Search') and resource ('banking accounts'), forming an understandable action-target pair. However, it is vague about what 'search' entails and does not distinguish this from sibling tools like boond_accounts_search or boond_banking_accounts_get. The purpose is recognizable but under-specified.

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 boond_banking_accounts_get or boond_banking_transactions_search. There are no exclusions, prerequisites, or context cues. The agent must infer usage entirely from the tool name and minimal description.

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

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

With no annotations, the description must disclose behavior. 'Search' implies a read-only operation but is not explicit about side effects, authentication, pagination behavior, or response format. The description adds minimal transparency beyond the 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 a single short sentence, which is efficient, but it is under-specified rather than truly concise. It does not front-load critical information like required parameters or usage context, so while it has no fluff, it lacks substance.

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 search tool with four parameters and no output schema, this description is severely incomplete. It does not explain what constitutes a valid search, how pagination works, what the query parameter filters, or what the response contains. An agent cannot reliably call this tool correctly based on the description alone.

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

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

Schema coverage is 0% – the description does not explain any of the four parameters. It only hints at accountId via 'for a specific account', leaving page, limit, and query completely undocumented. The description fails to compensate for the missing schema details.

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 tool searches banking transactions and requires a specific account, distinguishing it from account-level tools like banking_accounts_get. However, it doesn't specify what 'search' entails (e.g., filtering, sorting) or explicitly name alternatives, so it's clear but not fully differentiated.

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

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

The description implies the need for an accountId but gives no guidance on when to use this vs other banking tools, how to combine with account search, or the purpose of the query, page, and limit parameters. 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 provided, so the description carries the full burden of behavioral disclosure. It only states the action 'Create' without detailing side effects, permissions, return values, or the implications of setting parentId or managerId. For a mutation tool, 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, concise sentence that front-loads the core purpose. It contains no fluff, but it is extremely minimal—arguably under-specified. However, it is appropriately sized for stating the action, so it earns a 4.

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

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

The tool has 3 parameters and no output schema, yet the description does not address any of them or the expected response. It is completely inadequate for an agent to understand how to invoke the tool correctly, including what inputs are required or optional.

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

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

Schema description coverage is 0%, and the description does not explain any of the parameters (name, parentId, managerId). It adds no meaning beyond the raw schema, leaving the agent without guidance on what these fields represent or how they are used.

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 'Create' and the resource 'business unit', which distinguishes it from sibling tools like boond_businessunits_get, _update, and _search. It is unambiguous about the action and target.

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. It does not mention any prerequisites, context, or exclusions. The user must infer that creation is intended for new entities, but there is no explicit direction.

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 the action ('get') but does not explicitly say it is a read-only operation, what the response contains, or how errors (e.g., not found) are handled. It is not misleading, but it provides minimal information about the tool's behavior beyond the basic action.

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

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

The description is a single short sentence, 'Get a business unit by ID', which is direct, front-loaded, and free of unnecessary words. It conveys the essential information efficiently 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?

The tool is simple: one parameter, no output schema, no nested objects. The description is minimally sufficient for an agent to understand the basic function, but it does not mention what the response contains or any edge cases. For such a low-complexity tool, this is barely adequate; a fuller description could state that it returns the business unit details or mention potential errors.

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 documents 'id' as a required string with minLength 1, and the description references it as 'by ID'. This adds a small amount of semantic value by connecting the parameter to the lookup purpose, but it does not provide examples, format details, or explanation of what the ID refers to. Given the simplicity of the single parameter, the schema already covers most of the meaning, so a baseline score of 3 is appropriate.

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

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

The description states a specific verb ('Get') and resource ('business unit') with a clear lookup key ('by ID'). It is not a tautology and is distinguishable from sibling tools like boond_businessunits_search, which implies listing, and boond_businessunits_create/update, which imply mutation. It lacks elaboration on what a business unit is, but that is not essential for a get-by-ID 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?

The description provides no guidance on when to use this tool versus alternatives such as boond_businessunits_search (for listing) or boond_businessunits_update (for modifications). It does not mention that this is the correct choice when you have a specific business unit ID, nor does it exclude cases where search would be more appropriate. 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?

With no annotations, the description carries the full burden of behavioral disclosure. It implies a read-only search operation but never explicitly states that it has no side effects, nor does it mention result format, pagination behavior, or any rate limits. The description adds minimal behavioral transparency beyond the verb 'Search'.

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 fluff, but it is under-specified. It is concise but sacrifices useful detail that an agent needs. While every word earns its place, the overall structure is too minimal for a 3-parameter 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 the tool's simplicity (3 optional params, no output schema, no annotations), the description is woefully incomplete. It doesn't explain what 'criteria' means, how 'query' interacts with the search, or how pagination works. The agent has almost no information to invoke the tool correctly beyond the schema.

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

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

Schema description coverage is 0%, so the description must compensate. It only vaguely references 'name or criteria', which maps weakly to the 'query' parameter, but provides no explanation of 'page' or 'limit'. The description adds little meaning beyond the raw schema, leaving agents to guess parameter 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 states a verb ('Search'), a resource ('business units'), and a qualifier ('by name or criteria'). It distinguishes itself from the sibling 'boond_businessunits_get' by implying a list/search operation, though it doesn't explicitly contrast them. The purpose is specific and unambiguous.

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

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 'get' or 'create'. No context is provided about prerequisites, typical scenarios, or exclusions. An agent must infer the intended usage from the name and description alone.

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. 'Update' implies mutation, and 'existing' indicates the target must already exist, but nothing is said about side effects, whether this is a partial or full replacement, permissions, or idempotency. This is insufficient 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 concise sentence with no fluff, but it is under-specified. It earns its place by stating the operation, yet offers no structured breakdown of behavior, parameters, or 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 tool with 4 parameters, no output schema, and no annotations, this description is far too thin. It does not explain which fields are updatable, whether it replaces or patches, or what success looks like. An agent would have to rely entirely on parameter names and guesswork.

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

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

Schema description coverage is 0%, and the description does not compensate. It mentions nothing about the parameters (id, name, parentId, managerId), their requiredness, or their meaning. The agent gets no help understanding what each field does or how they relate to the update 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?

The description states a clear verb ('Update') and a specific resource ('business unit'), and the sibling list distinguishes it from boond_businessunits_search, _get, and _create. It lacks detail on what exactly can be updated, but the core purpose is unambiguous.

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

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

There is no guidance on when to use this tool versus alternatives, no mention of prerequisites (e.g., needing an existing ID), and no exclusions. The description merely names the operation without supporting the agent's decision to select it over boond_businessunits_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 provided, the description carries the full burden of behavioral disclosure, but it only says 'Create a new candidate.' It does not mention whether creation is idempotent, what side effects occur, what the response contains, or what happens on duplicate email or missing data.

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

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

The description is a single short sentence with no filler, so it is concise. However, it is under-specified for a tool with seven parameters and no annotations; it provides only a minimal statement of purpose rather than a structured, useful 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 create operation with no annotations and no output schema, the description should clarify expected behavior, return value, and constraints. It only names the operation, leaving the agent to infer response format, duplicate handling, and any organizational context around candidate creation.

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

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

Schema description coverage is 0%, yet the description mentions none of the seven parameters or the three required fields. An agent must rely entirely on property names in the schema; the description adds no semantic meaning beyond them.

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 'Create a new candidate' states a clear action and resource, so an agent knows this tool creates candidates rather than searches or updates them. It does not add any details that distinguish it from other create tools beyond the resource name, which appears in the tool 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 about when to choose this tool over alternatives such as boond_candidates_update or boond_candidates_search. The description merely restates the tool's purpose and implies creation without stating prerequisites or exclusion conditions.

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 bears the full burden. It only says 'get', which implies a read operation, but does not disclose error handling, authentication requirements, or response format. For a simple read, some detail is still expected.

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 phrase with no extraneous words, efficiently front-loading the core 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?

Given the tool's simplicity (one parameter, no output schema), the description is minimally adequate for an agent to know it needs an ID. However, it omits return value details and potential error cases, which would be helpful for full 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?

The schema has 0% description coverage, but the description's 'by ID' provides context for the 'id' parameter, clarifying it is the candidate identifier. This adds some meaning beyond the schema, but it is minimal and does not elaborate on format or constraints.

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

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

The description 'Get a candidate by ID' clearly states the action (get) and resource (candidate) with the identifier method, distinguishing it from boond_candidates_search, create, and update. It is specific and unambiguous.

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

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

The phrase 'by ID' implies this tool is for when you already have the candidate's ID, suggesting alternatives like search when you don't. However, this guidance is not explicit; it does not state when not to use it or name the search alternative.

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 states the core operation but does not disclose pagination behavior, result ordering, whether the search is exact or fuzzy, authentication requirements, or what happens when no query is provided. This leaves significant behavioral ambiguity for a search 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 concise sentence and is appropriately front-loaded with the action and resource. It is not bloated, though 'or other criteria' is unhelpfully vague and does not add much value.

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

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

Given no annotations, no output schema, 0% parameter coverage, and a large sibling toolset, this description is notably incomplete. It does not explain return values, search semantics, pagination, or when to use it over the closely related 'boond_candidates_get'. More context is needed 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 0%, and the description only partially clarifies the 'query' parameter by mentioning name/email. It does not explain the meaning or format of the 'query' value, nor the role of 'page' and 'limit' beyond what the schema's defaults and bounds already imply. The description fails to compensate for the absence of parameter documentation.

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

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

The description clearly identifies the action ('search') and the resource ('candidates'), and gives specific search criteria ('name, email'). However, 'or other criteria' is vague, and it does not explicitly distinguish itself from the sibling 'boond_candidates_get' beyond the general search-vs-get pattern.

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

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

No guidance is given for when to use this tool versus the sibling tools. It does not state that this should be used for query-based listing while 'boond_candidates_get' is for retrieving a specific candidate, nor does it explain what 'other criteria' might be. The agent must infer usage entirely from the tool name and generic search semantics.

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 disclose behavior on its own. Saying 'Update an existing candidate' only reveals that this is a mutation operation; it does not explain whether unspecified fields are preserved, whether the update is partial or full, what happens if the candidate does not exist, or what 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 very short and contains no filler, so it is easy to parse. However, it is under-specified for an 8-parameter mutation tool; the sentence is concise but not appropriately sized to the complexity of the 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 an update operation with 8 parameters, no annotations, and no output schema, this description is too thin. It does not explain expected return values, error cases, partial-update semantics, or how the optional fields interact, leaving an agent without enough context to invoke the tool reliably.

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

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

Schema description coverage is 0%, and the description adds no meaning to any of the 8 parameters. The parameter names and types give some signal (id, firstName, email, etc.), but the description itself does not clarify which fields are updatable in practice, which are optional when updating, or how the id parameter relates to the rest of the payload.

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 ('Update') and resource ('existing candidate'), and the word 'existing' signals that this tool is for modifying an already-created candidate rather than creating or retrieving one. It is clear enough to distinguish the basic intent from sibling tools such as create/get, although it does not elaborate on what updates are possible.

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 instead of boond_candidates_create, boond_candidates_get, or the other update tools. The phrase 'existing candidate' implies a non-creation use case, but there are no explicit conditions, exclusions, or alternatives mentioned.

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

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 'Create a new company' without revealing required permissions, idempotency, side effects, or response format. For a mutation tool with zero annotation coverage, 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 with no wasted words. It is front-loaded and efficient, but the brevity borders on under-specification. However, for the dimension of conciseness, it is appropriately minimal in structure, even if the content is lacking.

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 has 6 parameters, no output schema, and no annotations, the description is grossly incomplete. An agent cannot determine required fields, the meaning of the 'type' enum, or expected return values. The description provides almost no operational context, making it inadequate 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?

The schema has 0% description coverage, meaning the description does not explain any parameters. With 6 properties, including a required 'name' and an enum 'type', the description adds no meaning beyond what the schema already provides. The description fails to compensate for the lack of parameter documentation.

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

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

The description states a specific verb and resource: 'Create a new company.' It is clear about the action, though it does not differentiate from other create tools (e.g., boond_candidates_create) beyond the resource name. The resource name is self-evident, so it adds minimal value but is not misleading.

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. It does not mention prerequisites, such as whether a company type is required, nor does it contrast with boond_companies_update or search tools. An agent has no contextual cues to decide between this and related 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 of behavioral disclosure. It only states the basic operation without any information about permissions, error handling, response format, or what happens if the ID is not found. An agent cannot anticipate any side effects, data returned, or failure modes.

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 wasted words. It is concise, though it is arguably under-specified. It is appropriately sized for the simplicity of the operation but lacks the depth that could make it more 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?

Given the lack of an output schema, annotations, and a rich sibling set, the description is severely incomplete. It does not mention what fields are returned, any prerequisites (e.g., having the ID from a search), or any edge cases. An agent cannot fully judge when to use this tool or what to expect from 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 schema has zero description coverage for the 'id' parameter, and the description does not compensate. It does not explain what the ID represents, how to obtain it, or any format constraints beyond the schema's basic string and minLength. The description adds no semantic value over 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 clearly states the verb 'Get' and the resource 'a company by ID', which distinguishes it from search, create, and update siblings. It is specific enough that an agent knows it retrieves a single company record by its identifier, though it does not explicitly mention that it returns a single object or that the ID is the company's unique key.

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

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

The description provides no guidance on when to use this tool versus the sibling tools, particularly boond_companies_search. It does not mention that this tool should be used when the company ID is already known, or that search should be used to find IDs first. The usage context is entirely implied by the tool name.

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

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 'Search companies by name or criteria' and doesn't disclose pagination behavior, result ordering, filtering semantics, or whether the search is fuzzy/exact. The schema shows page/limit parameters, but the description doesn't explain how they affect 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 short sentence with no wasted words. It is concise and front-loaded with the action and resource, though it could add more useful detail without becoming verbose.

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

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

For a search tool with no annotations, no output schema, and 0% schema description coverage, the description is too thin. It doesn't explain how to construct a query, what results look like, or how pagination works. An agent would have to guess at the semantics of 'criteria' and the response format.

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

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

Schema description coverage is 0%, so the description must compensate for the undocumented parameters. It mentions 'name or criteria' which loosely maps to the 'query' parameter, but it doesn't explain the 'page' and 'limit' parameters or clarify what 'criteria' means. The description adds minimal value beyond the schema's bare parameter names.

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 'Search companies by name or criteria' clearly identifies the verb (search), the resource (companies), and the search mechanism (by name or criteria). It distinguishes itself from sibling tools like boond_companies_get (which retrieves a specific company) and boond_companies_create/update (which mutate companies), though it doesn't 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?

The description gives no explicit guidance on when to use this tool versus alternatives. It implies usage for searching companies, but it doesn't state when to prefer it over boond_companies_get or other search tools, nor does it mention any exclusions or prerequisites.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Update an existing company', which signals mutation but does not clarify whether this is a partial update or full replacement, what happens to omitted fields, whether the id is required to reference an existing record, or what the response looks like. This is a significant gap for a mutating 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 short sentence, which is concise, but it is under-specified rather than efficiently structured. For a tool with seven parameters and no annotations, this is too little content to be considered appropriately 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?

This is a mutating tool with seven parameters, no annotations, no output schema, and 0% schema coverage in the description. The description does not mention the required id, update semantics, parameter effects, or return behavior, so it is inadequate for an agent attempting to invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate by explaining parameter meaning, but it does not. It adds nothing beyond the schema's property names and types. The description never mentions the required id, the type enum, or the contacts array, leaving the agent with no semantic guidance beyond the raw JSON 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 verb and resource: 'Update an existing company'. It is distinguishable from the sibling tools boond_companies_create, boond_companies_get, and boond_companies_search because it identifies the update operation on the company entity. However, it does not mention which fields can be updated, so it lacks full scope 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?

No guidance is provided about when to use this tool versus alternatives such as boond_companies_create, boond_companies_get, or boond_companies_search. The description implies the obvious use case but does not state when this tool should be preferred or when it should not be used.

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

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 behavioral disclosure. It only states 'Create a new contact' without mentioning side effects, return values, authentication requirements, or any other behaviors. This is inadequate 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 sentence, which is concise and front-loaded with the purpose. However, it is so minimal that it borders on under-specification, though it does earn its place by conveying 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?

For a create tool with 7 parameters (4 required), no output schema, and no annotations, the description is severely incomplete. It does not explain success behavior, required fields, or any constraints, leaving the agent to infer too much from the schema alone.

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

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

The schema has 7 parameters with 0% description coverage, and the tool description does not explain any of them. It adds no meaning beyond what the schema already provides, and the required fields are only listed in the schema, not in the description.

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

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

The description 'Create a new contact' clearly states the verb (create) and resource (contact), and it distinguishes from sibling operations like search, get, and update. However, it is minimal and does not add specific details about the contact entity, making it slightly less informative than a more descriptive purpose statement.

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. It does not mention when not to use it, such as when an existing contact should be updated instead, or any prerequisites. The usage context is only implied by the tool name and description.

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

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 only states the operation and gives no detail about read-only behavior, output shape, error cases, or permissions. 'Get' implies a read operation, but little beyond that is disclosed.

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

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

The description is a single, front-loaded sentence with no filler. It is appropriately sized for a simple single-parameter getter 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 tool, this is minimally viable: the agent knows the action, resource, and parameter. However, with no output schema and no annotations, useful context such as return value shape and not-found behavior is omitted.

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

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

Schema description coverage is 0%, and the description adds only 'by ID,' which essentially restates the name of the 'id' parameter. It does not clarify what kind of ID this is, where it comes from, or how it maps to a contact beyond the obvious.

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 ('Get') and the resource ('a contact') with an explicit lookup key ('by ID'). It distinguishes itself from contact creation, update, and search, though it does not explicitly name sibling alternatives.

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

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

There is no guidance on when to use this tool versus boond_contacts_search or other contact tools. The 'by ID' wording only implies the tool is appropriate when a known contact ID is available, but no alternatives or exclusions are stated.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'search', which implies a read-only operation, but it does not state that it returns a list of contacts, how pagination works, or any side effects. There is no information about sorting, default behavior, or what 'other criteria' might be supported. The description adds little beyond the tool name itself.

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 sentence with no wasted words. It front-loads the verb 'search' and the resource 'contacts', followed by the key criteria. This is appropriately concise for the tool's simplicity.

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

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

For a tool with zero schema description coverage and no annotations, the description is too sparse. It does not confirm whether the tool returns a list or a single result, does not explain pagination (despite page/limit parameters), and does not give examples of valid query values. An agent would lack sufficient information to construct a correct search query beyond a basic name or email string. The description falls short of being complete even for a simple search tool.

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

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

Schema description coverage is 0%, so the description must compensate. It adds some meaning by indicating that the query parameter can contain a name or email, but it does not explain the format or other accepted criteria. The page and limit parameters are self-explanatory from their schema definitions and defaults, but their semantics are not elaborated. The description partially clarifies the query parameter's purpose but leaves ambiguity around 'other 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 clearly states it searches contacts by name, email, or other criteria, identifying both the verb (search) and the resource (contacts). It distinguishes from the contacts_get tool by implying a search over a list rather than fetching a single record, though it doesn't explicitly differentiate it from other search tools for different resources beyond the resource 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 on when to use this tool versus alternatives. It doesn't mention that boond_contacts_get should be used when a specific contact ID is known, nor does it clarify the distinction between search and other contact operations. The description offers no exclusions 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?

No annotations are provided, so the description carries the burden of disclosure. 'Update an existing contact' only restates the mutation; it does not reveal whether the update is partial/patch or full replacement, whether invalid fields are rejected, any authorization requirements, or side effects.

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

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

The description is one clean, front-loaded sentence with no filler or redundancy. It sacrifices informational depth rather than structure, but for conciseness it is efficient.

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

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

For an eight-parameter mutation tool with no annotations and no output schema, a one-sentence description is incomplete. It fails to explain update semantics, the required id, the set of editable fields, and any constraints or return behavior an agent would need to call it correctly.

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

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

The input schema has eight parameters with 0% description coverage and the tool description does not mention any parameter. It does not even indicate that id is required or that fields such as email, phone, and firstName are the updatable attributes, leaving the schema names to carry all 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 the core verb 'update' and the resource 'existing contact', which clearly identifies the operation and distinguishes it from boond_contacts_create. However, it is a standard CRUD phrasing shared with all *_update siblings and adds no contact-specific detail beyond the resource 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 word 'existing' implies the tool is for modifying a contact that already exists, which somewhat distinguishes it from create/search/get. There is no explicit guidance about when to use this tool instead of siblings, no mention of fetching the contact first, and no 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 full burden of behavioral disclosure. It only conveys that the operation creates a resource; it does not mention side effects, required relationships, idempotency, or response behavior. It is not misleading, but it materially under-discloses what happens when invoked.

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 states the essential action and resource. However, it leans toward under-specification rather than balanced concision, omitting any detail that would help an agent call the tool safely.

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 six-parameter mutation with 0% schema description coveragechen no output schema and no annotations, a one-sentence description is far from complete. An agent cannot determine valid values, the meaning of resourceId, or the expected behavior after creation.

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

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

Schema description coverage is 0%, and the description adds no parameter meaning. The required resourceId, startDate, and type, plus optional status/endDate/hourlyRate, are left with only names and enums; the description does not clarify semantics such as what resourceId refers to or expected date/rate formats.

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 'Create a new contract' clearly identifies the action (create) and the resource (contract), matching the tool name. It is unambiguous against the search/get/update sibling tools, though it does not add distinguishing scope or field-level 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?

No guidance is given about when to use this tool versus boond_contracts_search, boond_contracts_update, or contracts_get. There is no mention of prerequisites, exclusions, or related entities, leaving the agent to infer usage from the tool name alone.

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

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 the basic action without mentioning response format, error behavior, required permissions, or whether the contract might be returned in a nested structure. For a simple read tool this is minimal but still leaves unknowns.

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 sentence with no filler or redundant detail. It states the action, resource, and key qualifier clearly and front-loads the most important information. 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 one-parameter get-by-ID tool with no output schema, the description is almost sufficient: the agent knows what operation to perform and on what resource. It does not explain what the response contains, but 'Get a contract' reasonably implies returning the contract object. Given the absence of annotations and output schema, it is adequate but not rich.

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

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

Schema coverage is 0%, and there is one required parameter 'id'. The description's 'by ID' confirms the parameter's role but adds little beyond what the property name already implies; it does not describe ID format, source, or how to obtain one. However, with a single obvious parameter, this is minimally adequate.

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 names the resource 'contract', with the qualifier 'by ID' making it clear this is a direct single-record lookup rather than a search. It does not explicitly name sibling alternatives, but the by-ID wording differentiates it from boond_contracts_search and the create/update 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 gives no guidance on when to use this tool versus boond_contracts_search or other retrieval tools. There is no mention of prerequisites, typical use cases, or exclusions. An agent must infer from the name and ID parameter that this is for fetching a known contract.

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 that the tool searches contracts, but omits details such as whether it returns a list, how pagination works, whether authentication is required, or how the 'query' parameter behaves (exact match, fuzzy search, etc.). The description adds no behavioral context beyond the basic action.

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

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

The description is a single succinct sentence, front-loaded with the verb and resource. It contains no fluff or redundant terms,efficiently conveying the core purpose. Its brevity, however, borders on underspecification, keeping it from a 5.

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

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

For a search tool with three optional parametersable and no output schema, the description is not complete enough. It does not clarify what 'resource' and 'type' refer to in the context of contracts, nor does it explain the query syntax. An agent would be left guessing about how to effectively call the tool beyond passing arbitrary text. The presence of many sibling search tools also warrants more differentiation, which is absent.

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

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

Schema description coverage is 0%, so the description must compensate for all three parameters. It vaguely hints at query semantics ('by resource, type, or other criteria') but does not explain how to format the query or what valid values for 'resource' or 'type' are. The page and limit parameters are not mentioned at all, leaving their semantics entirely to inference from their names.

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 ('Search') and resource ('contracts'), and hints at search dimensions ('resource, type, or other criteria'). It distinguishes the tool from sibling 'get' operations by saying 'Search' rather than 'Get'. However, the meaning of 'resource' in the context of contracts is ambiguous, preventing 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 provides no guidance on when to use this tool versus alternatives. It does not mention boond_contracts_get for fetching a single contract by ID, nor does it indicate any conditions that would make this search the preferred option. Usage is only implied by the word 'Search', with no explicit context 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, the description must carry the behavioral burden. 'Update an existing contract' only implies a write operation; it doesn't specify partial vs full update, what happens to omitted fields, permission requirements, or idempotency. This is a significant gap 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 sentence that directly states the tool's purpose without any filler. Every word earns its place; it is concise and 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?

With 7 parameters, no output schema, and no annotations, this description is too sparse. It doesn't explain update semantics, allowed fields, or response behavior, leaving an agent without enough context to invoke 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 0%, and the description adds no meaning to any of the 7 parameters. It doesn't clarify the enums, date formats, or how fields behave on update, failing to compensate for the undocumented 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 clearly states a specific verb ('Update') and resource ('contract'), and the word 'existing' distinguishes it from contract creation. It doesn't name sibling tools, but the purpose is unambiguous and not a tautology.

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

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 boond_contracts_create or boond_contracts_get. There are no prerequisites, conditions, or alternatives mentioned, so usage is only implied by the 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?

With no annotations provided, the description is responsible for conveying behavior, but it only restates the create operation. It says nothing about required permissions, what a successful create returns, whether duplicates are possible, or what lifecycle or status the new delivery starts in. It does not contradict the create intent, but it discloses no meaningful behavioral detail.

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

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

The text is extremely short and contains no filler, which is generally good. However, it is under-specified to the point where it simply echoes the tool name rather than enriching the definition. It is concise but not structured as a genuinely informative description.

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

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

Although the tool is simple, the absence of an output schema and annotations means the description should explain the result of the call and any operational caveats. It provides none, so an agent still lacks information about response shape, error behavior, and side effects. The schema covers argument construction, not invocation 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?

All four parameters in the input schema have their own descriptions: name, projectId, dueDate (ISO 8601), and description. Since schema_description_coverage is 100%, the schema carries the parameter documentation, so the description does not need to add parameter detail. The neutral baseline of 3 is appropriate because the description contributes nothing extra 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 ('Create') and identifies the resource ('a new delivery'), which aligns with the tool name. It does not, however, provide delivery-specific context or distinguish this from the many sibling tools that also operate on deliveries, such as boond_deliveries_update or boond_deliveries_send.

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 contains no guidance on when to use this tool versus alternatives. It never mentions the search/get/update/send siblings or any condition that would select this create operation over them. An agent can only infer usage from the word '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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only indicates a read operation ('Get') and does not mention error behavior, response shape, required permissions, or any notable side effects. For a tool with no annotation coverage, this is a meaningful gap.

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

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

The description is five words and immediately states the operation and target resource. Every word earns its place, and there is no redundant filler.

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

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

For a one-parameter getter, the combination of description and schema is minimally sufficient to make the call. However, there is no output schema and no mention of what a successful response contains or what happens when the ID does not exist, leaving some ambiguity for the agent.

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

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

The schema already documents the single 'id' parameter with a 'Delivery ID' description, and the description reinforces that the ID is the lookup key. Because schema coverage is 100%, the description does not need to add much; it adds no new meaning beyond the schema.

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

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

The description is 'Get a delivery by ID', which clearly identifies the verb (get), the resource (delivery), and the lookup key (ID). This naturally distinguishes it from sibling tools like boond_deliveries_search, which retrieves collections rather than a single delivery.

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 a caller has a specific delivery ID and wants that single record, but it does not explicitly state when to use it versus the search alternative. The usage context is inferable from the phrasing, but no explicit 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 provided, so the description must carry the behavioral burden, but it only says 'Search deliveries by criteria.' It does not disclose return format, pagination behavior, query semantics, or whether the operation is read-only beyond what the verb 'search' 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 short and front-loaded, with no verbose filler. However, it is so generic that it largely restates the tool name, and 'by criteria' does not add meaningful selection guidance.

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

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

For a search tool with no output schema and only three optional parameters, an agent still needs to know what 'criteria' can contain and what the result will look like. The description is too sparse to be complete 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%: page, limit, and query each have a description. The tool description adds no extra meaning beyond the schema, so the baseline 3 applies.

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

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

The description identifies the resource ('deliveries') and the operation ('search'), so an agent knows broadly what the tool does. However, 'by criteria' is vague and adds no specifics about what distinguishes this search from boond_deliveries_get or from the many sibling *_search 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 about when to use this tool versus alternatives, such as boond_deliveries_get or other search tools. The description provides no context, exclusions, or conditions that would help an agent decide.

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 side effects, permissions, idempotency, rate limits, or what happens after calling. The action 'send' implies mutation but nothing is detailed.

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 sentence and front-loaded with the verb, which is efficient. However, it is under-specified to the point of being unhelpful—it provides no detail beyond the bare action. It is not appropriately sized because it omits essential context for a mutation 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 simple tool with one parameter and no output schema, the description should still clarify the nature of the notification and the effect of the action. It does not explain what happens when 'send' is invoked, leaving the agent uncertain about the outcome and required conditions. 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 coverage is 100% (the single parameter 'id' is described as 'Delivery ID'), so the baseline is 3. The description adds no additional meaning about the parameter beyond the schema, but it also does not contradict it. A 3 is appropriate given high 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 states a clear action ('Send') and a resource ('delivery notification'), distinguishing it from search/get/create/update operations. However, it is vague about what 'send' entails—whether it sends the delivery itself or a notification about it, and to whom. This ambiguity lowers it from a 4.

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 alternatives. There is no mention of prerequisites, use cases, or comparison with other send-like tools such as boond_quotations_send. The description is silent on context entirely.

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