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

With no annotations at all, the description carries the full burden of behavioral disclosure, and it discloses almost nothing. It does not say whether this requires admin/owner permission, whether it is idempotent when the user is already a member, what happens on failure, or whether the user is invited versus directly attached.

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 zero filler or redundancy. It is efficiently structured, but the brevity reflects under-specification rather than disciplined economy.

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 three-parameter required-field mutation with no annotations and no output schema, so the description must explain permissions, failure modes, and side effects. It says nothing about any of these, leaving an agent unable to predict what happens when the membership already exists or the role is invalid.

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%: teamId and userId are documented as UUIDs and role carries an explicit three-value enum with a description. The description adds nothing beyond the schema, so the baseline of 3 applies.

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

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

The sentence 'Add a user to a team' names a verb and two resources, but it is essentially a restatement of the tool name add_team_user and adds no scope detail. It does not distinguish this operation from siblings such as update_team_user, remove_team_user, or join_team, so an agent must infer the difference from names alone.

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 instead of update_team_user (changing a role) or remove_team_user (revoking access), which are the obvious near-miss alternatives in the sibling list. No preconditions, such as the user or team needing to already exist, are stated.

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

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

No annotations are provided, so the description carries the full behavioral-disclosure burden. It states the operation but omits authentication requirements, partial-failure behavior, idempotency, rate limits, and response format for a write/ingestion tool.

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

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

The description is a single front-loaded sentence with no filler. It states the core operation 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 schema is rich, including nested event fields and batch size constraints, which supports basic invocation. However, with no annotations and no output schema, the description should do more to explain batch response or partial-success behavior, leaving a meaningful gap for an ingestion 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 coverage is 100%, so the detailed nested event fields and min/max item limits are already documented in the schema. The description does not add parameter meaning beyond the schema, 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?

The description uses a specific verb ('Send') and states the exact resource/scope: multiple events or pageviews in one batch request. The words 'multiple' and 'batch' distinguish it from the single-event sibling send_event without requiring the schema to be opened.

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 batching context implies when to use this tool rather than send_event, but there is no explicit alternative named, no exclusion criteria, and no prerequisites. Usage is inferable but not documented.

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

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

No annotations exist, so the description carries the full burden for a state-changing operation. It doesn't say whether the pending secret is discarded, whether it errors when no setup is pending, whether an already-enabled 2FA is unaffected, or what authorization is required. Only the surface intent is conveyed.

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 phrase with no filler. The scope qualifiers ('pending', 'self-hosted') are exactly the disambiguating words and nothing 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 zero-parameter, simple cancellation this is minimally sufficient — the agent knows what it does. But with no annotations and no output schema, it says nothing about failure modes (no pending setup) or the effect on existing 2FA configuration, which a caller should know before invoking.

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

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

The schema has zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No misleading hints about inputs are given.

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 plus resource and scope: 'Cancel pending self-hosted Umami 2FA setup'. That clearly implies aborting an in-progress enrollment, which separates it from disable_two_factor and confirm_two_factor_setup by implication. It never names those siblings explicitly, so it lands at 4 rather than 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 word 'pending' implies the precondition (call only when a setup has been initiated but not confirmed), but the description never states that condition or names initiate_two_factor_setup / confirm_two_factor_setup / disable_two_factor as the alternatives. An agent must infer the workflow position.

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

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

No annotations exist, so the description carries the full behavioral burden, yet it only restates the name. It does not disclose whether the clone copies parameters/description, whether the source board is modified, what the default new-board name is, or what the response 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?

Five words is technically concise but far below the size needed for a mutation tool with four undocumented parameters. This is under-specification rather than efficient writing.

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 mutating tool with no annotations, no output schema, four parameters (one a nested object) and zero schema documentation leaves the agent with essentially nothing beyond the name. The definition is not complete enough to call correctly.

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

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

Schema description coverage is 0% across 4 parameters, including a nested free-form 'parameters' object, and the description adds nothing. An agent cannot learn that boardId is the required source, or that name/description/parameters are optional overrides for the copy.

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?

'Clone an Umami board' states a specific verb and resource, so an agent immediately knows the operation. It does not differentiate from siblings such as create_board or update_board, nor explain what the clone copies, so it stops short of a 5.

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

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

There is no guidance on when to clone versus create_board, no prerequisites (e.g. permissions on the source board), and no exclusions. The agent must infer the scenario entirely from the name.

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

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

With no annotations, the description carries the full burden; it does add the useful precondition that a login must already be pending and 2FA must have been demanded. It says nothing about failure behavior (invalid or expired code), whether the code is single-use, or what the caller receives once the login completes.

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, front-loaded with the action and immediately followed by the triggering condition. Nothing is wasted or repeated from structured fields.

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

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

For a two-parameter authentication tool with no output schema, an agent still lacks knowledge of what a successful completion yields (session established?) and how errors surface. The precondition is covered, but the post-condition is not.

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 parameters are documented in the schema, including the enum and the six-digit format note. The description adds no parameter-level 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?

The description names a specific verb and resource (complete a pending login) plus the Umami context, so it is immediately distinguishable from CRUD-style siblings. It stops short of explicitly naming how it differs from other auth siblings such as verify_auth or confirm_two_factor_setup, but the 'pending login + 2FA required' framing is precise.

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

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

It gives an explicit trigger: call this only after a tool reports that 2FA is required, which is a real routing signal. It does not state what to do instead when no login is pending (e.g. verify_auth) or when the user abandons the flow (cancel_two_factor_setup), so exclusions are missing.

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 usefully discloses that one-time backup codes are returned, but it omits whether confirming setup enables 2FA, what permissions are required, whether backup codes are shown only once, and how invalid or expired tokens are handled for this security-sensitive mutation.

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

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

The description is a single front-loaded sentence with no filler. It states the action and the key outcome 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?

With no annotations, no output schema, and an undocumented required parameter, the description should do more for a security-sensitive state-changing operation. It mentions backup codes but omits prerequisites, token semantics, state effects, and backup-code handling details needed for confident invocation.

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

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

The schema has one required parameter, token, with zero description coverage. The description does not explain that token should be a six-character TOTP code or how it relates to the confirmation flow, leaving the agent to infer its meaning from the tool name and min/max length constraints.

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

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

The description states a specific verb and resource: 'Confirm self-hosted Umami 2FA setup', and adds the outcome 'receive one-time backup codes'. This is clearly distinct from siblings like initiate_two_factor_setup, cancel_two_factor_setup, and complete_two_factor_login, though it does not explicitly name those 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 phrase 'Confirm ... setup' implies this should be used after initiating 2FA setup, but the description does not state prerequisites, when-not-to-use conditions, or direct alternatives such as complete_two_factor_login for login confirmation. Usage is implied rather than explicitly guided.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses that this is an add/mutation operation and requires Umami 3.4+, but does not explain permissions, whether the note appears immediately, default behavior for allDay, or possible failure modes.

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

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

The description is a single front-loaded sentence with no wasted words. It conveys the action, object, and version requirement efficiently.

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

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

For a create/mutation tool with no annotations, no output schema, and only 25% schema description coverage, the description is too sparse. It omits behavioral details, parameter semantics, and any indication of what happens after creation.

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

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

Schema description coverage is only 25%, so the description should compensate but does not. It implies websiteId, date, and note via 'website's charts' and 'dated note,' but never explains allDay or the note constraints, leaving key parameter meaning to the sparse schema.

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

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

The description states a specific verb and resource: 'Add a dated note to a website's charts.' The Umami 3.4+ qualifier adds useful scope. It does not explicitly differentiate from sibling tools like update_annotation or delete_annotation, but the create intent 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?

The description implies the tool creates an annotation, but gives no explicit guidance on when to use it versus list_annotations, update_annotation, or delete_annotation. No prerequisites or exclusions are stated.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it only implies mutation via "Create." It does not state permission/ownership requirements, what the `parameters` object does, whether the board is team-scoped, or what happens on duplicate names.

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 sentence is technically concise, but here brevity reflects under-specification rather than economy — nothing is front-loaded beyond a restatement of the tool name.

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 five-parameter mutation tool with a nested object, an enum, no annotations, and no output schema needs far more than a four-word description. Neither the enum semantics nor the required nested payload are addressed anywhere.

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% across five parameters, including an opaque free-form `parameters` object and a `type` enum with five unlabeled values. The description adds no meaning to any of them, leaving the agent entirely dependent on bare property names.

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

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

The description names a specific verb and resource ("Create" + "Umami board"), which is enough to distinguish it from get_board/update_board/delete_board by name alone. However, it never explains what an Umami board is or how it relates to the five board types in the schema, so the purpose is only vaguely understood.

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 create_website, create_link, create_pixel, or clone_board, nor any mention of prerequisites such as team membership. The agent must infer usage entirely from the tool name.

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

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

No annotations are provided, so the description carries the full burden, yet it discloses only that this is a mutating create. It does not mention auth/permission requirements, slug-uniqueness or collision behavior, whether the slug is used as a redirect path, or what the response contains (no output schema). 'Tracked' hints that the link records analytics events, which is the only real behavioral signal.

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?

It is a single front-loaded sentence with no filler, so there is no verbosity problem. The issue is the opposite: it is under-specified rather than concise, so the brevity earns no more than a middling score.

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

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

For a four-parameter mutation tool with zero annotation coverage, no schema descriptions, and no output schema, the definition leaves the agent without enough information to call it correctly. Missing are required-parameter semantics, slug rules, teamId scoping, error/conflict behavior, and return 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?

Schema description coverage is 0% and the description names none of the four parameters. The agent gets no meaning for url, name, slug (length constraints only), or the optional teamId, and no indication that slug is constrained to 8-100 characters and must presumably be unique.

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?

'Create a tracked link' states a specific verb and resource, and the resource (link) is distinguishable from sibling creators like create_pixel, create_website, or create_share. It stops short of 5 because it says nothing about scope (team vs. personal) or how it differs from the closest siblings, list_links/get_link/update_link.

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 when-to-use guidance at all: no prerequisites (e.g., must provide a slug not already taken), no indication of whether teamId is needed for team-scoped links, and no pointer to alternatives such as create_website_share or send_link_or_pixel_event. The agent must infer usage entirely from the sibling list.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a mutation by saying 'Create,' but does not disclose permissions, uniqueness constraints, side effects, or what happens when name/slug conflict.

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

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

The description is a single front-loaded sentence with no wasted words. However, it is undersized for a creation tool with three parameters and no annotations.

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 mutation tool with no annotations, no output schema, and zero parameter description coverage, the description is not complete enough. It omits required context, side effects, parameter meanings, and response 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?

Schema description coverage is 0% and the description does not explain any of the three parameters. It gives no meaning for name, slug, or teamId, so an agent must infer all parameter semantics from the schema alone.

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

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

The description states a clear verb and resource: creating a tracking pixel. It is enough to separate this tool from sibling read/update/delete pixel operations, though it adds little beyond the tool name.

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

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

There is no guidance on when to use this tool versus list_pixels, get_pixel, update_pixel, or other creation tools. Prerequisites such as team or website context are not mentioned.

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

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

No annotations are provided, so the description carries the full behavioral burden. It states no side effects, no permission requirements, no indication of what happens when 'parameters' doesn't match the selected report type, and no return information — all significant gaps for a write operation creating a persisted object.

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 or repetition. The problem is under-specification rather than verbosity, which is penalized in the other dimensions.

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

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

This is a mutation tool with no annotations and no output schema, and its nested 'parameters' object has polymorphic semantics per report type. None of that is addressed, so an agent has no basis for constructing a valid call beyond the raw schema.

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

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

Schema description coverage is 100%, so every parameter is already documented in the schema, including the ten-value type enum. The description adds nothing beyond the schema — notably it never explains that the required 'parameters' object is report-type-specific, which is the one place extra prose would have real 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?

"Create and save a new report" gives a clear verb and resource, so an agent understands the basic action. But it offers no differentiation from siblings such as update_report, run_report, or create_board, and the 'and save' phrasing adds no scope information.

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 prerequisites (e.g. that websiteId must reference an existing website), and no mention of update_report as the alternative when a report already exists. The agent must infer all routing from the name alone.

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

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

No annotations are provided, so the description must carry the behavioral burden. It never says whether creation is idempotent, whether names must be unique, what permissions are required, or what limits apply to cohorts versus segments. It only repeats the resource being created.

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 no wasted words, but the brevity is under-specification rather than economy—it omits information the agent needs.

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

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

For a mutation tool with nested objects, 4 required params, no annotations, and no output schema, the description is far too thin. An agent cannot know the valid shape or constraints of a segment/cohort creation from this.

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

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

Schema description coverage is 0% and the tool has four required parameters with nested objects. The description contributes nothing about 'parameters', 'match', 'action', 'filters', or the segment-vs-cohort constraints, leaving the undocumented schema to speak for itself.

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') and resource ('saved segment or cohort'), and the type enum in the schema matches. It is implicitly distinguishable from the list/get/update/delete_segment siblings, though the description doesn't explicitly reference them.

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

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

No guidance on when to choose this over alternatives, no prerequisites, no mention of how 'segment' differs from 'cohort'. The agent is left to infer usage entirely from the name.

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

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

No annotations are provided, so the description must carry the full behavioral load, yet it says nothing about access implications (is the share public? does it grant read access?), permission requirements, slug uniqueness, or what happens to the nested `parameters` object. Only the creation intent is conveyed.

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, which is efficient for a list of target types. It errs toward terse rather than bloated, which is the lesser sin.

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 takes 5 parameters including a nested untyped object, has no annotations and no output schema; a one-line description is not enough for an agent to call it correctly. At minimum the meaning of `parameters` and of slug defaults should be stated.

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% across 5 parameters, and the description only echoes the shareType enum values ('website, link, pixel, or board') while leaving entityId, name, slug, and the free-form `parameters` object completely unexplained. For a nested, additionalProperties object this is a serious gap.

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) and resource (share) plus the four entity kinds it can attach to, so the agent knows exactly what the tool produces. It does not, however, distinguish itself from the overlapping sibling create_website_share or explain how it relates to update_share/get_share_by_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?

There is no guidance on when to use this versus create_website_share, when to use list_entity_shares or get_share beforehand, or what prerequisites (existing website/link/pixel/board id, permissions) are needed. The agent must infer all routing from the name alone.

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

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

No annotations are provided, so the description carries the full behavioral burden. It conveys only that the tool mutates by creating, saying nothing about required permission level (team creation is typically admin-gated), name-uniqueness or duplicate-name behavior, or what side effects occur on the caller's account.

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 zero waste. It is efficient, though the brevity reflects under-specification rather than disciplined editing.

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

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

For an unannotated mutation tool with no output schema, the description omits permission requirements, duplicate-name handling, and whether the created team is returned or its ID discoverable. An agent can attempt the call but cannot predict failure modes or follow-up steps.

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% with a single documented 'name' parameter (maxLength 50), so the schema already explains the input. The description adds nothing beyond it, which is the baseline case for fully covered schemas.

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') and resource ('team'), which cleanly distinguishes it from create_website, create_user, and the other create_* siblings. It is clear but adds no scope detail such as whether the caller is auto-added as a member.

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 join_team, list_teams, or get_my_teams, and no stated prerequisites. The agent is left to infer that this is the onboarding path for a brand-new team.

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

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

With no annotations, the description must carry the safety profile, and it does disclose the key authorization constraint (admin only) for a mutation. It stops short of stating side effects, duplicate-username handling, whether the role is freely assignable, or what the call returns.

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?

Six words, zero filler, and the permission constraint is front-loaded. It is efficient but arguably thinner than a mutation tool warrants, which is captured under contextual completeness rather than here.

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 mutation tool with no annotations and no output schema requires the description to explain outcomes, error cases, and side effects. Aside from the admin-only note, none of that is present, leaving real gaps for an agent to call it safely.

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%: username, password (8-255 chars), and role (with an enum) are all documented in the schema. The description contributes nothing about parameter meaning or constraints, 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 user'), which cleanly separates it from sibling operations like update_user, delete_user, and list_users. No explicit sibling naming, but the verb makes the distinction obvious.

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 parenthetical '(admin only)' signals a permission prerequisite for use, which is genuine guidance. However, there is no statement of when to prefer this over alternatives such as add_team_user, nor any exclusion or precondition beyond the admin requirement.

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

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

With no annotations, the description carries the full behavioral burden and delivers almost none of it: nothing about required permissions, what happens on duplicate domains, whether teamId defaults to a personal account, or whether creation is reversible. Only the word 'Create' signals mutation.

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

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

A single front-loaded sentence with no filler. It is efficient, though the brevity reflects under-specification rather than disciplined editing.

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 mutation tool with no annotations and no output schema, the description omits auth requirements, duplicate handling, team scoping semantics, and what a successful response contains. The agent can call it from the schema alone but cannot 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?

Schema coverage is 100%, so every field including name, domain, teamId and shareId is already documented, and the description adds nothing beyond that. Baseline 3 applies 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?

States a specific verb and resource ('Create a new website') and adds the tracking context ('to track in Umami'). It does not distinguish itself from closely related siblings such as create_website_share or transfer_website, but the core action is unambiguous.

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

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

There is no guidance on when to use this versus alternatives, no prerequisites, and no mention of the team-scoped variant implied by the teamId parameter. The agent must infer everything from the sibling list and schema.

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 supplied, so the description carries the full behavioral burden, yet it only implies a write via the verb 'Create'. It says nothing about required permissions or roles, whether the share is public or expiring, what the created share contains, or whether it can be revoked.

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?

It is short but this is under-specification rather than conciseness: a four-word fragment carries no load-bearing information beyond the tool name already visible to the agent.

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

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

A mutation tool with no annotations, an undocumented nested object parameter, no output schema, and a huge sibling set — the description supplies none of the context needed to call it correctly or safely.

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% for three parameters, including a nested free-form 'parameters' object with additionalProperties unspecified. The description does not explain websiteId scoping, what 'name' labels, or what keys the nested object accepts.

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

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

The description 'Create a website share' simply restates the tool name create_website_share, adding no scope, no explanation of what a 'website share' is (public link, embed, permission grant?), and no differentiation from the sibling create_share or list_website_shares.

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 at all on when to use this versus create_share, list_website_shares, get_share_by_id, or update_share. The agent is left to infer the choice purely from names in a very large sibling list.

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

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

No annotations are provided, so the description carries the full behavioral burden. It indicates a delete operation but does not disclose irreversibility, required permissions, side effects, or error behavior.

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

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

The single sentence is concise and front-loaded, but it is too terse for a destructive operation. The version note adds some context but does not compensate for missing operational detail.

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

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

With no annotations, no output schema, and 0% schema description coverage, the one-line description is insufficient for a destructive two-parameter tool. It omits effects, permissions, return behavior, and parameter guidance.

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

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

Schema description coverage is 0%, and the description does not mention websiteId or annotationId or explain their UUID formats. It adds no parameter meaning beyond the raw schema.

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

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

The description states a specific verb and resource: "Delete a website annotation." It is clearly distinguishable from sibling tools like create_annotation, update_annotation, and get_annotation, 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?

There is no guidance on when to use this tool versus update_annotation or other annotation tools, and no prerequisites or warnings are given. Usage is only implied by the phrase "Delete a website annotation."

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure, yet it adds nothing beyond the verb. It does not state whether deletion is permanent or recoverable, whether the board must be empty, what permissions or ownership are required, or what happens to dashboards/links attached to the board.

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 words with zero filler, which is structurally clean and front-loaded. But the brevity is under-specification rather than economical writing, so it does not earn a high score for sizing.

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 an irreversible mutation tool with no annotations, no output schema, and an undocumented parameter. An agent lacks the warning context (permanence, side effects, prerequisites) required to call it responsibly, and the description supplies none of 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?

There is one parameter with 0% schema description coverage, so the description needed to compensate and says nothing about boardId. The schema conveys only that it is a required UUID-formatted string; the description offers no hint about where to obtain it (e.g., list_boards or get_board).

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 phrase 'Delete an Umami board' names a specific verb and resource, and 'Umami' adds a small amount of domain context. However, it is essentially a restatement of the name delete_board, and nothing distinguishes it from sibling delete operations (delete_report, delete_team, delete_link) beyond the noun itself.

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

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

There is no guidance on when to use this versus update_board or delete_website, no preconditions, and no exclusions. The agent must infer everything from the tool name and the sibling list.

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

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

With no annotations, the description carries the full behavioral burden, yet only the word "Delete" signals mutation. It says nothing about whether deletion is permanent, whether link analytics/history are also destroyed, what permissions are required, or whether the operation is recoverable.

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?

It is a single front-loaded sentence with zero wasted words. However, the brevity reflects under-specification rather than efficient communication of the essentials for a destructive operation.

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

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

For a destructive, irreversible-by-implication mutation with no annotations and no output schema, the description omits permissions, side effects, and confirmation behavior. The single parameter is simple, but the risk profile of the tool is entirely undocumented.

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

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

Schema description coverage is 0% and the sole parameter (linkId) is never mentioned in the description. Only the schema's own property name and uuid format communicate its meaning, so the description adds nothing to compensate for the coverage gap.

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 ("Delete" + "tracked link"), which is unambiguous against siblings like delete_pixel or delete_share. It lacks any explicit sibling differentiation or scope statement, but the action 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?

The description gives no guidance on when to use this tool versus alternatives, no prerequisites, and no warning about irreversibility. An agent must infer everything about when deletion is appropriate.

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

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

No annotations exist, so the description carries the full burden for a destructive mutation. It says nothing about permanence, whether historical tracking/metric data tied to the pixel is preserved or lost, required scopes, or what happens when the pixelId does not exist — all material for a delete operation.

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 words, front-loaded and waste-free, but the brevity crosses into under-specification for a destructive tool. Conciseness is achieved by omission rather than by tight writing.

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

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

With no annotations and no output schema, the definition provides no safety, permissions, or failure-mode context for a delete in a family of pixel tools. An agent can guess the effect but not the consequences.

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% for the single required parameter, and the description says nothing about pixelId — not how to obtain one (e.g. via list_pixels), nor that it is a UUID. The schema's type/format hints are the only source of parameter 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?

States a specific verb and resource ('Delete a tracking pixel'), which is unambiguous against siblings like create_pixel, update_pixel or delete_website. It does not differentiate itself from related cleanup actions (e.g. update_pixel to disable, or deleting a link), but the name-plus-description pair leaves no real ambiguity about the operation.

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

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

There is no guidance on when to delete versus update/disable a pixel, no prerequisites, and no warning about irreversibility. The agent must infer everything from the tool name alone.

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

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

No annotations are provided, so the description carries the full burden and it discloses almost nothing. It does not say deletion is permanent/irreversible, does not state which permission or role is required, does not note whether scheduled runs or shares referencing the report are affected, and gives no indication of the response. For a destructive mutation with zero annotation coverage this is a substantial gap.

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

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

A single front-loaded phrase with zero filler. The brevity is not wordiness-driven padding, though the same syllable count could have carried a warning about irreversibility instead.

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 destructive, unannotated, single-parameter tool with no output schema should at minimum say the deletion is permanent and what it affects. Nothing beyond the bare operation is conveyed, so an agent cannot confidently decide whether to call it or warn the user first.

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 reportId parameter is already documented as a UUID, so the description adds nothing but also loses nothing. Baseline 3 applies when the schema does all the work.

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 ("Delete a saved report"), which is enough for an agent to identify the operation unambiguously. It does not differentiate from siblings like delete_dashboard/delete_segment or point to list_reports/get_report for the surrounding workflow, so it stops short of a 5.

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

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

There is no guidance on when to use this versus alternatives such as update_report or simply leaving a report unused, and no mention of prerequisites or confirmation requirements. The agent must infer everything about the appropriate use context from the name alone.

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

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

No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It says 'Delete' but does not state whether deletion is permanent, what happens to related data, or what permissions are required.

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

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

The description is a single, front-loaded sentence with no wasted words. It is appropriately concise, though its brevity contributes to underspecification for a destructive tool.

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

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

Given the tool is destructive, has no annotations, no output schema, and 0% parameter description coverage, the description is incomplete. It identifies the action and resource but omits safety, parameter, and prerequisite context needed to invoke it correctly.

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

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

The schema has 0% description coverage for both required parameters (segmentId and websiteId). The description does not mention either parameter or explain how they identify the segment, leaving the agent no semantic guidance beyond the schema's property names.

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

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

The description states a specific verb ('Delete') and resource ('saved segment or cohort'), making the action clear. It distinguishes itself from segment siblings like list_segments, create_segment, get_segment, and update_segment by the verb, 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?

There is no guidance on when to use this tool versus update_segment or when deletion is appropriate. For a destructive operation, the description provides no context on prerequisites, confirmation, or irreversibility.

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

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

Annotations are absent, so the description carries the full burden. It discloses the storage-backend limitation but says nothing about whether deletion is permanent, required permissions, what happens if the session is already gone, or whether related data is affected.

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 no filler. Brevity is appropriate, though the single sentence leaves no room for any of the missing guidance.

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

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

A destructive mutation tool with no annotations, no output schema, and zero parameter documentation needs far more description than this. The agent lacks the safety and scoping context required to invoke deletion confidently.

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

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

Schema description coverage is 0%, so the description must compensate — and it does not. It implies sessionId identifies the session but never explains websiteId, its format (uuid), or why both are required to disambiguate a session.

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 ('Delete one session') and adds a scoping qualifier about self-hosted relational storage. It clearly separates itself from read siblings like get_session and get_sessions, though it does not explicitly distinguish itself from the other delete_* tools beyond the resource name.

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

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

No guidance on when to use this versus alternatives, no prerequisites, no warnings about irreversibility. The only contextual hint is the storage-backend restriction.

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 disclosure burden. It only restates that the operation deletes a share, without explaining permanence, required permissions, side effects, or error behavior for a destructive mutation.

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

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

The description is a single front-loaded sentence with no wasted words. However, its brevity comes at the cost of under-specification, so it is concise but not adequately informative.

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

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

For a destructive tool with no annotations, no output schema, and 0% schema description coverage, the description is too sparse. It should clarify prerequisites, irreversibility, and what the caller needs to know before deleting a share.

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

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

Schema description coverage is 0%, so the description must compensate for missing parameter semantics. It does not mention shareId at all, adding no meaning beyond the schema's name, UUID format, and required flag.

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: deleting a managed share. This is clear enough to distinguish it from read or update share operations, although it does not explicitly contrast with siblings such as update_share or get_share_by_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 gives no guidance on when to use this tool, when not to use it, or what alternatives exist. It implies a destructive operation but leaves all usage context to inference from the name.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a destructive mutation via 'Delete' but does not state irreversibility, required permissions, side effects on associated resources, or confirmation 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?

The description is a single, front-loaded sentence with no wasted words. However, its extreme brevity leaves important context unstated, so it is minimally adequate rather than optimally structured for a destructive operation.

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

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

With no annotations and no output schema, the description should provide enough context for a destructive tool, but it omits effects, safety considerations, and post-deletion behavior. The schema covers the parameter, but the definition is behaviorally incomplete.

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

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

Schema coverage is 100%, so the single teamId parameter is fully documented in the schema. The description adds no additional parameter semantics, which is acceptable at baseline when the schema already does the work.

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 ('Delete a team'), making the operation unambiguous. It does not explicitly distinguish itself from siblings such as update_team or remove_team_user, but the action is clear enough to select correctly.

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

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

There is no guidance on when to use this tool versus alternatives, no prerequisites or permissions mentioned, and no warning about when not to use it. The agent must infer everything from the tool name and schema.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose one meaningful trait: the admin-only authorization requirement. However, it says nothing about irreversibility, whether the deletion cascades to the user's websites/team memberships/shares, or whether any confirmation step exists — all critical for a destructive operation.

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 clause that is entirely front-loaded with the action and resource; nothing is wasted. It is efficient, though the brevity reflects under-specification rather than disciplined editing.

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

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

For an irreversible, admin-restricted mutation with no annotations and no output schema, the definition is too thin. An agent learns only that it deletes a user and needs admin rights — not what is destroyed alongside the user, whether the operation can be undone, or what the response confirms.

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?

Single parameter (userId) with 100% schema description coverage, so the schema already documents that a user UUID is required. The description adds no formatting, lookup, or validation guidance beyond the schema, which is the expected baseline for a fully-described one-parameter tool.

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 ("Delete a user") that clearly separates it from the other delete_* siblings such as delete_team, delete_website, delete_report. The scope is unambiguous, though it does not explicitly name the sibling alternatives an agent might confuse it 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?

The only usage signal is the parenthetical "(admin only)", which is a permission prerequisite rather than guidance. There is no statement of when to prefer this over remove_team_user, update_user, or delete_team, nor any warning about prerequisites beyond admin rights.

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 provided, and the description lacks disclosure of important behavior such as irreversibility, permission requirements, or cascading effects on associated data.

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

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

The description is a single efficient sentence but under-specified for a deletion tool; could include more context without being verbose.

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

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

For a simple delete tool, the description is too brief. It omits crucial context like post-deletion effects or how it differs from reset_website, given no output schema or annotations.

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?

Input schema covers 100% of parameters with a clear description. The tool description adds no new meaning beyond the schema, resulting in baseline score.

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 (Delete) and the resource (website from Umami), distinguishing it from siblings like create_website or update_website.

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

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

No guidance on when to use this tool versus alternatives like reset_website or when not to use it (e.g., irreversible deletion).

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 at all, the description carries the full burden for a destructive security mutation and mostly fails: it doesn't state that the caller must re-authenticate with password and a 6-digit TOTP, whether this affects only the caller or a target user, or whether the change is reversible. The only behavioral hint is the vague "when policy permits" failure condition.

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 verb and resource come first. It is efficiently written but simply too thin to earn a 5.

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

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

For an unannotated, irreversible security-settings mutation with two undocumented required parameters and no output schema, an agent needs prerequisites, effects, and failure modes that are entirely absent. The definition is not complete enough to invoke confidently.

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

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

Schema description coverage is 0% and the description mentions neither parameter, so nothing explains that "password" is the account credential or that "token" is a 6-character TOTP (the 6/6 length constraint is visible in the schema only). Parameter names are partly self-evident, which keeps this above 1, but no compensating semantics are added.

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 ("Disable ... 2FA") plus the product scope ("self-hosted Umami"), which is enough to distinguish it from setup tools like initiate_two_factor_setup or confirm_two_factor_setup. It does not, however, distinguish it from the closely related cancel_two_factor_setup or reset_user_two_factor.

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?

"When policy permits" gestures at a precondition but never says what policy, who can check it, or what happens if it blocks. There are three sibling 2FA-reset/cancel tools and the description offers no guidance on which to pick, leaving the agent to guess.

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

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

With no annotations, the description carries the full burden, and it does disclose the return encoding and format (base64-encoded ZIP containing CSVs), which is genuinely useful and non-obvious. It says nothing about permissions required, export size limits, whether the ZIP is a synchronous snapshot, or how pagination affects the exported dataset, which are material for a potentially expensive bulk operation.

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 zero filler; the key output characteristic is stated immediately. Nothing redundant is included.

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-parameter, zero-coverage, unannotated tool with no output schema, the description is far too thin. It omits timestamp units, the meaning of pagination on an export, the analytics scope of the CSVs, and any size/limit behavior an agent would need to call this safely.

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% across 5 parameters, and the description supplies no parameter meaning at all. Critically, startAt/endAt are untyped integers with no hint about units (epoch seconds vs milliseconds), and page/pageSize on an 'export' tool is ambiguous — whether they paginate the export itself or bound the underlying data is unexplained.

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 ('Export website analytics') and even the output artifact ('base64-encoded ZIP of CSV files'), so an agent knows exactly what it produces. It does not, however, contrast itself with the many sibling read tools (get_stats, get_metrics, get_pageviews) that also return analytics data, so the boundary is left 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?

There is no statement of when to choose this over get_stats/get_metrics/get_pageviews, nor any prerequisite context such as required scope or expected export size/cost. The agent must infer that 'export' means bulk retrieval rather than the paginated read endpoints.

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 provided, so description should disclose behavioral traits. It fails to define 'active visitors' (e.g., time window, uniqueness), does not mention whether it is read-only, and omits any rate limits or authorization 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?

Single sentence, 10 words, no redundancy. Every word serves a purpose.

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

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

For a simple metric tool with one parameter and no output schema, the description is minimally adequate but lacks definition of 'active' and any context on real-time 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?

With 100% schema coverage, the baseline is 3. The description adds no further meaning beyond the schema's description of websiteId as 'Website UUID'.

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?

Description clearly states the tool retrieves the number of currently active visitors for a website, using a specific verb 'Get' and resource 'active visitors'. It distinguishes itself from sibling tools like get_pageviews or get_stats by focusing on active visitor count.

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

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

No guidance on when to use this tool over alternatives. Sibling tools such as get_realtime or get_stats could overlap, but description provides no context for 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?

With no annotations, the description carries the full behavioral burden, but it only implies a read operation through the verb 'Get' and notes a version requirement. It does not disclose required permissions, behavior when the annotation is missing, whether the response is cached, or other operational traits.

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. However, its brevity reflects under-specification rather than fully earned conciseness, since useful context could have been added without bloat.

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 ID-based retrieval tool with no output schema and no annotations, the description is too sparse. It identifies the resource and a version compatibility note but omits usage boundaries, parameter meaning, return expectations, and permission or error 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?

Both required parameters have 0% schema description coverage, and the description does not mention websiteId or annotationId at all. The parameter names are present in the schema, but the description adds no meaning about scoping, valid values, or lookup behavior.

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 a website annotation'. It is clear that this retrieves one annotation, but it does not explicitly distinguish the operation from sibling reads such as list_annotations or explain the ID-based lookup.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention list_annotations, prerequisites, permissions, or error conditions, leaving usage entirely implied by the tool name.

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

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

No annotations are provided, so the description carries the full burden, and it discloses nothing beyond the bare verb. It does not say the operation is read-only, whether the board must exist, whether it needs authentication or team membership, or what an error looks like for an unknown boardId.

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 phrase with no filler and the core verb-resource pair front-loaded. It is efficient, though the brevity comes at the cost of substance rather than from disciplined editing.

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

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

With no annotations, no output schema, and an undocumented required ID parameter, the description leaves nearly everything an agent needs unstated. A single-sentence lookup tool can be simple, but this one is under-specified even for that.

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% for the single required boardId parameter, and the description does not compensate by explaining that it is the board's UUID identifier or where to obtain one. The schema only supplies type and format.

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 an Umami board" names a verb (get) and a resource (board), so the basic operation is inferable. But it gives no scope detail and does nothing to distinguish it from the many sibling board tools (list_boards, get_team, list_team_boards), nor does it indicate retrieval is by ID rather than by 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?

There is no when-to-use guidance, no mention of an alternative such as list_boards, and no prerequisites stated. The agent must infer from the sibling names alone that this is the single-board lookup by 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?

No annotations are provided, so the description carries the full burden. It does not disclose any behavioral traits beyond the basic purpose (e.g., read-only, auth requirements, rate limits), leaving ambiguities about side effects.

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

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

The description is a single, focused sentence that immediately conveys the core functionality. It contains no extraneous information and is efficiently front-loaded.

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

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

For a simple tool with one parameter and no output schema, the description is adequate but could be more informative about the return value (e.g., whether it returns a range object or just min/max dates).

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% coverage for the single parameter 'websiteId' with a description 'Website UUID'. The tool description adds no additional meaning beyond what the schema already provides, resulting in a baseline score.

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

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

The description clearly states the action ('Get') and the resource ('date range of available data for a website'). It is specific enough to distinguish from most sibling tools, though it does not explicitly contrast with similar get_* operations.

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

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

The description implies usage when needing the time span of available data, but provides no guidance on when not to use this tool or specific alternatives among many similar get_* tools.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Get' implies a read, but the description does not state read-only behavior, side effects, error conditions, or whether the result is empty when no custom data exists.

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

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

The description is a single front-loaded sentence with no wasted words. It is appropriately sized for a simple two-parameter lookup 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 simple read-by-ID tool with fully documented parameters, the description is minimally sufficient for invocation. However, because there are no annotations and no output schema, it could say more about the returned custom-data shape and error 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?

Schema description coverage is 100%, and both required parameters are documented in the schema. The description does not add parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

The description states a clear verb and resource: getting custom data attached to one event. The singular 'one event' distinguishes it from aggregate event-data siblings, though it does not explicitly name an alternative tool.

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

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

The phrase 'one event' hints at looking up a single event, but there is no explicit guidance on when to use this versus get_event_data_values, get_event_data_properties, or other event-data siblings. No prerequisites or exclusions are stated.

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

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

No annotations are provided, so the description carries the full burden. 'Get' implies a read, but the description says nothing about aggregation behavior, whether counts are scoped to the date range, rate limits, permissions, or result shape for what appears to be a time-bounded analytics query.

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 compact sentence, front-loaded with the verb and resource, with the parenthetical clarification placed immediately. The phrase 'event data events' is slightly redundant but the sentence earns its 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 read-only, schema-complete query tool with no output schema, the description is minimally sufficient to attempt a call. It falls short of being complete given the dense cluster of event siblings that require differentiation for reliable selection.

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 (websiteId, startAt, endAt, event, filters) are documented in the schema itself. The description adds no syntax, defaults, or semantics for the nested 'filters' object beyond what the schema states, so baseline 3 applies.

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

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

The description states a verb ('Get') and a resource ('event data events'), and the parenthetical narrows it to custom event names and counts for a website. However, it does not distinguish this from closely related siblings like get_events, get_event_data_fields, get_event_data_values, or get_event_data_stats, so an agent must guess which event query to select.

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 prerequisites, and no mention of alternatives among the many event-related siblings. The 'for a website' phrase hints at context but does not route the 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?

No annotations are provided, so the description carries the full behavioral burden. It does disclose the return content (property keys and their data types), which is the most useful behavioral fact for a discovery call, but it says nothing about permissions, read-only nature, pagination, or scope of the time window.

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 zero filler; the parenthetical pays for itself by clarifying the return value. Nothing is wasted or 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?

For a moderate-complexity read tool with a fully documented schema and no output schema, the description covers purpose and return content adequately. The only meaningful gap is the absence of routing guidance versus sibling event-data 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%, so all five parameters (websiteId, startAt, endAt, eventName, filters) are already documented in the schema. The description adds no syntax, format, or semantics beyond what the schema provides, 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?

Specific verb+resource: 'Get event data fields (property keys and their data types) for a website.' The parenthetical clarifies the return shape, which helps distinguish it from sibling read tools like get_event_data_values or get_event_data_properties. However, it never explicitly states how it differs from those near-identical siblings, so it stops short of a 5.

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

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

There is no when-to-use guidance, no exclusions, and no mention of the many sibling tools (get_event_data_properties, get_event_data_values, get_event_data_stats) that an agent must choose between. Usage must be entirely inferred from the name.

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

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

With no annotations, the description carries more burden, but it does identify this as a read-style retrieval and says the output contains property names and data types. It does not disclose permissions, rate limits, pagination, or how filters affect results.

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

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

The description is a single front-loaded sentence with no filler. It is appropriately sized for a straightforward metadata retrieval 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?

The description covers the basic return content and website scope, which is enough for a simple getter with a fully described schema. However, given many similarly named sibling tools and no annotations, it leaves the agent without guidance on when this tool is preferred over alternatives.

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 websiteId, startAt, endAt, and filters. The description adds only that the result is website-scoped and does not explain parameter semantics beyond the schema.

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

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

The description names a specific verb and resource: it gets custom-event property names and their data types for a website. This is clear, but it does not distinguish itself from closely named siblings such as get_event_data_fields or get_session_data_properties.

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 exclusions, and no alternatives. An agent must infer from the name alone that this is the metadata-discovery tool rather than a values, fields, stats, or events 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?

No annotations are provided, so the description carries the full burden and largely fails: beyond 'Get' implying a read, it says nothing about permissions needed, whether the filters object constrains results, how large the date window can be, or what the summary response looks like. The only behavioral hint is 'summary counts', which at least tells the agent not to expect raw event rows.

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 or repetition. It is arguably too terse rather than padded, but nothing in it wastes 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 5-parameter aggregation tool with a nested filters object, no annotations, and no output schema, one sentence is insufficient — the agent cannot tell what 'summary counts' contains (unique events? total events? per-event breakdown?) or how filters scope the result.

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

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

Schema description coverage is 100% — websiteId, startAt, endAt, event, and filters are all documented in the schema, so the description needn't repeat them. It adds nothing beyond the schema (e.g., how 'filters' interacts with 'event' is unspecified), so 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 ('Get') and resource ('event data statistics') and adds the parenthetical 'summary counts', which distinguishes it from sibling read tools like get_event_data_events or get_event_data_values that return rows rather than aggregates. It stops short of naming those siblings explicitly, so an agent must infer the split.

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 get_stats, get_events, or the other get_event_data_* tools, and no mention of prerequisites, rate limits, or exclusions. The agent is left to guess from the name alone.

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

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

No annotations are provided, so the description carries the full disclosure burden, yet it says nothing about authorization requirements, pagination, result ordering, limits, or what happens with an empty property. It only implies a read/aggregate operation, which is the minimum an agent could guess from the name.

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

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

A single front-loaded sentence with no filler; the parenthetical clarification earns its place. It is efficient but perhaps too terse given the tool's 7-parameter surface.

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 tool with a nested free-form 'filters' object, a raw Umami 'dataType' code, no annotations, and no output schema, the description is far too thin. An agent gets no help on filter key naming, timestamp semantics, or the shape of the returned counts.

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 7 parameters documented, so the baseline is 3. The description reinforces that the aggregation is scoped by 'website' and 'specific property', but adds no syntax or semantics for filters, dataType, or eventName beyond what the schema already states.

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 event data values') and disambiguates the payload with a parenthetical ('aggregated counts for a specific property'), which is more informative than the name alone. However, it never distinguishes itself from close siblings like get_event_values, get_event_data_properties, get_event_data_fields, or get_session_data_values, so the agent still has to guess which one to pick.

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 statement of when to use this tool versus the many adjacent event-data tools, and no prerequisites or exclusions. The only implicit signal is 'aggregated counts', which a reader must infer selects this over the raw-listing siblings.

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

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

With no annotations, the description carries the full behavioral burden. 'List' implies a read, but the description does not state whether this is read-only, how pagination parameters interact (page, pageSize, maxResults), what the return shape is, or any rate/permission constraints.

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 well-formed sentence that is front-loaded and free of padding. It is appropriately sized, though 'current Umami v3 filters' is slightly jargon-heavy.

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 complex 10-parameter query tool with a nested filters object, no annotations, and no output schema. The description does not explain return fields, pagination limits, how maxResults and pageSize interact, or what happens when filters conflict with top-level path/event/search parameters.

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 70%, so the schema already documents most parameters including the nested 'filters' object. The description only repeats that filters and pagination exist without adding format, examples, or 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?

States a specific verb and resource: 'List event rows for a website.' The mention of Umami v3 filters and pagination clarifies the scope, but it does not distinguish this from closely named siblings such as get_event_data_events, get_event_series, or get_event_values.

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

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

There is no explicit guidance on when to use this tool versus alternatives like get_event_data_events, get_event_series, get_event_data_values, or get_stats. The phrase 'current Umami v3 filters' is vague and does not help an agent choose between event-related siblings.

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

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

No annotations are provided, so the description carries the full burden, yet it discloses nothing about the read-only nature, auth requirements, rate limits, default grouping behavior, or how many series/buckets are returned. Only the bare purpose is conveyed.

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 short sentence with no filler, front-loading the core purpose. It is efficient, though its brevity contributes to the gaps in other dimensions rather than wasting 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?

With 9 parameters, a nested free-form filters object, no output schema, and no annotations, the description should explain what the response looks like (series points bucketed by unit) and how filters interact with event/path. None of that is present, leaving the agent guessing about result 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?

Schema description coverage is 89%, so nearly every parameter (websiteId, startAt, endAt, timezone, event, path, unit, filters) is already documented in the schema. The description adds no extra meaning such as default unit or filter semantics, 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 ('Get event metrics over time (event series data)') scoped to a website, which an agent can distinguish from bulk event listings like get_events. However, it never names or contrasts any sibling such as get_metrics, get_stats, or get_website_charts, leaving the boundary fuzzy.

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 when-to-use guidance, no prerequisites, and no exclusions. An agent cannot tell from the text whether this is the right choice versus get_events, get_event_data_stats, or get_metrics for a time-series request.

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

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

With no annotations, the description carries the full burden. "Get" implies a read, but it does not disclose whether results are paginated, capped, sorted, or permission-gated, nor does it explain how the nested filters object affects results. For a 6-parameter analytics query tool, this is a significant gap.

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

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

A single front-loaded sentence with no filler or redundancy. It is efficient, though arguably too terse given the tool's parameter complexity.

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 no annotations mean the description must explain behavior, but it does not describe return shape, ordering, limits, or the nested filters semantics. For a required-4-parameter analytics tool with a nested object parameter, this leaves core call-time questions unanswered.

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 every parameter and the type enum are documented in the schema itself; baseline 3 applies. The description adds only the loose framing that returned values are event or session properties, and does not clarify how search, filters, or the type enum interact.

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

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

The description states a specific verb ("Get") and resource ("event or session property values") scoped to a website, so an agent understands the basic operation. It does not differentiate itself from closely-named siblings such as get_event_data_values, get_session_data_values, or get_event_data_properties, leaving overlap unresolved.

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

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

No guidance on when to use this tool versus get_event_data_values, get_session_data_values, or get_metrics. There is no mention of prerequisites, exclusions, or decision criteria, so the agent must infer selection from the name alone.

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

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

No annotations are provided, so the description carries the full disclosure burden. It implies a read-only fetch but says nothing about authentication/scope requirements, behavior on a missing or malformed UUID, or what the response contains. For a zero-annotation tool this is a substantive gap.

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

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

Four words, front-loaded, with zero filler. However, this is brevity through omission rather than efficiency — there is no second sentence adding any clarifying value.

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

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

With no annotations, no output schema, and no parameter documentation, the description is the only explanatory text available and it provides none of the supporting detail. An agent cannot tell what a 'tracked link' record contains or how failures manifest.

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

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

Schema description coverage is 0%, and the description does not describe the single required parameter. The name 'linkId' with format uuid makes its meaning largely self-evident, which prevents a 1, but the description adds no semantics 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 ('Get') and resource ('a tracked link'), so the agent knows this is a single-resource retrieval. It does not distinguish itself from siblings like list_links or get_link_charts, but the core purpose is unambiguous.

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

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

There is no guidance on when to use this versus list_links (to enumerate) or get_link_charts (for analytics). No prerequisites, no mention of what happens for unknown/invalid IDs. Usage is only inferable from the name.

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

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

With no annotations, the description carries the full behavioral burden. "Get" implies a read, but it does not disclose authentication needs, return format, time-range behavior, or what happens when more than 20 link IDs are requested beyond the schema constraint.

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 single sentence is front-loaded and wastes no words. However, the "up to 20" clause largely repeats the schema's maxItems constraint rather than adding explanatory value.

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

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

For a tool with four parameters, 0% schema description coverage, no annotations, and no output schema, the description is far too thin. It identifies the data type and a link cap but leaves date range semantics, timezone handling, and response shape entirely unexplained.

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 explain the four parameters, but it only mentions the 20-link limit already expressed by maxItems. It adds no meaning for startAt, endAt, or timezone, leaving their units and formats undocumented.

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

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

The description names a specific verb ("Get") and resource ("chart data") scoped to tracked links, making the basic action clear. It distinguishes itself from website/pixel chart siblings by specifying "tracked links," though it does not explicitly name those 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 offers no guidance on when to use this tool versus siblings such as get_pixel_charts, get_link, or list_links. It implies chart retrieval for links but provides no conditions, exclusions, or prerequisites.

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

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

No annotations provided; description accurately states it's a read operation without side effects. Adequate but adds no behavioral context beyond the obvious.

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?

Single sentence, front-loaded with purpose, no filler. 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?

Simple tool with no params or output schema; description covers the essential purpose. Could specify return fields, but not critical given 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?

No parameters in input schema; description correctly omits param details. Baseline 4 for zero-parameter tools.

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?

Description clearly states verb (Get) and resource (currently authenticated user's profile information), distinguishing it from sibling tools like get_user or get_my_teams.

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?

Implicitly clear when to use: when needing the current user's profile. No explicit alternatives or exclusions, but not needed for such a straightforward 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?

With no annotations and no output schema, the description carries the full burden of behavioral disclosure. It says only that metrics are retrieved and never covers read-only behavior, authentication, pagination, rate limits, or what the aggregated response 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?

A single front-loaded sentence with no filler. It states the core action and immediately gives examples, making it efficient for an agent to scan.

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

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

This is a relatively complex tool with 10 parameters, nested filters, no annotations, and no output schema. The description does not explain return structure, aggregation semantics, time-range behavior, or pagination, leaving substantial gaps 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 high at 90%, so the schema already documents most parameters and enum values. The description adds only illustrative metric examples that largely duplicate the 'type' enum rather than explaining time range, filters, pagination, or search semantics.

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

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

States a specific verb ('Get') and resource ('aggregated metrics for a website') and gives examples of the metric dimensions available. The purpose is clear, but it does not explicitly distinguish this tool from close siblings such as get_stats, get_pageviews, get_events, or get_revenue_metrics.

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

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

There is no guidance on when to use this tool versus the many alternative analytics tools in the sibling set. The examples imply it is for aggregated breakdowns, but no explicit conditions, exclusions, or preferred alternatives are provided.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only list scoped to the current user, but does not disclose pagination behavior, permission requirements, return format, or whether all memberships are included. The core read semantics are clear, but important behavioral context is missing.

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

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

The description is a single, front-loaded sentence with no wasted words. It immediately states the action and scope.

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 four optional parameters and no output schema, the description gives enough context to call it correctly. It could say more about the returned team representation, but the low complexity keeps this from being a major 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 description coverage is 75%, with page, orderBy, and pageSize documented while sortDescending has no schema description. The tool description provides no additional parameter meaning, so the schema does most of the work; baseline 3 is appropriate for this coverage level.

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

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

The description states a specific verb (Get), resource (list of teams), and scope (the current user belongs to). This clearly distinguishes it from siblings like list_teams or get_user_teams, which operate on broader or specified users.

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 'current user belongs to' implies when to use this tool, but it does not explicitly say when to prefer it over siblings such as list_teams or get_user_teams. There are no exclusions or alternative-routing instructions.

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 does not disclose pagination behavior, default sort order, whether team sites are included by default, or anything about permissions/authorship scope beyond 'belonging to the current user'.

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 short sentence that front-loads the resource and scope. It is efficient, though its brevity comes at the cost of the missing guidance noted elsewhere.

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

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

With five parameters, pagination and an includeTeams flag, and no output schema, the description should explain the return shape, default inclusion of team sites, and how pagination interacts with results. It covers none of that.

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 80%, with page, orderBy, pageSize, and includeTeams documented in the schema; sortDescending has no description. The description adds no parameter guidance at all, so it merely meets the baseline when the schema does the work.

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 list of websites) scoped to the current user, which is somewhat distinguishing. However, siblings like list_websites and get_user_websites plausibly do the same thing, and the description offers no differentiation between them.

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

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

There is no statement of when to use this tool versus list_websites, get_user_websites, or get_website. The agent must infer the distinction, and the 'current user' scoping is the only hint.

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

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

With no annotations, the description carries the full behavioral burden. It only states that counts are returned over time; it does not disclose read-only/auth expectations, default grouping behavior, supported time-range limits, timezone handling, or the shape of the response.

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 a single front-loaded sentence with no wasted words. It is appropriately terse, though it could be slightly more informative without becoming verbose.

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

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

For a tool with eight parameters, a nested filters object, an enum unit parameter, and no output schema, this one-sentence description is too thin. It does not explain the returned time-series structure, default time unit, or how the filter and timezone parameters affect results.

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 eight parameters are already documented in the input schema. The description adds only the high-level notion of time-series counts for a website and does not clarify filter semantics, unit behavior, or timezone interaction beyond what the schema already 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 gives a specific verb ('Get') and resources ('pageview and session counts over time') scoped to a website, so an agent can tell it returns a time series rather than an aggregate. However, it does not distinguish itself from close siblings like get_stats, get_metrics, or get_website_charts.

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

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

There is no explicit guidance on when to use this tool versus alternatives, despite many overlapping analytics siblings such as get_stats, get_metrics, get_sessions, and get_website_charts. The phrase 'over time' implies time-series usage, but no exclusions or alternatives are named.

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

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

With no annotations, the description carries the full burden of disclosure, and four words disclose nothing: not whether pixelId must belong to a website the caller can access, not what happens on an unknown ID, not whether the pixel record is read-only or includes a writable snippet. This is a lookup tool whose failure and return behavior are entirely undocumented.

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 words contain no filler and are trivially front-loaded, so nothing needs trimming. The brevity is under-specification rather than disciplined conciseness, which caps the score.

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

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

A single-parameter lookup is simple, but with no annotations and no output schema, the description is the only place an agent could learn what comes back and what access is required. It supplies neither, leaving the definition insufficient for confident invocation.

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

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

Schema description coverage is 0%, so the description should compensate for the single undocumented parameter, but it adds nothing about pixelId beyond what the schema already shows (a required uuid). The agent must infer that pixelId is the pixel's own identifier rather than, say, a website ID.

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 a tracking pixel" names a verb and a resource and clarifies that the domain is analytics tracking pixels, but it is essentially a restatement of the name. It does not say whether the returned object is the pixel's configuration, its embed snippet, or its status, nor does it distinguish it from list_pixels or get_pixel_charts.

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 call this versus list_pixels (for enumeration) or get_pixel_charts (for reporting). No prerequisites such as needing a website ID or a pixel belonging to an accessible website are mentioned.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure, but it says nothing about authentication requirements, whether data is read-only, default time range, timezone behavior, or return shape. 'Get' implies a read operation, but the description does not confirm or expand on this.

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

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

The description is a single front-loaded sentence with no filler. It is concise, though its brevity is also the source of the specification gaps covered in other dimensions.

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

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

With no output schema, no annotations, and 0% parameter description coverage, the description is too sparse for a tool with four parameters. It does not describe what chart data is returned, how the date range is interpreted, or how timezone affects results — all essential 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 0%, so the description must compensate, but it only mentions the 20-pixel limit, which is already encoded in maxItems. It provides no meaning for startAt/endAt (e.g., epoch vs. ISO date, inclusive/exclusive, defaults) or timezone, leaving three optional parameters completely undocumented.

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

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

States a specific verb ('Get') and resource ('chart data ... tracking pixels'), and the 20-pixel cap is useful. However, 'chart data' is vague — it doesn't say which metrics or dimensions are returned. It only implicitly distinguishes itself from siblings like get_pixel and get_link_charts through the resource name, without naming 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?

No guidance on when to call this versus get_pixel, get_link_charts, or other chart tools is provided. There is no mention of prerequisites, exclusions, or typical use cases, leaving the agent to infer intent entirely from the name.

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

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

No annotations are supplied, so the description carries the full burden. It does disclose the time window and the categories of data returned, which is real behavioral information, but says nothing about result caps, ordering, whether filters narrow the 'current visitors' count, or read-vs-write status (implied read by 'Get').

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

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

Two tight sentences, zero waste, with the scope-defining 'last 30 minutes' front-loaded before the payload list. 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?

Seven parameters, no annotations, no output schema, and five undocumented parameters — this is exactly the case where the description has to do the heavy lifting. It covers the return shape conceptually but leaves filtering semantics, defaults and response limits unexplained.

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 29%: path, unit, event, device and country have no descriptions anywhere. The description's mention of 'active URLs, referrers, countries, and events' faintly hints that path/country/event act as filters, but it never explains units, timezone, or how multiple filters combine, so the coverage gap is left unfilled.

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 real-time data for a website') plus a scope ('last 30 minutes') and enumerates what comes back (visitors, URLs, referrers, countries, events). The only gap is that it never distinguishes itself from the sibling get_active_visitors, which reads like an overlapping capability.

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 '(last 30 minutes)' parenthetical implicitly frames the window, but there is no statement of when to pick this over get_active_visitors, get_stats, get_pageviews or get_sessions. No prerequisites, no exclusions, no alternative named.

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 implies a read-only fetch via 'Get' and hints at unauthenticated access with 'public', but says nothing about permission requirements, whether it reflects draft or live settings, or caching 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?

A single compact sentence with the core resource front-loaded and zero filler. It is efficient, though so short that it borders on under-specification rather than tightness.

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 no annotations, the description is the only source of information, yet it never describes what the configuration payload contains (recorder settings, heatmap flags, snippet fields). For a config-fetching tool the return shape is the main thing an agent needs.

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?

There is one required parameter (websiteId) with 0% schema description coverage, and the description never mentions it — no indication that the config is scoped per website or what identifier format is expected. The description fails to compensate for the schema gap.

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 ('recorder configuration') with qualifying scope ('public', 'session-replay and heatmap'). No sibling tool covers recorder configuration, so there is no close confusion to disambiguate, which keeps it just 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 gives no guidance on when to call this versus other website/configuration tools, nor any prerequisites (e.g., whether the caller must own the website or whether auth is required despite 'public'). The agent must infer usage entirely.

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

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

No annotations are provided, so the description carries full burden, yet it discloses nothing about whether this is a read-only operation, whether results are paginated/size-limited, or how reconstruction behaves for large replays. Given five parameters including index and time bounds, the absence of any behavioral context is a real gap.

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

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

A single front-loaded sentence with no filler or repetition. It is efficient, though the terseness borders on under-specification for a five-parameter tool.

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

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

With no annotations, no output schema, and 0% schema description coverage, the description must carry the load for a paginated retrieval tool and does not. An agent cannot tell from this text how to page through chunks/events, what 'until' bounds, or what the response looks like.

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% across five parameters, and the description explains none of them. The pagination/partitioning semantics of until, chunkIndex, and eventIndex are completely undocumented, leaving the agent to guess how to iterate through a replay's events.

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 reconstructed events' for 'one session replay'. This is clearly distinguishable from siblings like list_replays or get_session, which return replay metadata or session aggregates rather than the reconstructed event stream. It stops short of naming the sibling it is not, so no explicit differentiation.

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 statement of when to call this tool versus list_replays, list_session_replays, or get_session, and no prerequisites (e.g. that a replayId must come from a replay listing). The agent must infer usage entirely from the tool name.

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

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

With no annotations, the description carries full behavioral burden, but it only implies a read-only status check. It does not disclose the return shape (e.g., boolean/status), behavior when the replay is missing, required permissions, or side effects.

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

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

The description is a single front-loaded sentence with no filler. It is appropriately terse, though it could add one short clause about return value or parameters without losing concision.

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 small status-check tool with no annotations, no output schema, and undocumented parameters, the description is too sparse. It does not explain what 'saved' means, how the result is returned, or how this relates to set_replay_saved and list_saved_replays.

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% for both required parameters. The description hints at a single replay but does not explain replayId, and it says nothing about websiteId, leaving both identifiers' meaning and relationship undocumented.

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

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

The description uses a specific verb ('Check') and resource ('whether one session replay is saved'), so the operation is clear. It implicitly distinguishes itself from list_saved_replays and set_replay_saved by focusing on a single replay, though it does not name those 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?

There is no explicit guidance on when to use this tool versus alternatives such as list_saved_replays, get_replay, or set_replay_saved. Usage is only inferable from the phrase 'whether ... is saved', leaving the agent to guess the intended workflow.

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 implies a read-only fetch by using 'Get' and adds the scoping fact that the target is a *saved* report. It stops short of disclosing permission requirements or whether the response includes configuration only or generated results.

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. It is efficient, though sparse enough that a few more words on the return payload would have cost little.

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 full schema coverage, the definition is workable, but with no output schema it never indicates what 'details' comprises (name, metrics, filters, ownership), leaving an agent to guess at the response 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?

Schema coverage is 100% and the single parameter is documented as a 'Report UUID', so the schema does the heavy lifting. The description adds only the useful disambiguation that this UUID identifies a saved report rather than a website or session.

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 ('details of a specific saved report'), clearly distinct from list_reports and run_report by being a single-item fetch. It does not explicitly name when to use it versus get_website_reports or run_report, but the resource noun is unambiguous.

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

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

There is no guidance on when to use this versus list_reports (discovery), create_report/update_report (mutation), or run_report (execute). The only inference an agent can make is that it needs a known reportId, which comes from the schema, not the description.

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

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

No annotations are provided, so the description carries the full behavioral burden. "Get" implies a read operation, but the description does not disclose return shape, whether chart buckets depend on the unit/compare parameters, permission requirements, or any rate/size constraints. It is too thin for an 8-parameter analytics endpoint.

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