Loudcode

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

With no annotations, the description carries the burden and does well: it discloses the output (draft plus alternatives), the persistence side effect ('saved in Loudcode for the user to review'), and the critical negative ('NOT posted'). It does not cover auth requirements or limits, but the safety-relevant behavior is explicit.

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 sentences, front-loaded with the action and scoped to the triggering situation, then the input guidance, then the return/no-publish contract. 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 2-parameter draft tool with no output schema and no annotations, the description covers action, input expectations, return shape, and persistence. Minor gap: nothing about whether the draft is tied to the current session/user context or how the voice personalization is scoped.

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

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

Schema coverage is 100%, so baseline is 3; the description earns more by unpacking what 'summary' should contain — features, fixes, decisions, numbers, and user impact — which is richer than the schema's 'Plain language, specific.' The 'format' parameter is left to the schema, which documents its enum fully.

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+channel: 'Write a build in public post for X about work the user just did'. Clearly separable from siblings like list_drafts, queue_post, and post_metrics — it produces a draft, it doesn't post or 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 clear context for use ('about work the user just did' in this session) and implicitly rules out posting via 'it is NOT posted', which routes the agent toward queue_post for publishing. It stops short of naming an explicit alternative or exclusion.

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

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

No annotations are provided, so the description carries the full burden. It does add real context by disclosing that the result merges two distinct categories (unreviewed drafts and queued posts) and that ids are returned, but says nothing about ordering, result limits, pagination, or permissions on a potentially unbounded list.

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, front-loaded with the resource and scope, with no filler. The trailing 'with their ids' earns its place because there is no output schema.

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

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

For a zero-parameter read tool with no output schema, the description covers what is returned (drafts, queued posts, ids) adequately. Ordering, volume, and whether the list is scoped to the authenticated user's workspace 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?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. The mention of ids is return-value context rather than parameter guidance.

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?

Clear verb+resource: lists the user's drafts awaiting review plus posts queued for publishing, and states that ids are included. The scope is specific enough to separate it from write-side siblings like draft_post and queue_post, though it never names them.

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

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

Usage is implied by the content described ('drafts waiting for review, and posts queued to go out') — an agent can infer this is the read side of the draft/queue workflow. There is no explicit when-to-use, when-not-to-use, or named alternative such as list_ideas.

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

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

With no annotations, the description carries the full behavioral burden; it does disclose that ideas are machine-derived from multiple data sources rather than user-authored, which is useful context. It says nothing about volume, ordering, freshness, or whether the list can be empty, which are the details an agent would need to use results sensibly.

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, no filler, and the resource description precedes the usage hint. The minor awkwardness of 'Post ideas Loudcode found...' as a sentence fragment does not cost readability.

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

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

For a zero-parameter read tool this covers the essentials, and no output schema exists to defer to. However, an agent still does not know the shape or size of the returned idea list, nor how these ideas relate to the drafting flow that the sibling tools imply.

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

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

The tool takes zero parameters and the schema is an empty object, so there is nothing to disambiguate. Baseline 4 applies; the description correctly implies no filtering or scoping input is required.

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 identifies the resource (post ideas) and its provenance (derived from the user's product, numbers, posts and repo), which tells an agent exactly what comes back. It lacks an explicit verb like 'list' and never names a sibling such as draft_post, so differentiation is left implicit.

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

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

"Good when they shipped nothing new this week" gives one concrete trigger condition, which is more than nothing. It offers no when-not guidance and does not point to alternatives like weekly_checkin or draft_post when the agent actually wants to write something.

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

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

With no annotations, the description carries the behavioral burden; it does disclose that results are ordered best post first and that per-post figures come with totals, which tells the agent it is a read-only aggregation. It never states permission/auth requirements, behavior when no posts exist in the window, or whether results are paginated or capped in count.

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 listing the resource, the metrics, and the sort order with zero filler. Nothing is wasted and the most decision-relevant information comes first.

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

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

For a one-optional-parameter read tool with no output schema, describing the returned fields and ordering is exactly the right level of detail. Only minor gaps remain, such as the result cap and the empty-result 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 100% and the single optional 'days' parameter is fully documented with its default and maximum, so the schema does the work. The description only implies a lookback window via 'recent' and adds no format or boundary detail beyond the schema.

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

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

Names the specific resource (the user's recent X posts) and the exact measures returned (views, likes, replies per post plus totals), which is far more specific than a restatement of the name. It doesn't explicitly differentiate from siblings, but none of draft_post/list_drafts/queue_post/list_ideas compete in scope.

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

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

There is no statement of when to reach for this tool versus alternatives, and no mention of prerequisites such as an active X connection. The only contextual cue is the word 'recent', which the schema parameter already handles.

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

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

With no annotations, the description carries the full burden. It discloses the key behavior that this schedules a real post to the user's X account and explains the timing modes, but it omits whether queueing can be cancelled, what happens on failure, authorization requirements, and whether further confirmation is needed.

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

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

Two sentences, front-loaded with the core action, followed by the timing modes and the usage guard. Every sentence contributes useful 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?

The description is adequate for selecting and invoking the tool, especially because the schema fully documents parameters. However, for a real external posting action with no annotations and no output schema, important behavioral context such as reversibility, failure handling, and confirmation expectations is missing.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema. The description reinforces the meaning of the at parameter through the next-free-slot versus specific-time distinction, but does not add format or constraint details beyond what the schema provides.

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

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

The description states a specific verb and resource: queue a Loudcode draft to the user's X account. It also distinguishes the two scheduling modes, immediate next free slot versus a specific time, which separates it clearly from draft_post and list_drafts.

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

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

It gives an explicit gating condition: only use when the user asked to queue or schedule it. It does not name sibling alternatives such as draft_post, but the condition is clear enough to prevent accidental 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?

With no annotations, the description carries the full burden, and it does disclose the most consequential trait: output goes to drafts with suggested times and is not published. However, it says nothing about idempotency or duplicate drafts on repeat calls, what the response contains, or permissions, and the instruction to 'leave one empty if you don't know' is in tension with worked_on being required.

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

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

Two sentences, front-loaded with the action and its outcome, then the answering convention. Slightly dense phrasing ('and Loudcode plans a week of posts') but nothing is wasted.

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

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

For a mutating, side-effect-producing tool with no annotations and no output schema, the description covers the key side effect but omits what the agent gets back and whether repeated invocation creates additional draft batches. Adequate but leaves real operational gaps.

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

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

Schema coverage is 100% with clear per-field descriptions, so the baseline of 3 applies. The description only adds sourcing guidance ('from what you know about their week') and a fill strategy, which partially conflicts with the required worked_on field rather than clarifying it.

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

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

States a concrete action (run the user's weekly check-in) and its consequence (Loudcode plans a week of posts saved as drafts, not posted), which tells an agent what the tool actually produces. It does not name or distinguish itself against siblings like draft_post or queue_post, so the differentiation is only inferable from the draft/not-posted detail.

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: this is the check-in entry point that generates a week of drafts rather than a single post. There is no explicit when-to-use, when-not-to-use, or named alternative (e.g., 'use draft_post for a single post'), so an agent must infer the routing from sibling names.

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