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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the note is persisted and returns a generated id, but says nothing about permissions, duplicate handling, size limits, or error behavior for a 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 tight sentences with no filler; the core action is front-loaded and the return-value note is a single efficient 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 two-parameter create tool with no output schema, the description helpfully discloses the return value (the note id), compensating for the absent output schema. Only auth/error context 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 both required params (title, body) are already documented in the schema. The description only restates them without adding format, length, or uniqueness semantics. 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 (Create) and resource (persisted note) with the two defining fields (title, body). It clearly differs from read-oriented siblings like get_note/list_notes, though it doesn't name any sibling 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 mention that the returned id is 'needed later to fetch or delete it' hints at a create-then-get/delete workflow but never states when to prefer this tool over alternatives or any 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?

With no annotations, the description carries the full behavioral burden. It usefully flags that the sentence count is approximate and that the output is deterministic statistics plus a hash, but it does not state that the operation is read-only/non-mutating, nor how the hash is encoded (hex, casing), which matters for a checksum 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 sentences, no filler; the enumerated output list is front-loaded and the usage cue follows. 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, and the description compensates by enumerating exactly what is returned, including the approximation caveat. What remains missing is error/edge behavior (empty input, encoding assumptions), but nothing essential to calling the tool is absent.

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 is a single parameter and schema description coverage is 100%, so the schema already defines 'text' fully. The description adds no syntax or format detail beyond it, making this the baseline case where structured fields do the work.

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 gives a specific verb ('compute exact statistics') plus the resource (a block of text) and enumerates the exact outputs (characters, words, lines, sentences, SHA-256 hash), which clearly separates it from the read/write file and note siblings. It never names the closest sibling, transform_text, so an agent must still infer the boundary between analysis and transformation.

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?

"Useful whenever an exact count or checksum matters" is an implied usage cue, but it gives no explicit when-to-use/when-not-to-use guidance and does not point to transform_text or any alternative for related tasks. Adequate context, no routing information.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses irreversibility via 'Permanently delete,' which is the single most important trait for a destructive tool, but says nothing about required permissions, behavior on a nonexistent id, or whether any confirmation/soft-delete path exists.

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 short sentence with the destructive qualifier ('permanently') front and center, and zero filler. Nothing is wasted, though the terseness is close to under-specification.

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 delete with no output schema the essentials are present, but a destructive tool with no annotations should ideally state permissions, failure modes, and non-recoverability. It is adequate but leaves real gaps an agent would want covered.

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 lone parameter is already documented as 'The note id to delete.' The description's 'by its id' merely restates the schema, 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?

States a specific verb (delete) plus resource (note) and the selector (by its id), which cleanly distinguishes it from siblings like get_note, add_note, and list_notes. It stops short of explicitly naming an alternative, but the action is unambiguous.

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 when-to-use guidance, no statement of prerequisites or permissions, and no mention of alternatives or when this should be avoided. The agent must infer the entire usage context from the tool name alone.

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 usefully discloses that output is truncated to a safe length and that only http/https is permitted, but omits auth requirements, redirect/error behavior, timeouts, and any mention that POST with a body is supported despite the schema allowing it.

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 the core action front-loaded and the constraint (http/https only, truncation) trailing. 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?

With no output schema, the description does explain what is returned (text, truncated), which is the key missing piece. The main residual gap is that POST/body usage is never mentioned even though the schema supports 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 the schema already documents url, body, and method (including the GET/POST enum and GET default). The description adds no parameter-level detail beyond the schema, 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?

The description gives a specific verb and resource: 'Fetch the contents of a public http(s) URL and return the response body as text.' This clearly separates it from file-oriented siblings like read_file or list_directory, though it never names an alternative 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?

'Useful for reading web pages, JSON APIs, or other public HTTP resources' gives implied usage contexts, but there is no explicit when-to-use vs. when-not-to-use guidance and no reference to sibling tools such as read_file for local content.

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 supplied, so the description carries the full behavioral burden. It usefully discloses the return payload (title and body), but says nothing about behavior for unknown ids, missing permissions, or whether the fetch is read-only/idempotent. Adequate for a trivial read, but thin.

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 verb and resource, with zero wasted words while still naming the return payload.

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 is fetched and what comes back. It is nearly complete, missing only error/absence behavior for an unknown id.

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 id parameter is fully documented in the schema as coming from add_note or list_notes. The description only restates 'by its id', adding no format or validation detail beyond the schema, 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 (Fetch), resource (note), scope (one note by id), and what is returned (full title and body). This implicitly distinguishes it from list_notes, but it never names the sibling or explicitly contrast, 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?

Usage is implied by 'by its id' – reach for it when you have a single id – but there is no explicit when-to-use statement, no mention of when list_notes or read_file would be preferable, and no prerequisite 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 provided, so the description carries the full burden. The verb 'Report' implies a non-mutating read with no side effects, which is the key behavioral trait, but it says nothing about permission requirements, whether values are live or cached, or any rate/cost considerations.

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, zero filler; the scope (what is reported) is front-loaded and the use case follows. 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, and the description compensates well by enumerating the returned fields (OS, CPU, memory, uptime, local time) so an agent knows what to expect. The only gap is that it doesn't specify the format or units of the returned values.

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 no parameters, so there is nothing to document and the baseline of 4 applies. The description correctly does not invent parameter 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 action ('Report information about the machine running this MCP server') and enumerates the resources returned (OS, CPU, memory, uptime, local time). This is unambiguous and cannot be confused with any sibling such as read_file or get_note.

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 offers a usage context ('useful for diagnostics or environment-aware suggestions') but does not state when to prefer this over any alternative or any preconditions. With zero parameters and no competing sibling, this is adequate implied guidance rather than explicit routing.

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

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

With no annotations, the description carries the full burden and does disclose the key behavioral trait: the directory lives in a sandboxed workspace, implying confinement and relative paths. It omits whether listing is recursive, what errors occur for missing directories, and any permission/size constraints.

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, zero filler, with the core action stated first and the default-path rule second. Everything 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 single-parameter read tool with no output schema, the description covers the essential scope and the default path behavior. It could note recursion behavior or flag that the output is a listing rather than file contents, but 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 description coverage is 100%, so the baseline is 3. The description restates the default behavior ('Omit path to list the workspace root') and adds the sandbox framing, but does not add syntax constraints beyond what the schema already documents.

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 (files and subdirectories in a directory) scoped to the server's sandboxed 'workspace', which is clear and immediately actionable. It does not explicitly name a sibling tool, but the intent is unambiguous against read_file/write_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 gives one concrete usage rule ('Omit path to list the workspace root'), which tells the agent how to invoke it for the root case. It offers no guidance on when to prefer this over siblings like read_file or how it relates to listing notes.

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

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

With no annotations, the description carries the behavioral burden and discloses scope ('every stored note'), sort order ('most recently updated first'), and returned fields. It does not explicitly state read-only status or mention pagination, permissions, or rate limits, which are minor but real gaps.

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

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

Two sentences, front-loaded with the core purpose and return fields, followed by the alternative routing. Every sentence 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?

No output schema exists, so the description appropriately explains return values (id, title, timestamps) and ordering. For a zero-parameter list tool, the purpose, return content, and get_note routing make it complete enough to invoke 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?

The tool has zero parameters, so the rubric baseline is 4. The description adds nothing about parameters, but there is nothing for it to clarify.

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 specific verb 'List' and resource 'every stored note', then enumerates the returned fields (id, title, timestamps) and ordering. It distinguishes itself from sibling get_note by explicitly directing full-body fetches there.

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?

Explicitly names the relevant alternative: 'Use get_note to fetch a note's full body.' This tells an agent exactly when to choose get_note over list_notes, with no misleading gaps.

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 usefully discloses the sandbox and relative-path constraint, but says nothing about failure behavior (missing path, binary files), size/encoding limits, or whether the operation is strictly read-only, all of which matter for a filesystem 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, no filler, with the sandbox scope front-loaded before the path-format guidance. Every sentence 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 single-parameter read tool with no output schema, the description covers scope, path semantics, and return content ('full text contents'). It is nearly complete, with only edge-case behavior (errors, binary data) 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?

Schema description coverage is 100% and the single parameter is fully documented there, so the baseline is 3. The description adds only concrete path examples ('welcome.txt', 'notes/todo.txt'), which is marginal value over the schema's 'relative to the workspace root' wording.

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 ('Read the full text contents of a file') plus a scope qualifier ('inside the server's sandboxed workspace directory') that an agent can use to distinguish it from write_file and list_directory without opening any 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 by the verb and by the sandbox scope, but the description never states when to use this versus siblings such as list_directory or write_file, nor does it name any exclusions or preconditions (e.g. 'use list_directory first to discover paths').

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 disclosure burden. It adds one genuinely useful behavioral claim — the transformation is deterministic — but says nothing about error handling, empty/non-ASCII input, or idempotency guarantees beyond determinism.

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 states the operation and lists all valid styles with zero filler. Nothing could be removed without losing 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?

For a two-parameter, deterministic, non-mutating utility with full schema coverage and no output schema, the description covers what an agent needs to select and call it correctly. Only edge-case behavior is 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?

Schema description coverage is 100%, so both parameters are already documented in the schema, including the enum of valid styles. The description repeats that enum list without adding format, ordering, or edge-case nuance, 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?

The description gives a specific verb (transform) plus resource (text) and enumerates the five target case styles, so the agent knows exactly what the tool produces. It does not distinguish itself from any sibling such as analyze_text, but the function is unambiguous.

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: an agent can infer that this is the tool for case conversion, but there is no explicit when-to-use, when-not-to-use, or pointer to alternatives like analyze_text. Minimum viable for a single-purpose utility.

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

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

With no annotations, the description carries the full burden and does add real behavioral context: writes are confined to a sandboxed workspace directory, and parent directories are auto-created. It discloses the overwrite/destructive nature implicitly via 'overwrite' but says nothing about encoding, error behavior, or path-escape handling.

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, zero filler, with the core create/overwrite action front-loaded before the secondary parent-directory detail. Every sentence 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 2-parameter write tool with no annotations and no output schema, the description covers purpose, sandbox scope, and the auto-mkdir behavior, which is enough to invoke correctly. It leaves the overwrite consequences and error/return behavior unstated, a minor gap given the low 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 parameters are documented in the schema itself, so the baseline is 3. The description adds no path syntax, relative-path rules, or content format details beyond what the schema already provides.

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

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

The description gives a specific verb pair ('create or overwrite') on a specific resource ('a text file') scoped to the 'workspace' directory, so an agent immediately knows this is the write counterpart to read_file. It never names a sibling or contrast case, so it stops short of the top band.

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: the agent can infer 'write a file' from create/overwrite semantics. There is no explicit when-to-use, when-not-to-use, or pointer to an alternative tool, so the guidance is the minimum viable.

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