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

With no annotations present, the description carries the behavioral disclosure burden. It communicates that the tool attempts to retrieve the spec, returns only GET paths by default, and offers a full-spec option. It does not detail output format or failure modes, but for a read-only introspection tool this is reasonably transparent.

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

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

The description is two concise sentences: the first states the core behavior, the second gives the practical usage trigger. There is no filler or redundant 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 simple optional-boolean introspection tool, the description provides enough context: purpose, output scope, and when to invoke it. Since there is no output schema, a bit more detail about the exact output format would improve completeness, but it is not a critical gap.

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

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

The schema already fully documents the only parameter 'full' with its default and meaning. The description does not add parameter-level detail, but with 100% schema coverage this meets the baseline.

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

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

The description clearly states a specific verb ('ophalen') and resource (OpenAPI/Swagger-specificatie) and specifies that it returns available GET paths. This clearly distinguishes it from the data-access sibling tools like teamhood_raw_get.

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 an explicit trigger: use this tool when another tool returns a 404, so you can discover the endpoint name in your version. It provides clear context but does not mention alternatives or when not to use it.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses one meaningful trait: statuses come back as a flat list without status groups, which prevents an agent from expecting nested structure. It does not mention side effects (none expected) or other response details, but the key caveat is useful.

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 main purpose is front-loaded in the first sentence, and the important caveat about flat statuses is placed in the second. Every word earns its place.

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

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

For a one-parameter, read-only tool with no output schema, the description covers what is returned (rows and statuses) and flags a likely surprise (flat list without groups). It could be more explicit about row representation, but it is largely sufficient for correct invocation.

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

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

Schema description coverage is 100%; the schema already documents boardId as 'ID van het board.' The description adds no parameter-specific context beyond this, so it meets the baseline for schema-driven parameter clarity but does not exceed it.

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

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

The description uses a specific verb 'Geeft' (returns) and identifies the resource: rows and statuses of a board. It clearly differentiates from sibling tools like list_boards by focusing on internal board structure, though it does not explicitly name alternatives.

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

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

The description implies the tool should be used when you need a specific board's rows and statuses, but it provides no explicit when-to-use guidance, no exclusions, and does not reference any sibling tool. The flat-list warning hints at interpretation of results, not at tool selection.

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

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

No annotations are provided, so the description bears the full weight. It clearly implies a read-only operation ('retrieves') and adds useful context about return content, including aggregated values like estimation, tracked time, and budget. However, it does not mention error handling, missing item behavior, or any requirements such as authentication 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 a single, front-loaded sentence with no filler. It places the verb and object at the start, then adds relevant detail about aggregated values, all in a compact phrase.

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

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

For a simple get-by-ID operation with one parameter and no output schema, the description sufficiently conveys what will be returned (all fields and aggregates). It doesn't cover error scenarios or prerequisites, but the low complexity and explicit retrieval semantics make it fairly complete for an agent to invoke.

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

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

The schema already has 100% coverage for the single parameter 'itemId' with its description ('ID van het item'), so no additional details are required. The description doesn't add extra parameter semantics beyond what's in the schema, but that's sufficient given the high schema coverage.

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

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

The description states a specific verb ('retrieves'), a clear resource ('one work item'), and the full scope ('all fields including estimated, tracked time, budget'). This distinguishes it from the sibling tools like search_items, which returns multiple items, and get_item_activity, which focuses on activity data.

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

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

The description provides no explicit guidance on when to use this tool versus the alternatives (e.g., search_items, get_item_activity). It merely describes what the tool does; the agent must infer the use case from the name and behavior without any direct comparison or exclusions.

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

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

With no annotations present, the description carries the behavioral disclosure burden. It reveals a non-obvious API trait: activity is offered per board, not per item, and requires client-side filtering. It also states the output substance (status changes and who worked). It does not cover pagination or output format, but the schema already documents limit defaults.

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 with no filler. The first sentence front-loads the core function and output content, and the second delivers the essential filtering caveat. 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 read-only activity-list tool with a fully described schema and no output schema, the description covers the core operational need: what it returns, the board scope, the time period, and the filtering caveat. It could be slightly more explicit about the response shape, but that is not a significant blocker.

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

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

Schema description coverage is 100%, so the schema already fully documents all four parameters. The description adds thematic context about 'periode' and 'board' but does not need to repeat parameter details. Baseline 3 is appropriate because the description adds no parameter-level meaning beyond what the schema provides.

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

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

The description uses a specific verb ('Geeft') and resource ('item-activiteiten op een board binnen een periode') and clarifies exactly what kind of data is returned: status changes and who worked on items. It also distinguishes itself from per-item tools by explicitly noting Teamhood exposes this per board, not per item.

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

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

The description gives clear context: use this to retrieve board-level item activity within a date period. It also provides an important usage caveat — filter the results yourself for a specific item — which helps an agent avoid expecting per-item granularity. It does not name an alternative sibling tool, but the guidance is sufficient for correct selection.

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

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

No annotations are provided, so the description carries the full burden. It discloses a key behavioral trait: each timestamp includes both raw UTC and local date/time to avoid midnight misclassification. However, it does not mention pagination, output structure, or any side effects. For a read operation, it's somewhat adequate but not comprehensive.

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

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

The description is concise, with two sentences. The first sentence states the core purpose and filter option, the second provides a usage context. It is front-loaded and every sentence earns its place without redundancy.

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

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

The tool has no output schema, so the description should ideally explain the return structure. It mentions timestamps include local date/time and that groupByDay groups results, but does not describe the overall response shape, error cases, or pagination. For a tool with 5 parameters, this is a moderate gap, though not severe.

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 parameters are already documented in the schema. The description adds no additional parameter semantics beyond what's already there. It does not explain parameter formats or relationships beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool returns registered hours over a period, optionally filtered by user. It names the specific resource (time logs) and distinguishes itself from sibling tools like board/list/item retrieval. The mention of handling local time zones further clarifies its purpose.

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

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

The description gives a concrete use case: 'Gebruik dit om te zien wat er al geboekt staat voordat je nieuwe uren voorstelt' (use to check booked hours before proposing new ones). It implies when to use but does not explicitly exclude alternatives or mention when not to use it. Still, the guidance is helpful for an agent.

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

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

With no annotations, the description carries full behavioral disclosure burden. It says 'gives' (geeft), implying a read-only retrieval, but it does not explicitly state side-effects, permissions, pagination, or any limit. The absence of this additional information leaves the tool behavior under-specified.

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 compact sentence carries the entire description, stating the resource, scope, and output fields with no filler. It is well-structured and front-loaded, covering the key details efficiently.

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

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

The description states what the result includes (board IDs and names) and it is a simple single-parameter list tool. It lacks details like sorting or pagination, but these are not essential for an agent to call it incorrectly. An output schema is absent, so the description's mention of ID and name is sufficient to set expectations.

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

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

The input schema has 100% description coverage for workspaceId ('ID van de workspace'). The tool description only restates this by saying 'within a workspace', adding no new meaning beyond the schema. Baseline of 3 applies since the description does not enhance the parameter understanding.

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

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

The description clearly states the action ('Geeft' = gives/lists) and resource ('boards within a workspace') and specifies that the result includes each board's ID and name. This distinguishes it from sibling tools like teamhood_list_workspaces (lists workspaces) and teamhood_get_board_structure (for board details structure).

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

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

There is no guidance on when to use this tool over its alternatives. The description only states what the tool does; it does not mention alternative tools or conditions (e.g., 'for a detailed board structure, use teamhood_get_board_structure').

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

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

No annotations are provided, so the description carries the burden. It discloses that this is a list/read operation, the returned fields, and that last activity date is only provided 'waar beschikbaar'. It does not mention pagination, sorting, or whether filtering is server- or client-side, but the basic behavior is transparent enough.

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 first states what the tool returns is front-loaded, the second gives the main use case. No filler or redundant wording.

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 optional-parameter list tool without an output schema, the description covers enough: the input parameter is documented in the schema دریافت, and the description explains the output fields and common use case. It does not describe limits or response shape, but 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?

The schema already fully documents the single optional 'search' parameter as a case-insensitive name/email filter. The description adds no additional parameter meaning, but with 100% schema coverage the baseline of 3 is appropriate.

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

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

The description states a specific action ('Geeft de gebruikerslijst') and identifies the returned resource (users with name, email, and last activity date). It clearly distinguishes this from sibling tools like list_workspaces or search_items, though it does not explicitly contrast itself with those tools.

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

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

The description explicitly states when to use this tool: to find a colleague's user-ID for time logs. It does not provide exclusions or compare with alternatives, but it gives a clear, practical invocation context.

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

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

No annotations are provided, so the description carries the burden. It discloses that the tool returns all workspaces with their IDs, which is useful. However, it doesn't mention whether this is a read-only operation, pagination behavior, or any rate limits. The description is adequate but not rich.

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

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

Two sentences, front-loaded with the core purpose and the key usage hint. No wasted words.

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

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

For a zero-parameter list tool, the description is complete enough. It tells the agent what it returns and why it matters. It could mention the output format, but with no output schema and no params, the description covers the essential context.

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

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

The tool has 0 parameters, so the schema is trivially complete. The description adds context about what the response contains (workspace IDs), which is helpful. Baseline for 0 params is 4, and the description earns it.

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

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

The description clearly states the tool lists all workspaces in the Teamhood account and includes their IDs. It also distinguishes itself from siblings by noting it's the starting point for most other queries that need a workspace ID.

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

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

The description explicitly says 'Begin hier' (start here) and explains that almost every other query needs a workspace ID, which tells the agent when to use this tool before others. This is strong usage guidance.

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

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

There are no annotations, so the description carries the full burden. It explicitly states the tool is read-only and that writes are impossible, which is useful safety information. However, it does not mention error behavior, authentication constraints, or the shape of the returned data for a raw arbitrary path.

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, front-loaded sentences. The key information (arbitrary GET, fallback purpose, read-only guarantee) is delivered immediately with no filler.

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

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

For a raw passthrough tool, the description covers purpose, scope, and the critical read-only safety property. The absence of an output schema is acceptable for a raw HTTP GET, though a note about unprocessed/raw responses would make it fully complete.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds the base-path example ('/api/v1') and an example path value, but this largely mirrors the schema descriptions rather than adding new meaning.

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

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

The description states a specific verb ('executes a GET') and a specific resource scope ('arbitrary path of the Teamhood API'), and frames the tool as an emergency fallback, which clearly distinguishes it from the named sibling tools for specific endpoints.

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 explicitly says this is meant as an emergency valve when an endpoint has a different name in your environment, giving a clear condition for when to use it over the standard tools. It does not name a specific sibling alternative, but the intent is clear enough for an agent to make a selection.

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

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

No annotations are provided, so the description carries the full burden. It discloses that filtering is client-side, which is a significant behavioral trait affecting performance and result completeness. It also implies a read-only search operation. It could mention pagination or result limits, but the schema already documents maxItems. The client-side filtering disclosure is valuable and goes beyond the schema.

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

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

The description is three sentences with no waste. The primary purpose and use case are front-loaded, and the client-side filtering caveat is placed at the end. 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 search tool with a fully documented schema and no output schema, the description covers the main use case and the key behavioral caveat (client-side filtering). It does not describe the return format, but the fields parameter already explains compact vs full output. The only minor gap is not mentioning that results may be incomplete if the workspace is large, though the client-side filtering warning implies it.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters. The description adds context for the search use case (checking for existing tickets) but does not add meaning beyond the schema. Baseline 3 is appropriate because the schema does the heavy lifting.

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

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

The description states a specific verb ('Zoekt'), a clear resource ('work items (tickets) in een workspace'), and a concrete use case: checking whether a ticket already exists and retrieving its ticket number and exact title. It also distinguishes itself from siblings by mentioning workspace-scoped search and client-side filtering, which helps an agent tell it apart from teamhood_get_item or teamhood_raw_get.

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 explicit context for when to use this tool: to check for an existing ticket and to retrieve the ticket number and exact title. It also warns about client-side filtering and advises keeping the workspace scope limited for large accounts. It does not explicitly name alternatives or say when not to use it, but the use case is clear enough.

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