aidelly

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so safety is covered; the description still adds genuine context beyond that by disclosing the API-key scoping constraint that gates the call and by specifying the aggregate contents returned. It omits rate limits, freshness/latency of the 24-hour window, and behavior when workspace_id is supplied anyway.

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

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

Two sentences, front-loaded with the resource definition and followed by the precondition, with the enumerated payload list doing real work. The trailing 'Read-only.' is redundant with readOnlyHint=true but costs only a few tokens.

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

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

With no output schema, the description carries the return-value burden and does so well by listing the summary's sections. Combined with the auth scoping note, an agent has enough to call it correctly; only parameter-level behavior (tz, query overrides, whether workspace_id is honored) and any paging/limits are missing.

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

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

Schema description coverage is only 50% (tz and brand_id are entirely bare, and `query` is a free-form additionalProperties bag), so the description is expected to compensate — and it says nothing about any of the four parameters. 'Cross-workspace' mildly implies workspace_id is irrelevant here, which is left unresolved rather than explained, so the agent gets no guidance on tz or the query overrides.

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 ('Read') and resource ('cross-workspace agency summary') and then enumerates the exact contents: today's queue, next scheduled post, 24h failures, pending approvals, inbox counts by comments/DMs, and AI credit burn per workspace. The 'cross-workspace agency' framing and the 'same data as the dashboard Command Center' anchor cleanly separate it from the many per-workspace and single-resource getters in the sibling list.

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

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

Gives a hard precondition: it 'Works only with a key that is not scoped to one workspace,' which tells the agent when the call will fail and implicitly routes workspace-scoped needs to siblings like aidelly_get_workspace or aidelly_get_analytics_summary. It does not explicitly name those alternatives or state when-not-to-use, so it falls short of a full 5.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is fully covered. The description adds useful content-level context by enumerating the credit categories returned, but says nothing about auth requirements, scoping to workspace vs brand, or freshness of the snapshot.

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, and the enumeration of credit types is the most informative part placed immediately after the verb. Efficient, though it could have used one more clause to route versus siblings.

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

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

With no output schema, the description does carry useful return-content detail (the credit categories), but it leaves brand_id and the query override undocumented and gives no hint about how to scope the request to a workspace. Adequate for a simple read, with clear gaps remaining.

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 67%: workspace_id is documented in the schema while brand_id has no description and query is a generic escape hatch. The description adds no parameter meaning at all, so it neither helps nor compensates for the brand_id gap; baseline 3 is appropriate.

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

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

States a specific verb (Get) and a precise resource (workspace AI credit balance snapshot), and enumerates what the balance comprises (plan credits, trial grants, purchased credits). It is clear what the tool returns, but it does not differentiate itself from the nearby aidelly_get_usage sibling.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives such as aidelly_get_usage, which an agent could plausibly confuse with a credit-balance lookup. The agent must infer usage from the name alone.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), but the description adds real behavioral context: an empty list is a valid outcome, and a missing/stale insight must not be read as evidence of a trend. The closing 'Read-only' merely restates the annotation, adding no value.

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

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

Three tight sentences, front-loaded with the core action and then the two most likely misinterpretations. Only the trailing 'Read-only.' is expendable, duplicating the readOnlyHint annotation.

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?

It covers the semantic trap (empty results vs. trend evidence) but leaves the 8-parameter surface, including the opaque nested query object, undocumented with no output schema to fill in. Adequate for the behavioral warning, incomplete 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 only 25% across 8 parameters, including a free-form nested 'query' object and an undocumented 'type' string, so the description carries the burden of compensating. It says nothing about any parameter — no meaning for type, platforms, dismissed, brand_id, or how cursor/limit paginate. A significant 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+resource ('Read saved analytics insights for the workspace') and explicitly distinguishes itself from its nearest sibling, aidelly_generate_analytics_insights, which it names. An agent can route correctly without opening either schema.

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

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

Gives clear usage context: reading generates nothing (the generate sibling does), and results may legitimately be empty because saved insights are not scoped to the analytics summary date range. It does not, however, contrast with other read siblings such as aidelly_get_analytics_summary or aidelly_get_analytics_unified, so selection guidance is incomplete.

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

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so safety is covered. The description adds non-annotation context: it discloses return structure (summary.platformMetrics holds per-channel metrics) and the single-range-per-call constraint, which materially affects how an agent plans calls.

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 tight sentences, front-loaded with the verb and range scoping, then output structure, then the single-range constraint. No filler, though it leans on an unexplained dot path (summary.platformMetrics).

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 8-parameter, nested, output-schema-less tool, the description covers the essential range mechanics and one return field but omits several parameters and any sibling routing. Adequate but leaves clear gaps an agent must fill by trial.

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 only 25% schema description coverage, the description carries real burden. It usefully explains timeframe (example "30d"), the startDate/endDate alternative, and workspace_id, but leaves brand_id, includeActivity, includeInsights, and query unexplained in both schema and prose.

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 (Summarize) and resource (workspace analytics) with the scoping dimension (timeframe or startDate/endDate range). Clear on its own, but it never distinguishes itself from close siblings like get_analytics_unified, get_analytics_insights, or get_post_analytics.

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 hints at usage by clarifying that one call covers one range and a trend requires comparing two separate ranges, which is genuinely useful context. However, it names no alternative tool and gives no explicit when-to-use/when-not guidance against the several other analytics 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?

Annotations already declare readOnly, idempotent, non-destructive, openWorld, so the safety profile is covered. The description adds real behavioral context beyond them: it fuses stored and live provider metrics (relevant for latency/freshness expectations), enforces date-only input rather than timestamps, and states the return granularity (post, account, date).

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

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

Three tight sentences with zero filler, front-loaded with the core action and followed by required input format and return shape. Nothing restates the tool name or title.

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

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

For a 6-param read tool with no output schema and a nested query object, the description covers the essentials but leaves gaps: the role of brand_id, what the sparse-schema query override is for, any row limits or pagination, and the actual metric fields returned beyond the post/account/date grouping.

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 33% across 6 params. The description usefully adds semantics for from/to (YYYY-MM-DD, not timestamps) and platforms (comma-separated list), and workspace_id is documented in the schema. But brand_id, the nested query override object, and any constraints on those are left 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 and resource ('Read unified social analytics rows... combining stored and live provider metrics') with scope detail that separates it from a plain analytics read. It does not name or distinguish itself from close siblings like aidelly_get_analytics_summary, aidelly_get_post_analytics, or aidelly_get_analytics_insights, so an agent must infer the boundary.

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 use case (date-ranged, platform-filterable analytics) and states required inputs, but never says when to pick this over the summary/insights/post-analytics siblings or what it excludes. Usage is inferable rather than explicit.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and openWorld, so the safety profile is covered. The description adds useful context: what is returned (generated content + review status) and an explicit disclaimer that no approval/rejection/scheduling side effects occur. No auth or rate-limit detail, but that is a minor gap here.

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

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

Three short sentences, all load-bearing: the action, the read-only posture, and the excluded operations. Front-loaded with the core purpose and no padding.

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 exists, and the description partially compensates by naming the returned fields. Combined with the full annotation set, an agent has enough to call this correctly, though brand_id semantics and the shape of 'generated content' remain unspecified.

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

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

Schema coverage is 50%: workspace_id and query carry inline descriptions, but brand_id is undocumented and the description only restates 'by id'. With half the parameters lacking schema documentation, the description should compensate for it and does not, so the baseline 3 is appropriate.

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

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

States a specific verb (read), resource (content approval batch), and scope (one, by id), plus what the payload contains (generated content and review status). This distinguishes it from the list-style siblings like aidelly_get_approvals and aidelly_list_pending_approvals.

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 draws a clear negative boundary by naming the operations it does not perform (approve, reject, schedule), which steers the agent toward mutating siblings for those actions. It does not, however, name the specific alternative tool or state prerequisites beyond the 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds important behavioral context beyond that: 'Reading does not approve content' clarifies the effect of the call, and it explains pagination semantics (summary counts describe the current page while pagination.total covers all matching batches).

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 front-loaded with the core action and then adds targeted details in a compact, well-ordered sequence. Every sentence contributes useful information, though the density is high enough that some readers may need to parse it carefully.

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 7 parameters, no output schema, and low schema description coverage, the description covers key operational aspects (pagination, status, read-only nature, sibling distinction). However, it does not explain the remaining parameters (brand_id, cursor, query) or provide more detail on the shape of returned approval batches, leaving some gaps for an agent to infer.

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% (7 parameters, several undocumented). The description adds meaning for status ('use status=pending'), page/limit (pagination, maximum 50), and workspace_id (required scope), but it leaves brand_id, cursor, and the nested query object unexplained. It partially compensates but does not fully cover the parameter 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 states a specific verb (List) and resource (content approval batches) scoped to workspace_id. It explicitly distinguishes itself from the sibling aidelly_list_pending_approvals, so an agent can tell them apart without inspecting schemas.

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

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

It gives concrete usage guidance: use status=pending for pending work, and page/limit for pagination. It also names the alternative tool and its scope (post sign-off), which helps selection, though it does not spell out exactly when to choose this tool over the alternative in every case.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered and the description's 'Read-only' largely repeats it. The description adds a small amount of domain context ('member submissions and owner review') but says nothing about auth requirements, pagination, or return shape. With annotations carrying the behavioral burden, a 3 is appropriate.

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

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

Two short, front-loaded sentences with no filler. Minor waste: 'Read-only' duplicates the readOnlyHint annotation rather than adding new information.

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

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

For a simple read-only getter with no output schema this is nearly adequate, but the tool has 4 parameters at 50% description coverage and the nested query override object is unexplained anywhere. The description leaves an agent without guidance on how to supply a valid workspaceId or when to use the query override.

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 50%: workspace_id is documented, but workspaceId (the required param), brand_id, and the nested query override object are not. The description mentions 'the workspace's approval settings' but does not clarify the workspaceId vs. workspace_id duplication or what the query override is for, so it fails 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?

States a specific verb and resource ('Read the workspace's approval settings') and scopes it to 'member submissions and owner review', which hints at the approval-workflow domain. It does not explicitly distinguish itself from close siblings like aidelly_get_approvals or aidelly_get_approval_batch, 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?

No when-to-use guidance, no exclusions, and no reference to the obvious alternatives (aidelly_get_approvals, aidelly_get_approval_batch, aidelly_update_approval_settings). The only usable signal is the implied read-only nature, which is already carried by annotations.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered without the description's help. The description adds only that the response contains 'configuration and blocks', which is mild value; it says nothing about auth requirements, pagination, or what happens in an empty workspace.

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, which is appropriately sized for a simple read tool. Its brevity is efficient, though it leaves needed context unstated.

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

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

With no output schema, the description's mention of 'configuration and blocks' is the only hint at return shape, and that is minimal. The nested optional query object and the undescribed brand_id parameter mean an agent still lacks enough to call this confidently in every case.

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 67% and the description adds no parameter meaning at all. The undocumented brand_id is left entirely to inference (it is not even mentioned in the schema description), and while workspace_id and query do have schema text, the description does not clarify how the optional query overrides interact with this endpoint.

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 ('the workspace's link-in-bio page configuration and blocks'), and it is the only bio-page tool among the siblings, so there is no sibling ambiguity to resolve. It is clear but does not add scope detail (e.g., whether it covers published vs. draft state).

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

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

There is no explicit when-to-use guidance, no prerequisites, and no named alternative or follow-up tool. The read semantics are implied by 'Get' and by the readOnlyHint annotation, but the description itself offers nothing on invocation context.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower. The description does add genuine non-obvious context: that socialConnections and aiSummary can be stale/historical and how to resolve conflicts. It does not disclose return shape or any access 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?

Two sentences, zero waste, with the core action front-loaded before the data-freshness caveat. Every clause earns its place by disambiguating data sources.

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 tool with no output schema, the description covers the important freshness caveat and names key profile fields (socialConnections, aiSummary). It stops short of describing the returned profile structure, which would help since no output schema exists.

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

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

Schema description coverage is 67% (brand_id has no description; query and workspace_id do). The description adds no meaning about any of the three parameters — no syntax, defaults, or how brand_id vs workspace_id interact. Baseline 3 is appropriate given the schema carries most of the burden.

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 opens with a specific verb and resource: 'Read the workspace brand profile and voice,' which is unambiguous and clearly distinct from aidelly_update_brand_profile. However, it never distinguishes itself from the similarly-named aidelly_get_brand_settings_context, so an agent has to infer which one it wants.

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

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

It explicitly routes the agent to aidelly_list_social_connections when current connection status is needed, and states a precedence rule (explicit profile fields over conflicting aiSummary). That is real when-to-use guidance, but there is no guidance on when to prefer this tool over get_brand_settings_context or when the profile is not available.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the phrase 'it does not modify the brand' merely restates structured data. The description adds no new behavioral context such as auth requirements, rate limits, or what 'aggregated' actually aggregates, and there is no output schema to fill that 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?

Two compact sentences with the core action front-loaded and the non-mutating constraint carried by a trailing clause. No filler, though the second clause partly duplicates the 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 read-only tool whose safety profile is covered by annotations, this is nearly sufficient, but with no output schema the phrase 'aggregated brand settings context' never tells the agent what fields come back or how brand_id affects the result. Minor but real gap.

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

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

Schema coverage is 67%: workspace_id and query are documented in the schema while brand_id is not. The description's 'selected workspace' loosely maps to workspace_id but adds no syntax or brand_id semantics beyond the schema. Baseline 3 for moderate coverage 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+resource ('Read aggregated brand settings context for the selected workspace'), which is clear. However, it does not distinguish itself from the very similar sibling 'aidelly_get_brand_profile', leaving the agent to guess which brand-read tool 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?

It gives explicit when-to-use context ('before planning content or changing settings'), which is genuinely actionable. It stops short of naming an alternative or exclusion — notably it never contrasts with aidelly_get_brand_profile, the closest sibling.

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

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

Annotations already cover readOnly/idempotent/non-destructive, so the description's added value is the caveat that job creation success does not imply posts were scheduled, and that this tool never creates or retries. That is genuine behavioral context, though polling/expiry behavior is not discussed.

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

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

Three short sentences, front-loaded with the operation and key, then the important caveat. No filler.

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

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

With no output schema, the description still indicates what comes back (progress or completion status). Combined with the warning about job creation not guaranteeing scheduling, an agent has enough to call and interpret this read-only tool, though the auxiliary parameters remain unaddressed.

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

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

Schema coverage is 50% and jobId carries no schema description, so the description's tie of jobId to a previously created job does add meaning. However, brand_id and the catch-all query override are left unexplained, so it only partially compensates 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?

States a specific verb (read status) plus resource (bulk calendar fill job) and the lookup key (jobId). It is clearly distinguishable from the sibling create_bulk_fill_job, and even states what it is not ('does not create or retry posts').

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?

Says when to use it: polling the status of a previously created bulk fill job. It also gives a useful precondition ('a successful job creation response alone does not mean all posts were scheduled'). No explicit alternative tool is named, but the context is unambiguous.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=true, so safety is covered; 'This only reads the calendar' largely restates readOnlyHint. The genuinely additive detail is the cursor-based pagination behavior, which the annotations do not convey, but the description says nothing about result ordering, rate limits, or what happens with an invalid/expired cursor.

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

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

Two tight sentences with the purpose front-loaded and the pagination hint following. There is no filler or redundancy, though the closing sentence is close to duplicating the already-present readOnlyHint.

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

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

With no output schema, the description usefully previews the returned fields (timing, status, content details) and covers pagination, and the annotations carry the safety profile. It is close to complete for a paginated read tool, missing only scoping/filter behavior for brand_id and the query override.

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 50%: workspace_id and query are documented in-schema, while cursor and brand_id are not. The description partially compensates by explaining that returned cursors drive further pages, which gives cursor usable semantics, but it says nothing about brand_id or what the nested 'query' override object accepts beyond the schema's generic note.

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

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

The description states a specific verb and resource ('List content calendar events for the selected workspace') and enumerates what the payload contains (timing, status, content details). It does not, however, distinguish this tool from neighboring list/get tools such as aidelly_list_scheduled_posts or aidelly_get_scheduled_post, so the agent must infer the calendar-vs-scheduled-post boundary 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?

Usage is implied by the read-only framing and the pagination instruction ('Use returned cursors to read additional pages'), which tells the agent how to iterate. There is no explicit statement of when to reach for this tool versus the many other listing tools, and no prerequisites or exclusions are given, leaving routing to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered structurally. The description adds a genuinely non-redundant behavioral fact – that reading the rule does not execute the automation – which is not derivable from the annotations and directly prevents a harmful misread.

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

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

Three short sentences, front-loaded with what is read and by what key, followed by the two disambiguating facts. Every clause earns its place and nothing is repeated from the schema or 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?

With no output schema, the description carries the return-value burden and does state that the configuration is included, which is the main thing an agent needs to know about the response. The remaining gap – how the optional workspace_id/brand_id scoping affects a read – is minor for a single-record getter.

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 50%: workspace_id and query carry their own descriptions, while id and brand_id are bare. The description says "by id" but adds no format or scoping detail, and explains nothing about brand_id's relationship to workspace_id when both appear. Baseline 3 is appropriate since the schema does much of 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 names a specific verb and resource ("Read one saved content automation rule by id") and scopes it to a single record with its configuration, which implicitly separates it from the plural aidelly_get_content_automations lister and the create/update/delete variants. It stops short of naming any sibling explicitly, so it is clear but not maximally differentiating.

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?

"Read one ... rule by id" gives the selection condition (you already know the id, you want exactly one), and "It does not run the automation" is an explicit when-not that steers agents away from aidelly_trigger_content_automation. There is no direct routing to the alternative tools by name, so it is strong context rather than full alternative coverage.

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 readOnlyHint/idempotentHint already covering the safety profile, the description still adds real value: it discloses what is returned ('rule configuration and activity state') and pagination behavior ('follow next_cursor'). It doesn't mention auth, rate limits, or result volume, so it's not a 5.

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

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

Two compact sentences, front-loaded with the purpose, then return content, pagination, and the negative constraint. No filler.

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

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

For a 4-param read tool with no output schema, the description covers purpose, return shape, pagination, and the read-only boundary. The only gap is the meaning of brand_id and the nested query override object.

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 50%, and the description only clarifies the cursor parameter semantics ('follow next_cursor for additional pages') and implies workspace scoping. The brand_id and the nested query override object remain undocumented in both the schema and the description, so it only partially compensates.

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 saved content automation rules') with workspace scope, which cleanly separates it from mutation siblings like trigger/update/delete_content_automation. It does not explicitly name its closest sibling (aidelly_get_content_automation, singular), so it falls just short of 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 clause 'Does not run or change rules' gives a clear when-not boundary that routes the agent away from aidelly_trigger_content_automation, and the cursor note tells the agent how to continue. It stops short of naming an alternative or stating prerequisites for use.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld). The description adds genuinely new semantic context: drafts are never published and draft_planned_for is a planning date only, which prevents misinterpretation of the field. It still omits any auth or return-shape detail.

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

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

Three short sentences with the core operation front-loaded and no filler. The draft_planned_for clarification earns its place by disambiguating a field, though the sentence count is slightly more than the minimal single-operation statement.

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 with no output schema, this is nearly complete: it clarifies the resource semantics and the required argument source. It could still note the workspace scoping behavior for reads or what the returned draft contains, but neither is essential to call it correctly.

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

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

Schema description coverage is 50%, so half the parameters (query, brand_id) are undocumented in both schema and description. The description adds meaning only for id (source it exactly from list_drafts), leaving the workspace_id and query overrides unexplained. Baseline 3 is appropriate given the partial schema coverage.

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

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

States a specific verb and resource ('Get a single post draft by id'), making the operation clear. It does not explicitly contrast with near siblings like aidelly_get_post or aidelly_update_draft, but the reference to aidelly_list_drafts gives useful framing.

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

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

Provides one concrete prerequisite: ids must be copied exactly from aidelly_list_drafts, which tells the agent where to source the required argument. However, it gives no explicit when-to-use vs alternatives (e.g., get_post vs get_draft) and no conditions that would exclude its use.

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

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

The only behavioral claim, 'Read-only', merely restates the annotation readOnlyHint=true and adds nothing about what is returned, error behavior for a bad id, or whether brand_id/workspace_id are required. With full annotation coverage the bar is lower, but the description contributes no context beyond the structured hints.

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

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

Two short, front-loaded sentences with no filler; the lookup key and safety mode are stated first. The trailing 'Read-only' is redundant against the annotations, which is the only wasted clause.

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 tool with a nested object, 50% schema coverage, and no output schema, this is thin. It does not explain the query override, the brand_id/workspace_id scoping, or the expected return shape, so the definition is not self-sufficient.

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 50%, so the description must compensate, yet it only covers the id lookup key. It says nothing about the optional 'query' override object or the 'brand_id' parameter, leaving two of four parameters undocumented in both the schema and the description.

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

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

States a specific verb and resource with singular scope ('Read one connected e-commerce store by id'), which implicitly separates it from the plural aidelly_list_ecommerce_stores sibling. It stops short of naming that sibling explicitly, so an agent must infer the distinction from the singular/plural wording.

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 and no named alternative. An agent must guess that this is the by-id counterpart to aidelly_list_ecommerce_stores; nothing tells it when a single-store fetch is preferable to listing or to aidelly_sync_ecommerce_store.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered structurally. The description adds real value beyond them by clarifying that reading rules is inert with respect to automation state and outbound messaging, defusing the likely confusion with create/trigger siblings.

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

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

Two sentences, no filler, with the resource and scope front-loaded and the non-side-effect clarification second. Every clause earns its place.

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

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

For a read-only listing tool with no output schema, the description covers what is listed, the scope, and the absence of side effects. It does not describe pagination or result volume, which is a minor gap given there is no output schema to carry 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?

With 3 parameters at 67% schema coverage, the schema does most of the work for workspace_id and leaves brand_id and the sparse 'query' override undocumented. The description's phrase 'for the selected workspace' reinforces workspace_id but adds no syntax or meaning for the other two parameters. 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 (List) and resource (social inbox automation rules) scoped to a workspace, and notes the content of the returned rules (trigger and response settings). It is distinguishable from create/update/delete_inbox_automation, but it does not explicitly differentiate itself from nearby read siblings such as get_inbox_items.

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

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

Usage is implied rather than stated: the tool is for inspecting configured automation rules. The line 'Reading rules does not enable them or send messages' clarifies the reading context but stops short of naming when this is preferred over alternatives or what prerequisites apply.

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

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

Annotations already cover safety (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower. The description still adds real value: pagination behavior via next_cursor and the negative scope assertion that no reply is sent, which prevents misfiring on a mutating intent.

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, scope first, then use case, pagination, and the negative constraint. No filler and every clause carries information an agent needs before calling.

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 exists, so the description does need to carry return/pagination context, and it does ('next_cursor'). For a zero-required-param read tool this is close to complete; only the brand_id and query parameters remain 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?

With 50% schema coverage, the description only illuminates two of four parameters: workspace scoping ('selected workspace') and cursor pagination ('follow next_cursor'). It says nothing about brand_id or the free-form query override object, leaving half the surface undocumented in both places. Baseline 3 for moderate schema coverage.

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

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

States a specific verb and resource ('List social inbox messages and comments') scoped to the workspace, and explicitly negates the reply-writing sibling with 'Does not send replies.' An agent can distinguish this from aidelly_reply_to_inbox_item and the create_* tools without opening a schema.

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

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

Gives clear context ('for triage or selecting an item to reply to') and a when-not statement ('Does not send replies'), which implicitly routes the agent to the reply tool. It stops short of naming the alternative tool explicitly, so it is clear but not fully prescriptive.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds real behavioral value beyond that by defining the delivery-success condition (status=completed AND provider_post_id non-null) and what a failed status carries (error_code, error) – important since no output schema exists. It still says nothing about behavior with the optional overrides (query, brand_id, workspace_id).

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

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

Three short sentences, front-loaded with the purpose and then the two facts about delivery outcome. No filler, no restatement of the title, and every sentence carries information an agent would otherwise have to infer.

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

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

For a single-record read with no output schema, the description usefully explains the terminal-status semantics, but it is silent on the returned post shape and on the optional query/brand/workspace overrides that a caller may need. Adequate but with clear gaps given the schema coverage and absence of an output 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?

Coverage is 50% and the description adds nothing about the parameters; it only restates that a UUID is required, which the schema already conveys via format: uuid and required: [id]. The query, brand_id, and workspace_id parameters – including the non-obvious read-vs-write rule for workspace_id – are left entirely to the schema.

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

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

The description states a specific verb and resource plus the retrieval key: 'Get one post by its UUID.' That is unambiguous and separates it from the list-shaped siblings such as aidelly_list_posts. It does not, however, explicitly contrast itself with the other single-record getters (aidelly_get_scheduled_post, aidelly_get_draft), so 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?

Usage is only implied: 'by its UUID' tells the agent it needs an identifier, which suggests this follows a listing call. There is no explicit when-to-use guidance or named alternative (e.g. use aidelly_list_posts when you don't have an ID), so it lands at the minimum-viable level.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the trailing 'Read-only.' sentence is largely redundant. The description does add value by listing the returned metric set and the optional daily granularity, but says nothing about rate limits, pagination, date-range behavior, or auth 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?

A single front-loaded sentence naming the operation, the resource, and the metric set, with the one optional behavior appended at the end. No filler or redundancy.

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

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

With no output schema, the metric enumeration usefully substitutes for a return-value spec, but the description leaves several real gaps: the undocumented from/to range, the nested query override, and brand_id. For a 7-parameter read tool with sparse schema coverage, more behavioral context is warranted.

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 43%, and the description barely compensates. It mentions the daily breakdown (granularity), which the schema already documents, but says nothing about the undocumented from/to date-range parameters, brand_id, or the open-ended 'query' override object — the parameters most needing clarification.

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 (read), resource (performance metrics for one post), and even enumerates the metric families returned (views, impressions, likes, comments, shares, saves). The scoping phrase 'for one post' implicitly separates it from workspace-level siblings like aidelly_get_analytics_summary, but no sibling is named explicitly.

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

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

Usage is only implied: 'for one post' signals single-post scope, and 'optional daily breakdown' hints at trend use. There is no explicit when-to-use/when-not guidance and no routing against the several analytics siblings (aidelly_get_analytics_summary, aidelly_get_analytics_unified, aidelly_generate_analytics_insights).

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered. The description's only added behavioral detail is the workspace scoping, which is modest value beyond the structured 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?

A single sentence with zero padding, led by the verb and resource, with the scoping qualifier last. Nothing to trim.

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

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

For a simple read-by-ID tool with no output schema and annotation-covered safety, this is close to adequate. However, the nested 'query' parameter is described in the schema as an override for sparse parameter schemas and the description never explains it, leaving a real gap for an agent that hits the sparse path.

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 schema coverage at 50%, the schema documents workspace_id and the opaque 'query' override object, but says nothing about brand_id or how 'query' is used. The description confirms the ID lookup is required and workspace-scoped but adds no format or semantics beyond that, so it does not fully compensate for the 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+resource ('Retrieve a single report by ID') and scopes it to a workspace, which cleanly distinguishes it from the sibling list operation aidelly_list_reports. It does not name that sibling explicitly, so it falls just short of 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 parenthetical '(workspace-scoped)' implies the workspace context but never states when to use this versus aidelly_list_reports or aidelly_get_report_schedule. Usage is inferable from the name and verb, not spelled out.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered by structured data. The only behavioral addition is the workspace scoping constraint; there is no note on permissions, error behavior when the ID is unknown, or whether cross-workspace IDs are rejected.

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 identifying verb and resource come first, followed by the scoping qualifier, 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?

With four parameters (including a nested, free-form 'query' object) at only 50% schema description coverage and no output schema, the description leaves real gaps: it never explains the query overrides, brand_id, or what the returned schedule contains. For a tool of this parameter complexity it should do more.

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 50% (id and brand_id are undocumented, query and workspace_id are documented). The description partially compensates by clarifying that lookup is by ID and that the scope is the workspace, but it says nothing about brand_id or the query-override object, leaving half the surface to inference.

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 ('Retrieve a single report schedule by ID'), which cleanly separates it from aidelly_list_report_schedules and the create/update/delete variants of the same resource. It does not name any sibling explicitly, so it stops short of a 5.

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

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

The description gives no when-to-use guidance, no prerequisites, and never points to aidelly_list_report_schedules for enumeration or aidelly_update_report_schedule for modification. The parenthetical '(workspace-scoped)' implies a context but does not tell the agent when this tool is the right choice.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered by structured data. The description adds nothing behavioral beyond restating the operation, giving no detail on error or missing-job 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 front-loaded sentence with zero padding, which is structurally sound. However, the brevity reflects underspecification rather than efficient communication, since nothing of value is conveyed beyond the title.

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

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

For a simple read tool with no output schema, the description is thin: it does not say what a 'repurpose job' contains, what a returned job's status might be, or how to interpret the response. Annotations cover the safety questions, but the agent is left to guess at the resource's contents.

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 50%: workspace_id and query are documented in the schema, while id and brand_id are not. The description echoes only 'by id', which is already the required parameter, so it does nothing to compensate for the undocumented brand_id or the semantics of the query override object.

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 resource (repurpose job) with an explicit scope ('single ... by id'), so an agent knows it is a point-fetch rather than a list. It never names the sibling it complements, aidelly_list_repurpose_jobs, so differentiation is implicit rather than stated.

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

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

The only guidance is the word 'single' and 'by id', which implies a lookup. There is no statement of when to use this instead of aidelly_list_repurpose_jobs, no prerequisite such as a prior job id, and no note on what happens if the job is absent or still running.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, so "Read-only" merely repeats structured data. The only added value is noting the response includes the recycle plan and approval state, which is useful but modest context beyond the annotations.

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

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

Two tight sentences with the core purpose front-loaded and no filler. Efficiency is good, though "Read-only" is redundant with the 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 simple read tool with no output schema, mentioning the returned fields (recycle plan, approval state) helps, but the description omits the return shape and any parameter guidance despite incomplete schema coverage.

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

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

With only 50% schema description coverage, the description should compensate but adds nothing about parameters. The required `id` and `brand_id` are undocumented in both the schema and the description, leaving the agent to infer their 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 ("Read one scheduled post") and even names the payload contents (recycle plan, approval state). It doesn't explicitly differentiate from close siblings like aidelly_list_scheduled_posts or aidelly_get_post, but the singular resource makes the intent 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?

Usage is only implied: the agent infers you call this when you need a single scheduled post by ID. There is no explicit when-to-use vs aidelly_list_scheduled_posts / aidelly_get_post, and no stated prerequisites or exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered by structured data. The description adds useful behavior context by naming the returned payload (attachments, activity history), but it says nothing about permissions, scoping quirks, or failure modes.

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

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

A single front-loaded sentence with no filler; the primary payload is stated immediately. It is efficient but very thin for a tool with four parameters.

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 tool with annotations covering safety and no output schema, the description is adequate but leaves the undocumented `id`/`brand_id` parameters and workspace scoping unexplained. Given the sparse schema, a bit more on the identifying parameter and scoping would complete it.

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

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

Schema description coverage is only 50%: `id` and `brand_id` are undocumented in the schema, and the description adds no parameter meaning at all. The `id` (uuid) and workspace/brand scoping semantics are never explained, so the description fails 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?

States a specific verb and resource ('Get full details of a task') plus the scope of the payload (attachments and activity history), so it is clearly distinguishable from the related list_tasks at a glance. It does not explicitly name siblings like aidelly_list_tasks or aidelly_get_post to disambiguate further.

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 alternatives such as aidelly_list_tasks (to enumerate) or aidelly_get_post. No prerequisites or context are given, leaving the agent to 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered. The description adds the useful nuance that the returned limits are 'plan-aware', but it says nothing about auth requirements, rate limits, or how the optional time/workspace scoping changes 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?

A single tight sentence with no filler and the resource front-loaded. It is appropriately sized, though it is so brief that it leaves obvious questions (time range, filtering) unaddressed.

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 metrics endpoint with no output schema, the description conveys the essential purpose and that it returns both usage metrics and plan-aware limits. However, with 5 parameters at 40% coverage and an undocumented nested 'query' object, the definition does not explain how the optional filters shape the response.

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 40%; only workspace_id (and the generic 'query' override) are documented, while to, from, and brand_id carry no explanation in either schema or description. The description mentions zero parameters, so it does not compensate for the coverage gap and leaves the filtering semantics of the time range and brand ambiguous.

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 resources ('usage metrics and current plan-aware limits') scoped to 'the API key'. This is clear and distinguishes it from a pure balance check like get_ai_credit_balance by emphasizing plan-aware limits, though it never names a sibling tool explicitly.

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

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

There is no guidance on when to use this tool versus alternatives such as aidelly_get_ai_credit_balance, aidelly_get_agency_overview, or the analytics-summary tools. No preconditions, exclusions, or routing cues are given, so 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so 'Read-only' is largely redundant. The genuinely additive part is that domain ownership changes and validation happen outside this tool in the Aidelly app, clarifying the boundary of what this call can affect, but there is no info on required permissions or return shape.

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

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

Two sentences, zero waste, with the payload contents front-loaded before the scope-boundary note. Nothing repeated or padded.

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

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

For a zero-required-parameter read tool with no output schema, the description adequately covers what is returned and what the tool cannot do. It falls short only on naming the sibling update tool and clarifying how brand_id scopes 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 coverage is 67%: workspace_id and query are documented in the schema, but brand_id has no description anywhere. The phrase 'the agency's ... configuration' hints at brand/agency scoping but adds no format or selection guidance for brand_id, so baseline 3 is appropriate.

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

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

States a specific verb and resource ('Read the agency's white-label branding configuration') and enumerates the notable payload fields (custom-domain verification status, DNS instructions). The read-only framing implicitly distinguishes it from the sibling aidelly_update_white_label_config, though that sibling is never named.

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 statement that 'Custom domains are changed and verified in the Aidelly app' implicitly tells the agent this tool is not the mutation path, which is useful routing guidance. However, it never explicitly names aidelly_update_white_label_config as the alternative or states prerequisites such as which identifiers are needed.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so 'Read-only' in the description is redundant. The one genuine addition is the access-scope statement that only workspaces reachable by the API key are returned, which is useful context but thin.

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

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

Two short sentences, front-loaded with the action and resource, with no filler. Nothing in the text is wasted.

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

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

No output schema exists, so the description carries the burden of explaining what a workspace object contains, yet it says nothing about the returned fields. Combined with the unaddressed workspaceId/workspace_id ambiguity, an agent lacks what it needs to call this reliably.

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

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

The description mentions no parameters at all, and schema coverage is only 50%. Critically, the schema exposes both a required 'workspaceId' and an optional 'workspace_id' with overlapping meaning, and the description does nothing to disambiguate which one to send for a read.

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 ('Read one workspace') plus a scope qualifier ('the API key can access'). It is clearly distinguishable from list_workspaces, but it never names or contrasts with siblings such as aidelly_list_workspaces or aidelly_get_agency_overview.

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 fetching the workspace list or another read endpoint. 'Read-only' describes the operation, not a usage condition, and no prerequisites or exclusions are given.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so 'Read-only' in the description is largely redundant. The genuinely additive detail is that results come back as a flat list including sub-accounts, a return-shape behavior not in the annotations, but pagination, ordering, and result-size limits are unaddressed.

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

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

Three short sentences, front-loaded with the core scope statement, and the create_post linkage is placed usefully at the end. The closing 'Read-only' sentence is near-redundant given the annotations, costing a little density.

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

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

With no output schema, the description does carry part of the return-value burden and handles it by describing the flat-list shape and the id field's meaning. It still omits pagination behavior and what account fields are returned, and leaves the nested query override and brand_id filtering unexplained, so it is only borderline complete for a 3-parameter tool with a nested object.

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 33%, so the description needs to compensate but does not: brand_id and the nested 'query' override object are never explained, and the only parameter mention ('Requires workspace_id') merely restates the schema's required field. No filtering, format, or interaction semantics are added for the two undocumented parameters.

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 every postable account in a workspace as a flat list') and clarifies scope by naming sub-account types (Facebook Pages, Instagram Business, LinkedIn company pages). It does not, however, distinguish itself from the sibling aidelly_list_social_connections, which an agent could easily 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?

Gives concrete usage context: it notes workspace_id is required and that each returned id is the account_id consumed by aidelly_create_post, which tells the agent exactly when this tool feeds a downstream call. It stops short of stating when NOT to use it or naming an alternative for other account-related needs.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered by structured data. The description adds cursor-pagination behavior, which is genuinely useful beyond the annotations, but says nothing about default result size, ordering, or how the audit trail is scoped.

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

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

A single front-loaded sentence with no wasted words. However, at 9 parameters and 22% schema coverage, the extreme brevity works against completeness rather than serving as efficient conciseness.

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 9-parameter tool with a nested 'query' object, sparse schema documentation, and no output schema, the description is too thin. It never explains the audit-trail return shape, pagination semantics, or the meaning of the filter parameters, leaving the agent under-equipped.

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 22% across 9 parameters, and the description does not compensate, offering no format or meaning for since/until, action, cursor, brand_id, or actor_type. Only 'cursor pagination' and 'optional filtering' hint at the parameter surface, which is far short of what a low-coverage schema requires.

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 ('List') and a specific resource ('workspace activity audit trail'), which is unique among the sibling list_* tools, so an agent can distinguish it. It does not explicitly name a sibling it is not, so it falls short of a 5.

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

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

There is no guidance on when to choose this tool over the many other list_* siblings, nor any exclusions or prerequisites. 'Optional filtering' merely implies usage rather than stating when this tool is the right call.

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