Rolston Paul field notes

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description still adds useful context beyond the annotations: the response is Markdown, it is complete rather than summarized, and it is verbatim ('exactly as published'). It omits error behavior for an unknown slug, which keeps it at 4 rather than 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 sentence, front-loaded with the verb and resource, that spends its words on the format and the completeness of the returned content. Nothing is redundant with the title or the 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?

There is no output schema, so the description must carry the return-value burden and does: it enumerates the fields and content sections returned. The only gap is what happens when the slug does not resolve, which an agent would want to know for a single-item fetch.

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

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

Schema coverage is 100% and the single slug parameter is fully documented in-schema, including the URL pattern. The description adds nothing about the slug beyond what the schema states, so baseline 3 applies.

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

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

Specific verb ('Return') plus specific resource ('one field note') plus the delivery format ('as Markdown') and the exact content envelope (title, date, topic, every section and FAQ). It is clearly distinguishable from the list/search siblings by the 'one ... in full' framing, 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 only implied: the required slug and 'in full ... exactly as published' signal a single-item full read, contrasting with the list/search siblings. It never states when to prefer this over search_notes or related_notes, 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description's only added behavioral fact is the 'newest first' ordering, which is genuinely useful, but it says nothing about pagination, empty results, or what a note record contains.

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

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

A single front-loaded sentence with no filler; the verb, resource, ordering and optional scope all appear before any qualifying 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 simple, read-only list tool with rich annotations the description covers the essential purpose. But with no output schema, it could reasonably say what a returned note looks like or how the topic filter is discovered, and it leaves the limit parameter entirely 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?

Coverage is 50%: 'topic' is documented in the schema (a slug from list_topics), and the description merely restates it as 'optionally within one topic'. The 'limit' parameter is never mentioned anywhere, so the description does not compensate for the coverage gap or clarify that it caps result count (1-20, default 10).

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 the most recently published notes') plus the ordering ('newest first') and an optional scope ('within one topic'), so the agent knows exactly what it returns. It does not name or contrast any sibling (search_notes, related_notes), so sibling differentiation 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?

'Optionally within one topic' implies the default unfiltered browsing case, which hints at when to use it. However, there is no explicit statement of when to prefer this over search_notes or related_notes, and no exclusions or prerequisites 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 readOnly, idempotent, non-destructive and closed-world, so the safety profile needs no restating. The description does add useful behavioral value by disclosing what each entry contains (published description, premise, note slugs). It says nothing about result size, ordering, or whether all topics are always returned, which matters for a no-parameter listing.

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 action and resource, then the returned fields. No filler, no redundancy with the title 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 present, describing the shape of each returned item is the right thing to include, and the description does it. The remaining gap is the absence of any note about result volume/ordering or that the listing is unfiltered and unpaginated, which an agent would want before relying on 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?

The tool takes zero parameters, so there is no parameter semantics to explain beyond the implicit no-filter behavior. Baseline 4 applies; the description correctly does not waste space on nonexistent inputs.

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 ("List the topic guides") that is clearly a different resource from the note-oriented siblings (get_note, latest_notes, search_notes, related_notes). It also enumerates the returned fields, so an agent knows this is a browse/enumerate operation. It stops short of explicitly contrasting itself with the note tools, so a 4 rather than 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 statement of when to call this versus the note tools, no prerequisites, and no exclusions. Usage is only inferable from the verb "List"; the description never routes the agent between this and search_notes or get_note.

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=false and destructiveHint=false, so safety is covered. The description adds two useful facts beyond that: results are ranked by semantic closeness, and each carries its published description (implying unpublished notes are excluded). It says nothing about ordering guarantees, why the default is 4, or behavior when no note is similar.

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

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

A single front-loaded sentence with zero filler; the key distinguishing clause ('closest in meaning') arrives early and every word earns its place.

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

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

For a simple, read-only, two-parameter tool with no output schema, the description covers what the results are and that descriptions are included, which compensates for the missing output schema. The one gap is the undocumented limit parameter and result-count behavior.

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

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

Schema coverage is 50%: slug is documented in the schema, but limit has no description anywhere. The description does not explain what limit controls, how ranking interacts with the cap, or what happens at the maximum of 8, so it fails to compensate for the undocumented parameter.

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 the notes closest in meaning to a given note'), which implicitly separates it from get_note, latest_notes and search_notes by describing semantic proximity rather than lookup, recency or query matching. It does not explicitly name or contrast with those siblings, keeping it just short of a 5.

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

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

Usage is only implied: the agent can infer this is the tool for 'find similar content' rather than 'fetch a note'. There is no explicit when-to-use, when-not, or named alternative such as search_notes for keyword retrieval.

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, closed-world, so safety needs no restating. The description adds genuinely new behavior: results include a verbatim quoted passage only when one actually answers the question, plus notes matching the topic and passages close in meaning, each carrying a URL — revealing a hybrid lexical+semantic retrieval model and that indexing is limited to published content.

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 followed by return shape and the scoping hint. Every sentence carries information, though the return-shape sentence is dense enough that an agent may need to re-read it.

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 compensates by describing the result structure and URLs; parameters are fully covered by the schema. Minor gaps remain — whether limit applies to notes only versus passages, and what an empty result looks like — but nothing blocking for coherent invocation.

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

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

Schema coverage is 100%, so the schema documents slug format, limit bounds, and query length; baseline is 3. The description adds only slight extra meaning by explaining that the note parameter scopes the search to a single note rather than just naming the slug — useful effect-level context but not enough to exceed the baseline.

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

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

States a specific verb and resource — find published passages that answer a question — and enumerates the three result kinds (best verbatim passage, covering notes, semantically close passages). It never names a sibling, though 'search inside one note' implicitly contrasts with get_note, so differentiation is left partly 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?

'Find the published passages that answer a question' implies the triggering condition (a natural-language question), and 'Give note to search inside one note' explains the narrowing case. But there is no explicit when-not guidance and no routing to get_note for full-note reads or latest_notes for browsing, which an agent needs to choose correctly among five siblings.

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