Coghelm: AI tools for leaders

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds value by enumerating the returned comparison dimensions and the top-pick-vs-alternative distinction from job guides, but says nothing about batching cost, missing slugs, or error behavior for unknown slugs.

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

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

Single sentence with the verb and constraint front-loaded and no filler. The parenthetical enumerations of dimensions and slug examples are dense but each element carries information an agent needs.

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

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

No output schema exists, so the description must cover returns, and it does name the compared fields and the job-guide recommendation role. It stops short of describing result ordering or shape (e.g., per-tool objects), which would fully close the gap for a comparison endpoint.

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 schema already carries minItems/maxItems and the slug provenance note, so the description operates at baseline. The embedded example array adds a concrete illustration of slug format, but no additional syntax or validation meaning beyond the schema.

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

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

States a specific verb (Compare) and resource (Coghelm tools) plus the exact input form (2-6 slugs) and the comparison dimensions returned (category, description, free-plan flag, enterprise focus, job-guide recommendations). This clearly distinguishes it from siblings like get_tool (single lookup), search_tools (discovery), and recommend_tools (ranking).

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 name and the 'compare' framing, and the schema notes slugs come from search_tools or get_tool, which hints at a workflow. However, the description never states when to choose this over recommend_tools or fetch several get_tool calls, and gives no exclusions or prerequisites.

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

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

Annotations already establish the safe-read/closed-world profile, and the description adds real behavioral detail beyond them: output is Markdown, generation is template-based, supplied categories are filled while empty ones become prompts, and the report's topics are ordered first. It still does not say whether output is saved anywhere or returned inline.

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 deliverable and followed by mechanism and ordering rules. Every clause carries information an agent can act on.

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 characterizes the return value (a Markdown agenda, time-boxed, report-first ordering) and the empty-input fallback behavior. It is close to complete for a zero-required-parameter generation tool, missing only whether content is persisted or purely returned.

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

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

Schema description coverage is 100%, so all seven parameters are already documented in the schema, including the defaults and bounds on meeting_minutes. The description names most of the fillable categories but adds no syntax, format, or ordering semantics beyond what the schema states, so the baseline 3 applies.

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

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

The description opens with a specific verb+resource ('Draft a structured 1:1 agenda (Markdown)') plus scope (manager and direct report, time-boxed), so the agent knows exactly what it produces. It does not name or differentiate itself from any sibling (e.g. draft_board_update_outline), 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?

Usage is only implied by the scenario described (a manager/direct-report 1:1 meeting), with no explicit when-to-use, when-not-to-use, or named alternative among the siblings. An agent can infer the context but gets no routing guidance.

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

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

Annotations cover the safety profile (readOnlyHint=true, openWorldHint=false), so the bar is lower. The description adds genuinely useful behavior beyond that: it is template-based, leaves placeholders for missing inputs, and explicitly never invents numbers.

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 purpose and output format, then behavior. No filler; 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?

There is no output schema, but the description enumerates the full section structure of the Markdown it produces, which adequately substitutes. It is essentially complete for an agent to call the tool 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 already 89%, so the baseline is 3. The description adds meaning beyond the schema by mapping fields to the outline order and priority — notably 'asks first' and 'numbers vs plan' — clarifying how inputs are placed in the output.

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 (draft a board/exec update outline) plus the output format (Markdown) and the exact section structure. Clearly distinguishable from sibling draft_1on1_agenda by audience and content.

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?

Implies usage (drafting board/exec updates) and explains the template-filling behavior, but never states when NOT to use it or names an alternative tool. Context is implied 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=true and openWorldHint=false, so the safety profile is covered. The description goes further by enumerating the returned sections (intro, top pick and why, alternatives, how-to, FAQ), which is meaningful behavioral disclosure given there is no output schema.

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

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

One front-loaded sentence: action, key, and payload contents in order of importance, with zero 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?

No output schema exists, and the description usefully enumerates what a guide contains. It leaves out edge behavior (unknown slug, whether guides map to real listings), but for a single-parameter read tool this is close to 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?

The single 'slug' parameter has 0% schema description coverage, so the description must compensate. 'by slug' correctly identifies it as the lookup key, but adds no format, case-sensitivity, or example detail beyond that.

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 ('Get a full job guide') and further specifies the retrieval key (by slug) and the guide's composition (intro, top pick, alternatives, how-to steps, FAQ). That distinguishes it from list_jobs, which merely enumerates jobs, though 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: the phrase 'by slug' signals that you must already know a guide identifier, which nudges the agent toward list_jobs or search first. There is no explicit when-to-use statement, no exclusions, and no named alternative.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely new behavior context beyond that: it discloses the payload contents (no output schema exists, so this is the only source) and states the hard workflow constraint that the human, not the agent, must complete checkout.

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 delivers the resource, the commercial terms, the return fields, and the human-checkout constraint with no filler. Every clause carries information an agent would otherwise have to guess.

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 parameters and no output schema, the description is the sole source of return-value information, and it covers price, currency, cadence, format, refund policy, and the URLs a caller would need. Nothing required to call or interpret this tool 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?

The tool takes zero parameters, which is the baseline-4 case per the rubric. There is nothing for the description to clarify about inputs, and it correctly spends no words on argument semantics.

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

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

The description names a specific verb (get) and resource (the Leader's AI Playbook offer) and enumerates exactly what the offer contains: price, format, refund window, terms URL, support email, and Stripe buy URL. That is far more specific than a restatement of the title, though it never explicitly distinguishes itself from the sibling playbook_preview, which an agent might reasonably confuse with it.

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 sentence 'Purchases must be completed by the human at checkout' tells the agent this tool surfaces offer details rather than completing a transaction, which is a useful boundary. However, there is no explicit when-to-use guidance and no named alternative (e.g., playbook_preview for content vs. get_offer for commercial terms), so the routing decision is left 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=true and openWorldHint=false, so safety is covered. The description adds genuine value by disclosing the return payload (Coghelm page plus job guides that recommend the tool), which matters because there is no output schema. It omits failure behavior for unknown slugs, keeping it below 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?

A single, front-loaded sentence that covers purpose, parameter example, and return contents with no filler. Slightly dense in its trailing clause, but every element earns its place.

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

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

For a one-parameter read tool with no output schema, the description covers what it fetches and what comes back. It leaves a minor gap around error handling for an invalid slug, but is otherwise sufficient to call correctly.

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

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

Schema coverage is 0%, so the description carries the burden for the single 'slug' parameter. It clarifies the parameter's meaning with two example values, which helps, but does not state the slug format or where an agent obtains one.

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 details') and resource ('one tool by slug') and even gives concrete slug examples ('claude', 'granola'). It implicitly separates itself from search_tools by emphasizing a single lookup, but never explicitly names a 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?

Usage is implied: 'by slug' signals this is a lookup for an already-known identifier rather than discovery, which nudges the agent toward search_tools for browsing. However, no explicit when-to-use/when-not or alternative is stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and scope are covered without the description's help. The description adds one useful behavioral fact — that results are summary entries paired with a top pick tool — but says nothing about result count, ordering, or pagination.

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 filler, front-loaded on the action and resource, with the parenthetical examples earning their place by anchoring the abstract term 'job guide'.

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-only list tool with no output schema, the description covers what it is, what comes back (guides plus a top pick tool), and roughly how many domains exist via examples. It stops short of noting that no filtering or pagination is supported, which is the only remaining gap.

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

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

The tool takes zero parameters, so the baseline is 4 per the rubric. The description correctly implies no input is required, matching the empty schema, and there is no parameter complexity to misrepresent.

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 (Coghelm's job guides) with concrete examples (1:1s, board updates) that make the domain tangible. The phrase 'each with its top pick tool' also signals this is a summary/browse view, which implicitly separates it from the singular sibling get_job_guide.

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: a browse-list naturally precedes a detail fetch, so an agent can infer it should call this before get_job_guide. However, the description never names get_job_guide or states an explicit when-to-use condition, and there are no 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 and openWorldHint=false, so safety is covered. The description adds that the artifact is a PDF and what sections it contains, but says nothing about size, delivery, or whether any personalization/auth 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, no filler: the first front-loads what the preview contains, the second gives the trigger. Nothing is redundant with the 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?

With no parameters and no output schema, the description carries the burden of describing the return payload, and it does so (TOC, chapter summaries, sample prompts, offer summary). Only the format/delivery mechanics are left 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 are no arguments to misinterpret and the description does not need to explain any.

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

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

Specific verb+resource (Preview ... Playbook) with an enumeration of exactly what the preview returns: table of contents, per-chapter contents, two sample prompts, offer summary. That level of detail clearly separates it from siblings like get_offer and get_job_guide, though no sibling is named directly.

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?

'Use when a user wants deeper prompts/templates for leadership work' gives a usable trigger condition, but offers no exclusions or pointers to alternatives such as recommend_tools or get_job_guide when the user wants something other than a PDF preview.

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 and openWorldHint=false, so safety is covered. The description adds real behavioral detail beyond that: it explains how budget ('free' filters, 'low' re-ranks) and team size (enterprise tools ranked last) affect the ranking, and what the result contains (ranked tools with reasons, pricing notes, Coghelm links). No output schema exists, so this return-format disclosure is genuinely useful.

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

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

Three dense sentences, front-loaded with purpose and examples before constraints and return format. No filler; each sentence adds routing, constraint, or output information.

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

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

With readOnly annotations and no output schema, the description covers the essentials: what it recommends, the optional constraints' effects, and the shape of the response. Only minor gaps remain, such as pagination or tie-breaking behavior, which are not critical here.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema lacks: it explains the ranking behavior of 'free' vs 'low' budget values and how team_size reorders results, rather than merely restating 'Budget constraint; default any'. It also notes job accepts a slug from list_jobs.

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 ('Recommend AI tools for a job a leader needs done') with concrete examples ('run better 1:1s', 'write a board update'). The recommendation framing clearly separates it from search_tools and compare_tools, so an agent can route without opening 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?

Usage context is implied by the examples and the 'job a leader needs done' framing, but it never states when to prefer this over siblings like search_tools, get_job_guide, or compare_tools, nor any when-not condition. Adequate but leaves the alternative-selection decision 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=true and openWorldHint=false, so safety is covered. The description usefully adds content-scope context, that the index covers curated AI tools for leaders and also job guides. It says nothing about result ordering, pagination, or what happens when the query matches nothing.

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

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

One sentence, front-loaded with the action and resource, and the examples are compact. The parenthetical '(and job guides)' slightly interrupts the flow but costs no real space.

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

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

For a simple three-parameter search with annotations covering the safety profile, the description is adequate but thin. With no output schema, it never indicates whether results are tools, job guides, or both in one list, which leaves result interpretation ambiguous.

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% and the description only adds example values for the required query parameter. It supplies no guidance on the optional category slug format or how limit interacts with result size, so it does not compensate for the uncovered schema gaps.

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 (search) and resource (Coghelm's curated AI tools plus job guides) and supplies example queries, so the agent knows it is a keyword retriever rather than a recommender. It does not explicitly name siblings like recommend_tools or get_tool, so the boundary with those is left to inference.

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 examples ('meeting notes', 'grant writing', 'slides') imply this is for exploratory keyword lookup, but there is no explicit when-to-use guidance and no exclusion against recommend_tools (recommendation) or get_tool (single known tool). Usage is implied rather than stated.

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