Hub Planner MCP by usefulapi

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

Annotations already declare readOnlyHint=false and idempotentHint=false, but the description adds genuinely new context: the API key scope needed and the concrete consequence of non-idempotency (duplicate clients). It stops short of saying what is returned or how duplicates are detected/prevented.

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 sentences, front-loaded with the operation class and with zero filler; each sentence carries a distinct fact (action, auth requirement, duplicate risk).

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 write with annotations covering safety and idempotency, the description covers the key operational facts an agent needs (write, auth scope, duplicate risk). Only the return value and duplicate-failure behavior are 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 carry the param meaning; it only says 'by name', leaving uniqueness, trimming, and format unaddressed. The minLength/maxLength constraints live in the schema, so the description adds little beyond naming the field.

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 client') plus the sole input ('by name'), and the 'WRITE:' prefix separates it at a glance from the get_/list_/search_ client siblings. An agent can identify what it does without opening 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?

Provides a real prerequisite ('Requires a Read & Write API key') and warns that repeats create duplicates, which implies checking first, but it never names the alternative tool (hubplanner_get_client / hubplanner_list_clients) or states the condition for using it. Usage is inferred rather than directed.

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?

Adds substantial context beyond the annotations: it names the auth requirement (Read & Write API key), discloses downstream side effects (affects reports and billing), and states retry behavior (no automatic retries). These are exactly the traits annotations do not convey.

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?

Four short sentences, each earning its place: operation, auth, consequence, retry semantics. The operation is front-loaded after the WRITE marker.

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?

No output schema and thin annotations mean the description carries the load, and it adequately covers auth, side effects, and retry behavior for a create. It is slightly incomplete on parameter meaning (minutes/note) and on duplicate-entry behavior, but the core an agent needs to call it correctly is present.

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%, so the description must carry parameter meaning, but it only references resource, project, and date conceptually. It never explains that 'minutes' is worked time (1-1440) or what 'note' is for, leaving the two most ambiguous params to the bare 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 (Create), resource (time entry), and scope (a resource and project on one date). The 'WRITE:' prefix and singular-entry framing distinguish it clearly from the get/list/search_time_entries siblings.

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

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

The 'WRITE:' label and 'verify details first' imply this is the mutation path versus read siblings, and 'No automatic retries' tells the agent to retry deliberately. It never explicitly names an alternative or a when-not-to-use condition, so it stops short of full routing guidance.

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

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

readOnlyHint=true already establishes this is a safe read with no side effects, so the description is not required to prove safety. But it adds nothing beyond the annotations – no note on behavior when the ID is unknown (empty result vs error), no pagination or scope caveats, no indication of what a booking record contains.

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 with no filler or redundancy; the resource and the access pattern appear immediately. It is appropriately sized for a trivial read, though the brevity edges into under-specification.

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

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

For a one-parameter read tool with readOnlyHint and no output schema, the essentials are present, but with no output schema the description could have said what fields come back or what happens on a missing ID. Adequate, not 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 0% and the single 'id' property has no schema description. The phrase "by its ID" does confirm the parameter takes a booking identifier rather than a user/project ID, which is a small but real addition over the bare 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?

"Get one Hub Planner booking by its ID" gives a specific verb (get), resource (booking), and cardinality (one, by ID), which implicitly separates it from the list_/search_ siblings that return collections. It stops short of naming those siblings explicitly, so the differentiation is inferable rather than stated.

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 choose this over hubplanner_list_bookings or hubplanner_search_bookings, and no mention of what to do when you have a booking name/subject but not an ID. The agent must infer the retrieval path 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?

readOnlyHint=true already declares the safety profile, so the description's burden is light. 'Get one ... by its ID' usefully adds that the result is a single entity rather than a collection, but it says nothing about what happens when the ID does not exist or what fields are returned.

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

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

A single front-loaded sentence with no filler. It is efficient, though arguably too terse for a tool that lacks an output schema.

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

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

For a one-parameter read-only getter this is close to adequate: the action, target, and key are all present. Missing is any notion of not-found behavior or expected return content, which matters somewhat because no output schema exists.

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 required parameter with 0% description coverage, so the description must carry the meaning. 'By its ID' tells the agent the parameter is the client identifier, but adds no format hints (ID shape, string length/lookup rules) beyond what the schema name 'id' already implies.

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

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

The description names a specific verb and resource ('Get one Hub Planner client') and states the lookup key (ID), which separates it from the list/search siblings. It stops short of explicitly naming those siblings, but the single-vs-many distinction is clear.

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

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

There is no guidance on when to use this versus hubplanner_list_clients or hubplanner_search_*; the only implied rule is 'when you have an ID'. No prerequisites, no exclusion for the case where the ID is unknown.

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, and the description adds nothing further — no note on what happens when the ID is unknown (error vs empty), no permission/scope requirements, no mention of ID format. With annotations covering the safety profile the bar is lower, but the description contributes essentially nothing beyond the annotation.

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

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

A single front-loaded sentence with no filler; the resource and the identifying key come first. It is efficient, though so terse that brevity shades into under-specification rather than true crispness.

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

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

For a one-parameter read tool with readOnlyHint and no output schema, the essentials are covered — an agent knows what it fetches and how to identify it. Missing are the ID format and failure behavior on an unknown ID, which are the only real gaps 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?

Schema description coverage is 0%, so the description must carry the meaning of the single `id` parameter. It only restates "by its ID" without giving the expected identifier form (e.g. a Hub Planner object ID vs a human-readable project code) or any constraint context beyond the schema's minLength/maxLength.

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 Hub Planner project") and scopes it to a single record via ID, which implicitly distinguishes it from hubplanner_list_projects and hubplanner_search_projects. It does not name those siblings explicitly, but the singular-by-ID framing makes the intent 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 versus hubplanner_search_projects or hubplanner_list_projects, nor any stated prerequisite such as already having a valid project ID. The condition "by its ID" is the only hint an agent gets, and it is left 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?

The readOnlyHint annotation already covers the safety profile, but the description adds nothing beyond it — no indication of what happens when the ID does not exist, whether it errors or returns empty, or any auth/rate-limit context. It essentially restates the title.

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

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

One short, front-loaded sentence with zero waste. It is efficient, though bordering on 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 simple one-parameter read with readOnlyHint and no output schema, the description is minimally sufficient to call it correctly. Missing pieces — ID format and not-found behavior — are small but real gaps for a lookup 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; 'by its ID' does establish that the single parameter is the resource identifier, but says nothing about accepted ID format despite it being a free-form string up to 200 chars.

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?

Specific verb and resource ('Get one Hub Planner resource by its ID'), and the word 'one' implicitly separates it from the list/search siblings. It stops short of naming those siblings, so the differentiation is inferable rather than explicit.

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

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

Usage is only implied: an agent can infer this is the direct-lookup path when it already holds a resource ID, versus list/search tools. There is no explicit statement of when to prefer it over hubplanner_search_resources or hubplanner_list_resources.

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 this is a safe read, so the description's main added value is confirming single-record retrieval. It does not disclose behavior on a missing/invalid ID (error vs empty) or any scoping/permission constraints, which would be genuinely useful additional context.

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

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

A single front-loaded sentence with no redundant phrasing. It is appropriately sized for a trivial one-parameter lookup, though it could have used its brevity budget to add a usage hint.

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 read with readOnlyHint covering safety and no output schema, the essentials are present, but the description says nothing about return shape or failure behavior when the ID doesn't resolve. Adequate 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?

The schema documents only type and length bounds with 0% description coverage; the description clarifies that the lone 'id' parameter is the timeentry's ID rather than a user/workspace ID. That is a meaningful but minimal addition, leaving format assumptions (e.g., UUID) unstated.

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 (Get) and resource (Hub Planner timeentry) with scope (one, by ID), which distinguishes it from list_time_entries and search_time_entries siblings that return many. It is clear, though it doesn't explicitly name the multi-item siblings it contrasts with.

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 its ID' signals single-record lookup versus listing/searching, but the description never says when to prefer this over hubplanner_list_time_entries or hubplanner_search_time_entries, nor what to do if the ID is unknown. No explicit alternatives or exclusions are given.

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

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

Annotations already declare readOnlyHint=true, so safety needs no restating; the description instead adds genuinely new behavioral detail — zero-based paging and the 'follow next_page until null' termination loop, which is the only place the next_page cursor is documented since there is no output schema.

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

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

Three short sentences, no filler, with the core purpose and pagination loop front-loaded before the routing hint to the search tool.

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

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

For a read-only two-parameter lister with full schema coverage, the description covers the only non-obvious behavior — how iteration ends via next_page. It could mention whether an empty page signals exhaustion, but nothing essential to a correct call 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%, so both parameters (page, limit) and their bounds/defaults are already fully documented. The description's pagination notes concern traversal rather than parameter meaning, so it adds no semantics 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?

States a specific verb and resource ('List one page of Hub Planner bookings') and immediately scopes it as the unfiltered counterpart to the search tool, so an agent can distinguish it from hubplanner_search_bookings without opening either 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?

Explicitly routes filtered queries to the search tool, giving a clear when-to-use-this-vs-alternative rule. The hedge 'where available' and the absence of any stated prerequisites (auth, workspace scope) keep it short of a 5.

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

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

Annotations already declare readOnlyHint=true, so safety is covered, and the description adds genuinely new behavior: zero-based paging and the "follow next_page until null" termination rule, which governs how to drain results. It does not disclose rate limits or the shape of a client record, but for a read-only list tool this is solid.

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

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

Three short sentences, all load-bearing; purpose is front-loaded before the pagination mechanics and the alternative-tool pointer. Nothing redundant 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 2-parameter, no-required-args read tool with readOnlyHint and no output schema, the description covers purpose, paging loop, and the filtered alternative — enough to invoke correctly. The only gap is that it never hints at what a client record contains or whether default limit of 100 is applied automatically.

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 'page' (zero-based) and 'limit' (max 1000) are already documented. The description adds value beyond that by explaining the iteration contract — start at page 0 and continue while next_page is non-null — which is not expressible 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?

Specific verb + resource + scope: "List one page of Hub Planner clients" tells an agent exactly what this returns and that it is paginated, distinguishing it from hubplanner_get_client. Sibling differentiation is only partial because the redirect points at "the search tool where available" rather than a named sibling (and no hubplanner_search_clients exists).

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?

Clear usage context: use this for the unfiltered paginated listing and follow next_page until null. The alternative path is stated but hedged ("the search tool where available"), which leaves the agent to figure out which tool that is; no mention of when to prefer get_client for a single record.

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 only establish readOnlyHint=true, but the description adds real behavioral detail the annotations don't carry: zero-based paging and the next_page-until-null termination protocol, which is essential to avoid missing data. It stops short of noting rate limits or ordering of results, 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?

Three short sentences, no filler, and the core scoping constraint plus pagination protocol are front-loaded before the alternative-tool pointer. Every sentence earns its place.

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

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

For a two-parameter read-only list tool this covers the essentials an agent needs: what it returns (a page), how to advance, and where to go for filters. With no output schema, a brief note on result ordering or what a project record contains would have closed the remaining 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%, so both parameters (page, limit) are already fully documented with defaults, minimums and maximums. The description restates the zero-based origin and introduces next_page, which is a response field rather than an input parameter, so it adds only marginal semantic value.

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 one page of Hub Planner projects") and scopes the result set explicitly to a single page. It also distinguishes itself from the sibling search tool, so an agent can tell list-projects from search-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?

Gives concrete usage context: start at page 0 and follow next_page until null, and use the search tool for filtered results. The hedge "where available" weakens the routing instruction slightly, and it never mentions when to prefer hubplanner_get_project for a single known project.

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 genuinely new behavior — that results are paginated and that a next_page cursor must be followed until null. It doesn't state rate limits or default page size, but the core pagination contract 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?

Three short sentences, zero filler, with the core action stated first and pagination mechanics immediately after. Every sentence carries distinct 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?

With no output schema, the description still conveys the response envelope (paginated, next_page cursor) which is the critical thing an agent needs. It stops short of describing resource fields or total counts, but nothing required for correct invocation 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 coverage is 100%, so 'page' and 'limit' are already fully documented. The description's 'pages start at 0' merely restates the schema minimum/default, and the next_page guidance is output-side rather than clarifying the input parameters, so it 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?

States a specific verb and resource ('List one page of Hub Planner resources') and scopes it to a single page, which distinguishes it from an unfiltered/full dump. It gestures at the search sibling ('use the search tool where available') but never names hubplanner_search_resources, so the differentiation is slightly hedged.

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?

Gives explicit operating instructions: pages are zero-based, iterate next_page until null, and switch to a search tool when filtering is needed. The only gap is the vague 'where available' qualifier instead of pointing at the concrete sibling tool.

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 only needs to add context. It does add paging behavior (pages start at 0, follow next_page until null), which is genuinely useful, but it says nothing about the entry shape, ordering, or whether next_page sits alongside data. With annotations covering the safety profile, a 3 is appropriate.

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

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

Three short sentences, front-loaded with the core action and zero padding. The final sentence is a slightly loose pointer rather than wasted text.

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

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

For a two-parameter read tool with full schema coverage and a readOnlyHint, this is nearly complete: paging and the next_page sentinel are covered even without an output schema. A note on entry contents or ordering would close the remaining 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 both parameters already carry descriptions ('Zero-based page', 'Results per page, max 1000'), so the description cannot add much. It restates zero-based paging and introduces next_page for the response, but gives no format or interaction detail 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?

States a specific verb and resource ('List one page of Hub Planner time entries') and points away from the filtered variant, so an agent can separate it from hubplanner_search_time_entries. The hedge 'where available' and failure to name that sibling explicitly keep it 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?

Gives a clear usage rule: use this for unfiltered paging, use the search tool for filtered results. The alternative is named only generically ('the search tool'), with no explicit when-not conditions 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?

Annotations already declare readOnlyHint=true, so safety is covered. The description does add genuinely non-obvious behavior — that the date filter is an inclusive overlap test rather than containment — but it is silent on defaults when no filters are given (all bookings?), result ordering, and any per-call scope or permission requirements.

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

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

Three short sentences with the primary purpose first, followed by the two pieces of non-obvious semantics. No filler and nothing redundant.

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, zero-required search tool with no output schema, the description should clarify the unfiltered behavior, identifier formats, and result ordering. It covers the range semantics well but leaves those gaps, which matter for correct invocation.

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

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

Schema coverage is only 33%: page and limit are documented in-schema, while start, end, project and resource have no descriptions there. The description partially compensates by explaining the overlap semantics of start/end and naming the filter roles of project/resource, but it never says whether resource/project are IDs or names, nor that all parameters are optional.

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 ('Find bookings') and enumerates the filter axes (resource, project, date range). It does not explicitly distinguish itself from the sibling list_bookings or search_time_entries, so the agent must infer that this is the filtered variant.

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 sentence about start/end selecting overlapping bookings gives real usage semantics for those two parameters, and pagination is noted as zero-based. However, there is no guidance on when to prefer this over list_bookings or get_booking, nor on what happens if a caller supplies no filters at all.

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 this is a safe read, so the description's job is only to add context. It contributes the "exact name" matching semantics and the zero-based pagination note, but says nothing about behavior with no filters supplied (does it return all projects?), result ordering, or total counts.

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 zero filler, and the core purpose is front-loaded. The brevity comes at the cost of completeness rather than being padded, but nothing in the text is wasted.

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 4-parameter, no-required-parameter read tool with annotations covering safety, this is close to sufficient. It is missing the default-behavior case (no filters) and any differentiation from hubplanner_list_projects, which matters given how many overlapping sibling tools exist.

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 50%: page and limit are already documented in the schema, and the status enum is self-describing. The description's real contribution is clarifying that name is an exact match rather than a substring search, which the schema does not say — valuable but limited to one parameter.

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

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

States a specific verb+resource ("Search projects") and the two filter dimensions (exact name or status), so the agent knows what the tool does. It does not, however, distinguish itself from the sibling hubplanner_list_projects or hubplanner_get_project, leaving the search-vs-list boundary implicit.

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 exact name or status" implies when to reach for this over a plain list, but the description never names an alternative or states a condition such as "use list_projects to enumerate everything." Usage must be inferred from sibling names.

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

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

readOnlyHint=true already tells the agent this is a safe read. The only added behavioral note is 'Pagination is zero-based', which largely duplicates the page parameter's schema description, and nothing is said about what happens with zero filters or how results are ordered.

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

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

Two sentences, front-loaded with the filterable fields and followed by the pagination caveat. No filler, though the pagination sentence repeats structured data.

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-optional-parameter search with no output schema and no annotation detail beyond readOnlyHint, the description omits the result shape, default ordering, and the limit/paging relationship. Adequate to call it, but not sufficient to predict its behavior.

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?

Coverage is only 33%, so the description has to carry weight: it correctly signals exact-match semantics for email, firstName, lastName and status, which is real value beyond the bare schema. However limit is never mentioned and the exactness claim for a status enum is ambiguous, leaving the compensation incomplete.

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?

Names a specific verb (search) and resource (resources) plus the exact fields it filters on, which clearly separates it from list_resources and get_resource by implication. It stops short of naming those siblings explicitly, so the differentiation is inferential rather than stated.

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 'search ... by exact email, first name, last name or status' implies when to reach for this over a plain list, and the word 'exact' hints that partial matches won't work. There is no explicit when-to-use/when-not guidance or named 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?

Annotations already declare readOnlyHint=true, and the description correctly reinforces a non-mutating read. It adds genuine behavioral detail beyond the annotations ('inclusive' date range, zero-based pagination), but omits whether multiple filters are AND-combined, whether results are sorted, and what the response shape looks like.

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

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

One sentence plus a short pagination clause, zero filler, with the filter semantics front-loaded. Nothing could be cut without losing 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?

For a 7-parameter, zero-required search tool with no output schema and only a readOnlyHint, the description covers filters and the pagination base adequately but says nothing about default result ordering, whether all parameters are optional, or how an empty filter set behaves.

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 only 29%, so the description must compensate — and it does, covering start/end (inclusive, YYYY-MM-DD), resource, project, status, and the zero-based page convention. The limit parameter's meaning lives only in the schema, and the AND/OR combination of optional filters is left unstated.

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 (Find) and resource (time entries) plus the filterable dimensions: resource, project, inclusive date range, and submission status. It does not distinguish itself from the sibling hubplanner_list_time_entries, so an agent must infer the search-vs-list 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?

Usage is implied by naming the filter dimensions — an agent can infer this is the filtered query and that list_time_entries is the unfiltered alternative — but no explicit when-to-use or when-not-to-use guidance is given, and the sibling is never named.

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