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

With no annotations present, the description carries the full behavioral burden and does this well: it explicitly states the tool returns a draft, does not write a file, relies only on repo facts or project.faf content, and 'nothing invented.' This gives the agent a reliable model of side effects and output trustworthiness.

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 two sentences with the core purpose front-loaded. Every clause adds necessary information: source of facts, quality tiers, and the non-write side effect. It avoids repetition of schema or annotation details, so there is no wasted text.

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 tool with no output schema, the description is complete: it explains what the output is (a draft), what data feeds it, when the result is better or best, and that it does not modify the filesystem. An agent can decide whether and how to invoke this tool without ambiguity.

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

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

The input schema has zero parameters and 100% coverage, so there are no parameter semantics to clarify. The description still adds relevant semantic context by distinguishing the BETTER and BEST input states based on whether a project.faf exists, which helps the agent understand what determines output quality.

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: 'Author an AGENTS.md for this project and return the draft.' It also clearly isolates this tool from its siblings by framing it as draft generation rather than reading or listing existing AGENTS.md content, and it emphasizes that no file is written.

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 clear contextual guidance on when output is BETTER versus BEST, specifically depending on whether a project.faf exists. It does not explicitly name sibling alternatives such as read_agents_md, but the purpose and the non-write guarantee make the intended usage clear enough.

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 one useful behavior: 'A missing id is reported, not an error', and mentions it reports whether removal occurred. However, it doesn't address permanence, side effects, or error output format for a destructive operation.

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

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

Two brief, information-dense sentences. The core action and purpose are front-loaded, and every word contributes value.

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

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

For a simple one-parameter tool, the description plus schema cover core use, error behavior, and removal reporting. No output schema exists, but the 'reports whether' statement gives sufficient guidance. A bit more on side effects or return format would improve completeness, but it's nearly 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 100%, so the baseline is 3. The description only restates 'by id' and the schema already documents the 'reports whether a fact was actually removed' behavior, adding no new parameter-level 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?

The description states a specific verb and resource: 'Remove a fact by id'. It also adds context on why ('to correct or drop something stale'), and the sibling set (remember, recall) makes the distinct purpose clear.

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

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

The description gives clear usage context with 'to correct or drop something stale', implying when to use this tool. It doesn't explicitly list alternatives or when-not-to-use scenarios, but the intention is fairly clear.

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 discloses that the output is a list of headings and frames the tool as context-saving, but it does not explicitly state that the operation is read-only, has no side effects, or how it behaves if AGENTS.md is missing. For a simple list operation, these are minor gaps but still present.

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 entire description is one concise sentence of about 24 words. The action is front-loaded ('List the headings'), and the rationale provides useful context without any 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 zero-parameter listing tool, the description covers the action, the target, and the reason to use it. It does not specify the exact return format (e.g., plain list vs markdown), but since no output schema exists, a bit more detail about the response shape would improve completeness.

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

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

There are zero parameters, so the baseline is 4 per rubric. The description adds meaning by saying 'this project's AGENTS.md', indicating the target is fixed to the current project and no path or filter argument 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 states a specific verb ('List') and a specific resource ('the headings in this project's AGENTS.md'), and explains the purpose ('so a client can pull one section instead of spending context on the whole file'). It clearly distinguishes this tool from siblings like read_agents_md, which reads the full file.

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: when a client wants to retrieve only the section headers rather than the full document. The phrase 'instead of spending context on the whole file' contrasts with reading the entire file, effectively pointing at read_agents_md as the alternative, but it does not name alternatives or state explicit when-not conditions.

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 present, so the description carries the full burden. It discloses the kind of data returned (context sources, media types, discovery surface) and 'list' implies a read-only operation. However, it doesn't explicitly state there are no side effects or mention edge cases like empty results.

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

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

The description is two concise sentences that front-load the core function and then add the usage context. Every word earns its place; no fluff.

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 tool with no output schema and no annotations, the description fully captures what the agent needs: what the tool does, what it returns, and when to use it. Nothing critical 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 has zero parameters, so the baseline is 4. The description doesn't need to elaborate on inputs, and it doesn't omit anything relevant.

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

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

The description clearly states the tool lists which context sources (AGENTS.md, memory, identity) are published, their media types, and the discovery surface. This is specific and distinct from sibling tools like read_agents_md or list_agents_md_sections.

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 a clear usage scenario: 'For a client connecting cold.' This tells an agent when to use the tool. It doesn't explicitly mention alternatives or when not to use it, but the scoped purpose makes it obvious.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. 'Return' implies a read operation and the whole-file-or-section scope is clear, but the description does not explicitly state it has no side effects, how missing sections behave, or any return-format details. It is adequate but not rich.

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 first sentence is concise, front-loaded, and behaviorally precise. The second sentence is somewhat non-essential and motivational, but it is short and helps position the tool's purpose without bloating the description.

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

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

For a simple one-parameter read tool with full schema coverage, the description is nearly complete: it states what is returned and the available modes. The main gap is not explicitly disambiguating from list_agents_md_sections, though the verb 'Return' and 'section by heading' make the distinction reasonably clear.

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

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

Schema description coverage is 100%, so the baseline is 3; the schema already documents the section parameter and the omit-for-whole-file behavior. The description adds only a slight contextual restatement ('or one section by heading'), providing no 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?

The description states a specific verb and resource: 'Return this project's AGENTS.md', and explicitly defines the two modes: whole file or one section by heading. This clearly differentiates it from sibling tools like author_agents_md (write) and list_agents_md_sections (list headings).

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

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

The phrase 'The instructions a client would otherwise have to know to look for and read wholesale' implies this is the entry point for pulling project instructions, but it never explicitly says when to prefer this over list_agents_md_sections or when not to use it. Usage context is implied, not stated with exclusions or alternatives.

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 behavioral burden. 'Retrieve' conveys a read-only action, 'exact lookup' clarifies matching semantics, and the schema property description discloses the not-found response. This is adequate transparency for a simple lookup tool.

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

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

Two short sentences with no wasted words. The action and resource are front-loaded, and the precision qualifier is presented immediately after the main purpose.

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

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

For a one-parameter lookup tool, the description plus schema property cover the operation, id semantics, and missing-id outcome. It could be more explicit about when to prefer this over sibling tools, but nothing essential is missing for a correct invocation.

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

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

Schema coverage is 100% and the id property already explains that it is the exact id from a previous remember call and what value will be returned. The description's 'exact lookup — not fuzzy or substring' reinforces behavior but adds little new parameter-level 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?

The description uses a specific verb ('Retrieve') and resource ('a fact stored in a previous session by id'), and the exact-lookup qualifier distinguishes it from fuzzy search behavior. It clearly positions this as the retrieval counterpart to remember.

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

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

The description implies the tool is for looking up a previously stored fact by exact id, but it does not explicitly say 'use this when you have an id from remember' or name an alternative for fuzzy/substring needs. The 'not fuzzy or substring' hint provides context but not concrete when-to-use 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?

No annotations are provided, so the description carries the full burden. It discloses that facts go to a .fafm file rather than memory, that reusing an id replaces text in place, and that new ids append. It also exposes the written verification_status. It does not describe return or failure behavior, but the core side effects are clearly stated.

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. Every clause adds a distinct behavioral fact, and there is no filler or repetition.

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 two-parameter write tool with no output schema, the description covers persistence location, update/replace semantics, append behavior, and written status. The main gaps are the lack of a return-value/confirmation description and explicit failure modes, but these are minor at this complexity.

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

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

Schema description coverage is 100%, and both id and text are already well-documented in the schema. The description mostly restates the id replacement semantics found in the schema, adding little parameter-level meaning beyond 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 the exact operation: persistently storing a fact past the session boundary, with explicit update-vs-append semantics. This clearly distinguishes it from read-oriented siblings like recall and read_agents_md.

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 when to use it: any fact that must survive the session or be updated by id. It does not explicitly contrast with recall/forget or state when not to use it, but the durable-write 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?

Without annotations, the description carries the burden. It discloses default collapsing behavior, the expanded parameter, and the HTTP alternative. It doesn't explicitly state read-only or side-effect-free, but 'render' implies no mutation.

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

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

Two sentences, front-loaded with the main purpose, then additional details. No 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?

All necessary information for invoking the tool is present: action, parameters, defaults, and alternative access method. Output format is succinctly described as an HTML page.

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 adds meaning for 'expanded' by explaining the default collapse and the expanded:true toggle. The HTTP query parameter ?expand=all is also noted. Theme and accent are already well-documented in 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 clearly states the tool renders the whole card as an HTML page for reading or screenshotting, listing the exact components (identity, AGENTS.md, memory, discovery). This distinguishes it from sibling tools that recall, forget, or edit individual memory sections.

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 use for human-facing presentation but doesn't explicitly contrast with alternatives like read_agents_md or whoami. It does mention the HTTP endpoint, but lacks a clear 'when to use vs. not use' statement.

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 disclosure burden. It discloses the source (.fafa card), the kind of data returned (identity fields), and implies a read-only introspection behavior. It could be more explicit about side effects or non-mutability, but for a simple identity query the disclosure is adequate.

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

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

The description is a single well-structured sentence that leads with the core purpose and then enumerates the specific fields returned. Every word contributes meaning, with 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?

For a zero-parameter, no-output-schema introspection tool, the description is complete: it names the identity source and lists the relevant fields an agent can expect. There are no hidden inputs, and the output scope is sufficiently specified.

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 accepts zero parameters, so there are no parameter semantics to document. The empty input schema is fully self-explanatory, and the description does not need to compensate for any 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?

The description clearly identifies what the tool returns: this server's own identity, explicitly listing name, vendor, version, status, and license from its .fafa card. This firmly distinguishes it from sibling tools that focus on agent markdown files, memory, and context sources.

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 makes it clear this tool is for retrieving server identity information, which is a distinct and self-contained purpose. It does not explicitly state when not to use it, but the contrast with sibling tools is strong enough that an agent can infer the appropriate context for invocation.

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