Craftboxx MCP by usefulapi

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

Adds real value beyond the annotations by disclosing non-idempotency (each call creates a new record) and the underlying POST endpoint. It does not go further into permissions, duplicates, or what the response contains, but the key behavioral trait of repeated calls is covered.

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

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

Three short clauses, front-loaded with the write marker and the non-idempotency caveat; nothing is wasted. It is slightly telegraphic and uses an endpoint reference that adds little for an agent choosing a 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?

A simple 4-parameter create tool with a complete schema and no output schema; the description covers mutation semantics, uniqueness behavior, and the endpoint. It could mention whether a created ID is returned, but nothing needed to call it correctly is missing.

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

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

Schema description coverage is 100% and all four fields are documented in the schema, so the description need not repeat them. It contributes nothing extra about parameters, so baseline 3 is appropriate.

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

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

States a specific verb and resource ('create a new customer') that clearly separates it from the get_/list_ customer siblings. It doesn't name a sibling explicitly, so it falls just short of the top mark.

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 'WRITE:' prefix and the 'not idempotent' warning imply this is the tool for creating records, but there is no explicit when-to-use statement, no alternative named, and no exclusions. Adequate but thin.

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

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

The non-idempotency warning ("Each call creates a new record") is real behavioral context beyond annotations and directly prevents accidental duplicate creation. The endpoint disclosure is also useful. It stops short of saying what is returned or what permissions/validation failures look like, so it is not a 5.

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

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

Three short clauses, front-loaded with the WRITE marker and the core verb+resource, then the idempotency caveat, then the endpoint. No filler and nothing that needs reordering.

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 3-parameter create tool with no output schema and full schema coverage, this covers the essentials an agent needs: it's a write, it's non-idempotent, and the customer must pre-exist. Only a note on error/return behavior would add anything.

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

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

Schema description coverage is 100% and the required fields, minLength, and the cross-reference to craftboxx_list_customers are all already in the schema. The description adds no parameter-level meaning, 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?

States a specific verb and resource ("create a new project") plus a scope qualifier ("for an existing customer") and even the underlying endpoint (POST /projects). This clearly separates it from craftboxx_get_project and craftboxx_list_projects without opening a schema.

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

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

"For an existing customer" implies the prerequisite that the customer must already exist, and the schema points at craftboxx_list_customers for the id. However, the description gives no explicit when-to-use/when-not guidance and never names a sibling alternative, so usage is inferable rather than 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?

The readOnlyHint annotation already establishes that this is a safe read operation. The description adds only the API endpoint, with no additional behavioral context such as error behavior, permissions, or rate limits.

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

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

The description is two short sentences with the core purpose front-loaded. The API endpoint sentence is compact and adds a useful mapping without wasting space.

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

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

For a simple single-record getter with one fully described parameter and a readOnly annotation, the description is sufficient for correct invocation. It does not explain the returned assignment shape, but no output schema is present and the complexity is low.

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

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

Schema description coverage is 100%, so the single assignment_id parameter is already fully documented. The description's 'by id' adds only minimal meaning beyond the schema, which is the expected baseline when the schema does the heavy lifting.

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

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

The description states a specific verb and resource: get one assignment by id. The phrase 'one assignment by id' distinguishes it from list_assignments, though it does not explicitly name that sibling as the alternative for listing.

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 is the tool to use when a specific assignment id is known. However, there is no explicit when-to-use guidance, no exclusions, and no mention of when to use list_assignments instead.

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?

readOnlyHint=true already establishes this is a safe read, so the description's burden is low. It adds the returned field categories (name, address, contact data), which is useful because there is no output schema, but says nothing about permissions, error cases, or whether a null result is possible.

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

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

One front-loaded sentence gives the resource, scope, and returned fields, followed by a short API mapping. Nothing is padded or repeated from the title.

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

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

For a zero-parameter read with readOnlyHint and a stated payload, an agent has enough to invoke it correctly. The only omission is what happens when the account has no company attached, which is minor for this shape.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The description correctly refrains from inventing arguments and instead pins the target to the authenticated account.

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

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

States a specific verb and resource ("Get the company") scoped to "the signed-in account" and enumerates the payload (name, address, contact data). The "signed-in account" scoping implicitly separates it from craftboxx_get_customer, but no sibling is named 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?

Usage is implied: fetch the caller's own company rather than a customer record. There is no explicit when/when-not guidance or pointer to craftboxx_get_customer / craftboxx_list_customers for other company data.

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?

readOnlyHint=true already declares the safety profile, so the description only needs to add context. It contributes the underlying endpoint (GET /customers/{id}) but says nothing about failure behavior for an unknown id, auth requirements, or what fields the returned customer carries.

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

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

Two short sentences, front-loaded with the action and scope. The API endpoint sentence is mild filler for an agent but plausibly useful for debugging, so it isn't wasteful enough to penalize heavily.

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

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

This is a simple single-parameter read tool and annotations cover safety, but with no output schema the description offers no hint about what a customer record contains or how a missing id is surfaced — a modest but real gap.

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

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

Schema coverage is 100% and the single parameter is documented as 'The customer id.' The description's 'by id' merely restates that, adding no format, type, or sourcing guidance beyond the schema — baseline 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 gives a specific verb and resource ('Get one customer by id'), clearly distinguishing a single-record fetch from the list_customers and create_customer siblings, though it never names those alternatives 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?

Usage is only implied by the phrase 'by id' — an agent infers it is the lookup path when a specific customer id is known, but there is no explicit when-to-use, when-not, or routing to craftboxx_list_customers for browsing.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the underlying REST endpoint (GET /employees/{id}), which helps an agent reason about idempotence and error behavior, but says nothing about not-found handling or response shape.

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

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

Two short sentences, the key fact (one employee by id) front-loaded, with zero filler. Nothing is redundant, though nothing is elaborated either.

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

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

For a single-parameter read tool with annotations covering safety and a fully described schema, the description supplies enough to call it correctly. The only omission is what the response contains, which is minor given the trivial nature of the 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?

Only one parameter and schema description coverage is 100%, so the schema already documents employee_id fully. The description's 'by id' adds no format or type guidance beyond that, making the baseline 3 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?

States a specific verb and resource ('Get one employee by id'), and the word 'one' implicitly separates it from the sibling craftboxx_list_employees. It is clear what the tool does, though it never names the list 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?

Usage is only implied: fetching a single record when you already have an id, as opposed to listing. There is no explicit when-to-use/when-not statement or named alternative, but for a simple lookup tool this is a reasonable minimum.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds little beyond that — the endpoint reference (GET /projects/{id}) is a restatement, and there's no mention of error behavior for missing ids or what a project record contains, though the latter is partially excused by the lack of an output schema.

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

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

Two short sentences, with the actual purpose front-loaded. The API endpoint line is low-value filler but not harmful.

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

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

This is a simple one-parameter read tool with full schema coverage and a readOnlyHint, so heavy description isn't required. Still, nothing is said about the returned project or failure modes, leaving the definition minimally adequate rather than complete.

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

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

Schema coverage is 100% for the single required parameter, so the baseline of 3 applies. The description contributes nothing beyond the schema's 'The project id.' and doesn't clarify whether the id is numeric or string despite the schema allowing both.

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

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

States a specific verb and resource ('Get one project by id'), which naturally distinguishes it from the sibling list_projects. It doesn't explicitly name the sibling, but the singular/plural distinction 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 implied: fetch a single project when you have its id. There's no explicit guidance on when to prefer this over craftboxx_list_projects or what happens if the id is unknown, but the condition for use is reasonably inferable.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds that this is a GET on the /absences endpoint, which is minor but real context; it says nothing about pagination defaults, result ordering, or whether unpaginated calls are risky.

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

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

Two compact sentences that lead with the purpose, then the endpoint. Slightly wasteful since the filter parenthetical duplicates what the schema documents, but nothing is buried or padded.

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 read-only, fully-documented, zero-required-parameter list tool with no output schema, this is close to sufficient; the safety profile and params are carried by annotations and schema. The remaining gap is that an agent gets no hint about what absence records contain or how pagination should be driven.

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

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

Schema coverage is 100%, so the schema already explains all six parameters including the pointer to craftboxx_list_absence_types. The parenthetical '(employee, type, start, end)' restates filter dimensions already present in the schema and adds no format or semantics beyond it.

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

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

States a specific verb+resource ('List absences') and gives concrete examples of what an absence is (holiday, sick leave), plus the underlying endpoint. It does not differentiate itself from the related craftboxx_list_absence_types sibling, which is only referenced inside the schema.

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

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

There is no when-to-use guidance, no exclusions, and no pointer to the sibling craftboxx_list_absence_types for discovering type ids. The agent must infer that this is the general listing tool for absences purely from the name and one-line 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?

readOnlyHint=true already tells the agent this is a safe read. The description adds the underlying endpoint (GET /absences/types), which usefully signals it is a static reference list rather than a mutated resource, but it says nothing about pagination defaults, result volume, or whether the list is user-scoped.

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

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

Two terse sentences, zero filler, with the resource definition front-loaded and the endpoint as supporting detail. Nothing to trim.

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

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

For a two-optional-param read-only list with full schema coverage and annotations carrying the safety profile, the description is nearly complete. The only real gap is what fields come back (id? label?) since there is no output schema, which matters because the returned identifiers are likely needed by other tools.

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

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

Schema description coverage is 100% and both page/per_page parameters are documented with bounds in the schema. The description adds no parameter meaning beyond that, 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?

States a specific verb+resource ('List absence reasons') and parenthetically clarifies what an absence type is (holiday, sick, ...). It implicitly distinguishes the reference-data tool from craftboxx_list_absences, but never names that sibling to confirm the distinction.

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

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

No explicit when-to-use statement or exclusions. The word 'types' plus the examples loosely imply this is the lookup for valid absence reasons, presumably to feed into other calls, but an agent must infer the relationship to craftboxx_list_absences on its own.

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

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

The readOnlyHint annotation already establishes the safe read-only nature, and the description usefully adds the underlying API endpoint and the key fields returned. However, it does not describe pagination behavior, filtering behavior, or whether the list is scoped to the authenticated company.

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 definition is two compact sentences with zero waste and front-loads what the tool returns. The API endpoint is supplementary but brief.

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-only list tool with no output schema, the description supplies the resource scope, key returned fields, and endpoint. Pagination and search/filter semantics are left to the schema, which is reasonable given the 100% schema description coverage.

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

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

Schema description coverage is 100%, so the four parameters are already documented. The description does not add syntax, matching behavior, or filter-combination semantics beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource ("List articles in the material catalog") and names representative returned fields. The resource is distinct from siblings, but the description does not explicitly differentiate this tool from other list_* 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?

It implies this is for browsing the material catalog, but gives no guidance on when to prefer it over other list tools or when to use free-text search versus manufacturer filtering. No exclusions or alternative-selection criteria 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?

The readOnlyHint annotation already establishes the safe-read profile, and the description adds that results are assignments with specific fields plus the underlying endpoint (GET /assignments). It does not disclose pagination behavior, default result limits, or how archived items interact with results beyond what the schema's show_archived already says.

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

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

Two short sentences with no filler: the resource definition and the field list come first, filtering second, endpoint last. Every clause carries information an agent can use.

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 7-parameter list tool with full schema coverage and no output schema, the description explains what an assignment is and which fields come back, which is the main gap the schema cannot cover. Pagination semantics (default page size, total counts) are left implicit, keeping it just short of 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 100%, so every parameter (q, start, end, page, per_page, employees, show_archived) is already documented in the schema. The description's mention of date-range and employee filtering only echoes two of those parameters without adding format or semantic detail beyond the schema, which is the expected baseline.

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

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

States a specific verb and resource ('List assignments') and then disambiguates the domain term by glossing it as 'planned jobs/appointments' with the returned fields spelled out. This clearly separates it from the singular craftboxx_get_assignment sibling, though it never explicitly contrasts with craftboxx_list_timesheets or craftboxx_list_projects.

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?

'Filter by date range or employee' implies the intended retrieval contexts, but there is no explicit when-to-use versus when-to-use-something-else guidance, and no mention of when the list endpoint is preferable to get_assignment for a known id.

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?

readOnlyHint=true already tells the agent this is a safe read, so the description's burden is lighter. It adds the upstream endpoint (GET /customers) and a sketch of returned fields, but says nothing about pagination defaults, result ordering, or response envelope for a paginated collection.

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

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

Two compact sentences with no filler and the core purpose front-loaded. The parenthetical "info" is vague enough to be slightly wasteful, but overall nothing is padded.

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

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

With no output schema and only a readOnly annotation, the description should carry more: pagination semantics, what "info" actually contains, and how results are ordered are all absent. The 5-parameter filter surface is fully documented in the schema, so the gap is mostly about return behavior rather than 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 q, name, page, per_page, and customer_number are all documented in the schema itself. The description's parenthetical mentions name and customer number but frames them as returned fields rather than filters, adding no syntax or behavior 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?

States a specific verb and resource ("List customers") and hints at returned fields (name, customer number, info), which is enough to distinguish it from mutation siblings like craftboxx_create_customer. It does not explicitly contrast with craftboxx_get_customer, so a reader must rely on the list/get naming convention to separate the two.

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 when-to-use guidance and no mention of the alternative craftboxx_get_customer for single-record retrieval. The only signal is the verb "List", leaving the list-vs-get choice to inference.

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

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

readOnlyHint=true already covers the safety profile, and the description adds valuable context beyond that: a documentation is a report written on an assignment and returns title, state, type, and author. It also cites the backing endpoint GET /documentations, though it does not mention pagination 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?

Two tight sentences: the purpose and its definition are front-loaded, followed by the API reference. There is no wasted verbiage.

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 5-optional-parameter read-only list tool with no output schema, the description supplies the return fields and resource definition, which is exactly what fills the output-schema gap. Only pagination/result-shape nuance is left unstated, a minor omission given the schema covers the paging params.

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 q, page, per_page, author_id, and assignment_id are already documented in the schema. The description adds no filter semantics beyond that, 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?

States a clear verb and resource (list job documentations) and clarifies what a documentation is (reports written on assignments) with its fields. This conceptually distinguishes it from siblings like list_assignments, though it never names a sibling explicitly.

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

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

There is no explicit when-to-use guidance, no exclusions, and no mention of when to prefer list_assignments versus list_documentations. Usage is only implied by the name and the parenthetical definition.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered; the description adds genuinely new context by disclosing which fields come back (important since there is no output schema) and mapping the call to the underlying GET /employees endpoint. It stops short of describing pagination behavior or result-size limits, so not a 5.

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

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

Two compact clauses with zero filler: the resource and its returned fields are front-loaded, followed by the endpoint reference. Every element 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 fully-optional 6-parameter list tool with no output schema, the description covers the return shape and the underlying API, and the schema carries the filtering semantics. The only real omission is guidance on pagination expectations and on choosing this over craftboxx_get_employee.

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

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

Schema description coverage is 100%, with all six parameters (q, page, email, group_id, per_page, last_name) documented in the schema itself. The description adds no filtering syntax or interaction detail (e.g. how q combines with exact-match filters), 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?

States a specific verb+resource ('List employees') and enumerates the returned fields (name, email, phone, group, skills, inactive flag), which sharply distinguishes it from a detail fetch. It does not explicitly contrast with sibling craftboxx_get_employee, so it falls short of a 5.

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

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

The description contains no when-to-use or when-not-to-use guidance and never names the alternative (craftboxx_get_employee) for single-record retrieval. The agent must infer from the tool name that this is the roster-browsing option rather than a detail lookup.

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

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

The readOnlyHint annotation already declares this is a safe read, so the description's main added value is the concrete endpoint (GET /projects) and the returned field set. It says nothing about pagination behavior, total counts, or result ordering, which is meaningful context given the page/per_page parameters.

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

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

Two compact sentences, front-loaded with what the tool does and what it returns, with the API endpoint as a trailing reference. Nothing is wasted and nothing important is buried.

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 seven optional parameters and no output schema, the enumerated return fields partially compensate for the missing output contract, which is a real contribution. But pagination semantics and whether the response is a bare array or a paginated envelope remain unexplained, leaving a gap an agent would hit on the first call.

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 seven parameters (q, page, per_page, title, project_nr, customer_id, show_archived) are already documented in the schema. The description adds nothing about filtering semantics or how filters combine, 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?

States a specific verb and resource ('List projects') and even enumerates the fields returned (title, project number, customer, sales volume), so the agent knows what it gets back. It does not, however, distinguish itself from the singular sibling craftboxx_get_project or from the other list_* tools, which is the only thing keeping it from a 5.

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

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

There is no when-to-use guidance: nothing says to prefer this over craftboxx_get_project for a single record, or over craftboxx_list_customers when the customer context is the goal. Usage is only implied by the verb 'List', leaving the agent to infer routing from tool names 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?

Annotations already declare readOnlyHint=true, so safety is covered. The description adds the returned field set and the backing API endpoint, which is useful context since no output schema exists, but it does not describe pagination behavior, sorting, or filtering semantics beyond what the schema provides.

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

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

Two compact sentences, front-loaded with the purpose and returned fields. The endpoint line is marginally redundant but harmless and lightly useful for API-aware callers.

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 read-only filtered list with no output schema, listing the returned fields is the key addition, and it is present. The parameters are fully described in the schema, and annotations cover safety, so only minor details like pagination behavior or sort order are unstated.

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 five parameters (start, end, employee_id, page, per_page) are already documented in the input schema. The description adds no parameter-specific meaning beyond that baseline, which is acceptable given the schema does the heavy lifting.

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

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

States a specific verb and resource ('List timesheets') and enumerates the fields returned (employee, start, end, working time, break time), so an agent knows exactly what data this tool surfaces. It does not explicitly differentiate itself from sibling list tools such as list_absences, but the resource name 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?

The description gives no explicit when-to-use guidance, no prerequisites, and no alternatives. Usage is only implied by the generic 'List' verb, leaving the agent to infer this is for timesheet retrieval rather than absence or assignment retrieval.

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