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

Annotations already declare readOnlyHint=true, idempotentHint=true and a closed world, and the description reinforces them with 'Does not write a file' rather than contradicting them. It adds real behavioral context beyond the annotations by disclosing the content provenance (repo facts, 'nothing invented') and the two-block output shape when a project.faf is 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?

It is a single front-loaded sentence with the verb and resource leading, and every clause carries information (provenance, quality tiers, no-write guarantee). The stacked parentheticals and BETTER/BEST framing make it denser to parse than it needs to be, costing it the top mark.

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 draft generator with no output schema or annotations about returns, the description supplies what the agent needs: the source of content, the no-write guarantee, and the file's managed-block structure. Details like draft length or how an existing AGENTS.md is handled are left unstated.

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 and there is no parameter semantics for the description to compensate for. It correctly omits any argument discussion rather than inventing options.

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 clear verb+resource: 'Author an AGENTS.md for this project and return the draft,' plus the key scoping fact that it 'Does not write a file,' which distinguishes it from save/write siblings. It never names the read/list siblings directly, so an agent must infer the boundary from the verb alone rather than being told 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?

It gives a usable precondition ('BEST when a project.faf exists') and a fallback path when it doesn't, which is genuine conditional guidance. However, it frames these as output-quality tiers (BETTER/BEST) rather than telling the agent when to choose this tool over alternatives like read_agents_md or list_agents_md_sections, so usage is only implied.

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 destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds genuinely new behavioral information not in the annotations: a missing id is reported rather than treated as an error, which tells the agent how to interpret a failed lookup.

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 clauses with the action front-loaded and the error-handling note second; every word earns its place and nothing is 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 one-parameter delete with no output schema, the description plus schema cover the essentials: what is removed, that a miss is reported, and that it is destructive/idempotent. It could say slightly more about what the report contains, but nothing needed to call it correctly 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 coverage is 100%, so the single 'id' parameter and its role are fully documented in the schema, establishing a baseline of 3. 'by id' in the description adds no syntax or format detail beyond 'the exact id of the fact to remove' already present 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?

States a specific verb and resource ('Remove a fact by id') plus the intent behind it, which is enough to separate it from siblings like remember and recall without opening either schema. It stops short of naming those alternatives explicitly, so it is clear but not maximally differentiated.

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 'to correct or drop something stale' gives a concrete when-to-use context (correction / stale data removal). There is no explicit when-not or named alternative, but for a single-purpose delete tool the usage trigger 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 and openWorldHint=false, so the safety profile is fully covered by structured fields. The description's added value is the context-cost rationale, which is useful but modest, and it says nothing about the shape of what is returned.

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: verb/resource first, rationale second. No waste and nothing buried.

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 full annotation coverage and no output schema, the description supplies everything needed to select it. The only gap is that it does not hint at the return payload (heading list structure), which is a minor omission.

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 per the rubric the baseline is 4; there is nothing for the description to disambiguate.

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 (headings in this project's AGENTS.md), so an agent can tell this apart from read_agents_md (full content) or author_agents_md (write). The contrasting sibling is only implied via 'instead of the whole file' rather than named, which keeps 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?

The trailing clause gives a clear situational rationale for the tool: use it to find a section so you can fetch just that part, saving context. It stops short of explicit when-not guidance or naming the follow-up tool (read_agents_md) directly.

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 openWorldHint=false, so the safety profile is covered. The description adds that this is a broad discovery probe returning content categories and discovery surfaces, but says nothing about response shape, ordering or what a cold client should do with the result.

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 zero filler, and the primary purpose is front-loaded before the audience qualifier. Nothing is repeated from 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?

For a zero-parameter, read-only discovery tool with annotations covering safety, the description gives enough to call it: it names the categories and surfaces returned. With no output schema, a fuller sketch of the returned structure would have pushed this higher.

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 schema carries no semantics to compensate for; the baseline of 4 applies. The description's enumeration of content types is about return content, not input, so it neither helps nor hurts here.

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 discovery action and enumerates the resource categories it covers (AGENTS.md, memory, identity) plus the dimensions it reports (media types, discovery surface). It implicitly reads as the umbrella lister over siblings like read_agents_md, list_agents_md_sections and whoami, but never names them, 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?

"For a client connecting cold" gives a genuine usage context (session-start discovery), which is more than nothing. However, it offers no explicit alternatives or exclusions, and with near-overlapping siblings (list_agents_md_sections, read_agents_md, whoami) an agent could still pick the wrong tool.

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 openWorldHint=false, so the safety profile is covered. The description adds only the justification for the tool's existence and the output granularity; it says nothing about behavior when a heading doesn't match, since the case-insensitive prefix match detail lives in the 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?

Two sentences, front-loaded with the primary action and output modes. The trailing clause about what a client would otherwise have to look for is rationale rather than instruction, so it is mildly expendable but not harmful.

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 annotations covering safety and no output schema, the description sufficiently conveys what is returned (whole file or a named section). Missing only edge-case behavior when no section matches, which is a minor 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 100% and the single parameter is fully documented there, including the case-insensitive prefix-match semantics. The description only restates the same whole-file-vs-section choice, adding no syntax or format detail beyond the schema. 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 ('Return this project's AGENTS.md') plus the two output modes (whole file or one section by heading). This clearly separates it from the sibling write tool author_agents_md and from list_agents_md_sections, which only lists 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 whole file, or one section by heading' implies when to use the section parameter, but the description gives no explicit guidance such as 'use list_agents_md_sections first to discover headings' or any exclusion. Usage is inferable but not 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 cover read-only, idempotent, and closed-world behavior. The description adds meaningful context beyond that: it retrieves facts stored in a previous session and performs exact matching only — a behavioral constraint that prevents an agent from expecting fuzzy results. It doesn't discuss auth or rate limits, but none are implied.

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 core action and immediately followed by the key constraint. Every word earns its place; 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 single-parameter read tool, the description, schema, and annotations together cover all an agent needs: what it does, how to call it, the exact-match constraint, the return behavior (via schema), and the safety profile (via annotations). 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?

Schema coverage is 100%, and the schema already documents that the id must be the exact id from a previous remember call, including the possible 'no memory for <id>' response. The description's 'by id' and 'exact lookup' reinforce but do not add syntax or format details beyond what the schema provides, 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 (Retrieve) and resource (a fact stored in a previous session), scoped by id. The phrase 'Exact lookup — not fuzzy or substring' clearly distinguishes it from broader search or fuzzy-match operations, and the verb contrasts naturally with siblings like remember and forget.

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 clear context: use when you have an id from a previous remember call, and explicitly excludes fuzzy/substring lookups. However, it does not name alternative tools or describe when to prefer remember/forget/list operations, so it stops short of full when/when-not/alternatives 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 already declare destructiveHint=true and idempotentHint=true, but the description earns credit by explaining why: reusing an id overwrites that fact's text in place while a new id appends, and storage is a .fafm file rather than memory. It also discloses the side effect of tagging facts verification_status: unverified, which is not derivable from the schema or 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?

Three tight clauses, no padding, with the most decision-relevant information (persistence across sessions, overwrite-vs-append) front-loaded. Every sentence 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?

For a two-parameter, no-output-schema write tool with full annotation coverage, the description supplies storage location, overwrite semantics, and the unverified flag — enough to call it correctly. Return behavior is left unstated, but the tool plausibly returns nothing meaningful, so the gap is minor.

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 id and text are already fully documented in the schema, including the id-reuse rule stated there as well. The description adds no new parameter-level detail (syntax, format, limits) beyond what the schema provides, so the baseline of 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 and resource ('Persist a fact') plus the crucial scope distinction that it survives the session boundary via a .fafm file rather than memory. The id-reuse vs append semantics further pin down behavior. It does not name or contrast the related recall/forget siblings, so it falls short of the top mark.

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 its place — persisting facts across sessions — but gives no explicit when-to-use vs when-not, and never references the sibling tools (recall, forget, save_context_card) that an agent must choose between. The id-reuse note is behavioral, not selection 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 already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful non-schema context: the default collapsed rendering of AGENTS.md sections and the parallel HTTP endpoint with ?expand=all.

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 dense but front-loaded sentences; the core purpose leads and the behavioral detail follows. The em-dash content list is efficient, though the second sentence packs two unrelated facts (collapse default, HTTP route) together.

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 correctly characterizes the return value as one self-contained HTML page. Nothing critical is missing for a zero-required-parameter, read-only render tool, though it could note whether the response is the HTML itself or a reference to 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 100%, so all three parameters (theme, accent, expanded) are already documented with defaults and the accent hex format. The description only restates the expanded flag semantics, adding no new meaning beyond the schema. Baseline 3 is correct.

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 (render) and resource (the context card) and enumerates the content scope: identity, AGENTS.md, memory, discovery, output format (self-contained HTML page). An agent can distinguish this from save_context_card or read_agents_md 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?

Usage is implied rather than stated: 'a person can read or screenshot' signals a human-facing, presentation use case, and it notes the equivalent HTTP route (GET /card). However, there is no explicit when-to-use, when-not, or named alternative among siblings (e.g. save_context_card vs render).

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 flag destructiveHint=true and idempotentHint=true; the description adds the concrete consequence ('Replaces any earlier context-card.html') and the browser-open side effect, which the boolean hints cannot convey. It does not mention failure modes or permission requirements, so it stops short of full coverage.

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 sentences, front-loaded with the action and artifact, with no filler. The return-value sentence and the alternative-routing sentence are both load-bearing; slightly dense but 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?

With no output schema, the description carries the return contract itself ('the card as Markdown ... plus a clickable link'), lists the returned content sections, and discloses the overwrite and browser-open side effects. Nothing an agent needs to call it correctly 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 the schema already documents all five optional parameters (open, theme, accent, detail, expanded), including defaults and enum values. The description adds nothing parameter-specific, 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?

States a specific verb and artifact: 'Write the context card to context-card.html in the project.' It also names the output (Markdown plus a link) and contrasts itself with the sibling render_context_card, so an agent can distinguish the two 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?

'Use this instead of pasting render_context_card's HTML into a chat that can't display it' names the alternative tool and the condition that selects this one. The local-vs-remote behavior of the browser-open step is also stated, so the routing decision and the execution context are both 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 cover the safety profile (readOnly, idempotent, not open-world), and the description adds genuinely useful context beyond them: the contents returned and the source of truth (its .fafa card), which aligns with openWorldHint=false. It is silent on failure behavior when no card exists, so it stops short of full disclosure.

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 the identity statement first and the field/source detail immediately after. Every clause earns its place with 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 parameters and no output schema, the description usefully compensates by listing the fields that come back. It is nearly complete; only edge behavior (missing/invalid .fafa card) is unaddressed, which is a small gap for an identity probe.

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 schema baseline of 4 applies. Nothing in the description is needed to explain inputs, and none is misdescribed.

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 the specific resource (the server's OWN identity, not the caller's) and enumerates the returned fields (name, vendor, version, status, license). This disambiguates it well against siblings like list_context_sources or read_agents_md, though it never names an alternative 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?

Usage is only implied: an agent infers it should call this when it needs to know what server it is talking to. There is no explicit when-to-use, when-not-to-use, or named alternative among the sibling tools, but for a trivial zero-argument probe the omission is minor.

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