Free-core agent tools with typed schemas (diff, cron, units, JSON→TS, golden hour, pack weight, prompts). No account required.
Scored across 47 tools
Most tools target distinct operations, and local-ops tools are clearly tagged so agents can avoid confusion. There is minor overlap among product-facing tools and several status/list tools, but the descriptions are specific enough to separate them.
All names are lowercase snake_case and generally readable, but the action position is inconsistent: get_product and extract_urls sit alongside csv_select and cron_explain, plus noun-only names like lorem_ipsum. This reduces predictability without becoming chaotic.
With 47 tools, the server is far beyond the typical well-scoped range and reads as a general-purpose grab bag rather than a focused API. Each utility may be small, but the sheer number makes selection and onboarding harder.
The utility side is broad and covers many common text, data, and time tasks, but the product and local-ops surfaces have noticeable gaps: no product create/update/delete, no analytics read-back, and no way to execute or clear queued actions. These are workable gaps rather than fatal dead ends.
Encode text to base64 or decode base64 to UTF-8 text.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | Base64 string (decode mode) | |
| mode | No | encode | decode (default encode) | |
| text | No | Plain text (encode mode) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must convey behavior. It accurately states the transformation (encode/decode to/from UTF-8) but does not disclose edge cases such as invalid base64 input handling, behavior when both text and data are provided, or return format specifics. It is not misleading, but it lacks depth.
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, tightly worded sentence that immediately conveys the tool's purpose. Every word contributes, and it is front-loaded with the primary verb 'Encode' and the resource 'base64'.
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?
Given the tool's simplicity, the description covers the essential function, and the schema covers all parameters. Since there is no output schema, the description implicitly conveys the return value by explaining the transformation. It lacks explicit error-handling info but is otherwise complete for a straightforward utility.
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 parameters are fully documented in the schema. The description adds minimal extra meaning beyond the schema; it merely echoes encode/decode without elaborating on parameter interactions or formats. Baseline of 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?
The description clearly states the tool's function: encoding text to base64 and decoding base64 to UTF-8 text. It uses specific verbs and resources, and is easily distinguished from sibling utility tools (e.g., hash_text, html_escape) by its explicit base64 focus.
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 when to use the tool (for base64 encoding/decoding) but provides no explicit guidance on when to choose it over alternatives or mention any exclusions. The mode parameter is described in the schema, but the description itself does not offer usage direction beyond the core function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain a 5-field cron expression (minute hour day-of-month month day-of-week) in plain English.
| Name | Required | Description | Default |
|---|---|---|---|
| expr | Yes | Cron expression, e.g. "0 9 * * 1-5" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the input scope (5-field) and the nature of the output ('plain English'), but does not mention validation behavior, error handling, or the exact output format. This is minimal but adequate for a simple read-only utility.
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 front-loads the verb and resource, with no unnecessary words. It perfectly balances brevity and informativeness.
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 utility with no output schema, the description is complete: it explains what the tool does, what input it expects, and what the output looks like ('plain English'). No additional context is necessary.
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 schema already documents the 'expr' parameter with an example, and the description adds the field order ('minute hour day-of-month month day-of-week'), enriching the parameter's meaning beyond the schema. Since schema coverage is high, this extra context boosts the score above 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?
The description clearly states the tool's function with a specific verb ('Explain') and resource ('5-field cron expression'), and it identifies the exact field order. This distinguishes it from any sibling tools, which are all unrelated utilities.
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 clearly implies when to use the tool: whenever a 5-field cron expression needs translation to plain English. It does not explicitly discuss alternatives or exclusions, but no sibling tool serves a similar purpose, so the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pick and reorder CSV columns by name or 1-based index. Handles quoted fields; emits csv, json, or markdown.
| Name | Required | Description | Default |
|---|---|---|---|
| csv | Yes | CSV text | |
| output | No | csv (default) | json | markdown | |
| columns | No | Column names or numbers, in output order (default all) | |
| delimiter | No | Single char (default ,) | |
| has_header | No | First row is a header (default true) |
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 adds value by stating that it 'handles quoted fields' and 'emits csv, json, or markdown', which informs the agent about input robustness and output behavior. It does not mention side effects (likely none) but this is a read/transform tool; adequate for the context.
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 sentence that packs essential information: purpose, key capabilities (handle quoted fields, output formats). No filler or redundant content. Well-structured and front-loaded.
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?
The tool is moderate complexity with 5 parameters and no output schema. The description covers the core functionality but omits details like what happens with missing headers, how to specify columns by name vs. index, or potential errors. With no annotations and no output schema, a bit more detail would be helpful, but the schema provides full parameter documentation, so it is adequate.
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 describes all parameters. The description adds some context (e.g., ability to reorder by name/index, output formats), but does not elaborate on parameter syntax (e.g., how to specify columns) beyond what the schema already provides. Meets the baseline of 3 given high schema coverage.
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 ('Pick and reorder') with a clear resource ('CSV columns'), and mentions the key options (by name or index, output formats). It clearly distinguishes from siblings like 'csv_to_markdown' by focusing on column selection/reordering and multiple output formats, though it doesn't explicitly name the alternative.
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 usage for selecting/reordering columns and specifying output format, but does not explicitly state when to use this tool over alternatives like csv_to_markdown. It provides no when-not-to-use conditions (e.g., if needing only conversion, use csv_to_markdown). Guidance is minimal but not misleading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert CSV text (comma-separated, optional quoted fields) into a GitHub-flavored markdown table.
| Name | Required | Description | Default |
|---|---|---|---|
| csv | Yes | CSV text including header row | |
| delimiter | No | Field delimiter (default ",") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It discloses that the tool handles optional quoted fields, which is a useful behavioral detail beyond the schema. However, it does not mention edge cases like empty fields, newlines, or error handling, leaving some transparency gaps for a transformation 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?
The description is a single, concise sentence that front-loads the core function. Every word adds value, with no redundancy or 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 simple two-parameter converter with no output schema, the description adequately specifies input format (CSV with optional quoted fields) and output (GitHub-flavored markdown table). It is complete enough for the tool's complexity, though it could mention handling of delimiters beyond the schema default.
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 covers both parameters (csv and delimiter) with 100% description coverage. The tool description does not add any additional semantic meaning beyond what the schema already provides, so it stays at the baseline for high schema coverage.
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's function: converting CSV text into a GitHub-flavored markdown table. It uses a specific verb ('convert') and names both the input (CSV text) and output (markdown table), distinguishing it from sibling conversion tools like json_to_ts.
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 clearly implies when to use this tool: whenever you have CSV text and want a markdown table. However, it does not explicitly mention alternatives or when not to use it, though no sibling tool appears to be a direct alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Line-by-line diff of two text blobs. Returns unified-style +/- lines and add/remove/unchanged counts.
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | Original text | |
| b | Yes | Modified text |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It clearly states the tool returns unified-style +/- lines and counts, which describes the operational behavior. While it doesn't mention edge cases like whitespace handling, the pure-function nature makes this level of transparency 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 two sentences, with the main action front-loaded. The second sentence efficiently summarizes the return value. Every word earns its place, and there is no redundant or extraneous 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?
Given the tool's simplicity, the description fully covers what it does and what it returns. There is no output schema, but the return format is explicitly described. No missing side effects or prerequisites exist, making the description contextually complete.
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 schema provides 100% coverage with descriptions for both 'a' (Original text) and 'b' (Modified text). The description only refers to 'two text blobs' without adding any details beyond the schema, so no additional semantic value is provided. 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?
The description opens with 'Line-by-line diff of two text blobs,' which clearly identifies the verb (diff) and resource (two text blobs). It distinguishes this tool from siblings, none of which perform diffing, making the purpose 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?
The description clearly implies when to use the tool: whenever two text blobs need comparison. It doesn't explicitly state alternatives or exclusions, but given the tool's unique role among siblings, this context is sufficient. The phrase 'Returns unified-style +/- lines' also sets expectations for the output.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Strip an email body down to what was actually written: removes quoted replies, signatures, mobile footers, tracking params, unsubscribe lines, and invisible characters.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Email body (plain text or markdown) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It clearly lists the transformations performed (removes quoted replies, signatures, mobile footers, tracking params, unsubscribe lines, invisible characters) and the outcome ('down to what was actually written'). However, it does not disclose any limitations or edge cases, such as behavior with non-text formats, but the explicit list provides solid transparency.
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 front-loads the primary action ('Strip an email body down...') and then enumerates the specific removals, achieving high informational density with zero wasted words. It is concise and immediately readable.
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 tool with one straightforward parameter and no output schema, the description sufficiently explains the tool's function and scope. It does not explicitly state the return value, but 'strip down' implies the cleaned text is returned. Given the simplicity, the description is complete enough for an agent to understand and invoke the tool appropriately.
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 provides 100% coverage for the single parameter 'text' with a clear description. The tool description does not add any additional meaning beyond the schema, but since the schema already fully documents the parameter, the baseline of 3 is appropriate. There is no extra nuance, but none is needed for this simple 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?
The description uses a specific verb 'Strip' with a clear resource 'an email body' and enumerates exactly what is removed (quoted replies, signatures, etc.), making the tool's purpose unambiguous and distinct from the sibling tools, none of which offer similar email-specific cleaning functionality.
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 clearly implies use when an email body needs cleanup, but it does not explicitly state when to prefer this over alternatives or any exclusions. There is no guidance on when not to use it, such as for preserving formatting or handling HTML emails. Still, the purpose is specific enough that usage context is inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract unique http(s) URLs from free text.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
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 two behavioral traits: uniqueness (deduplication) and scheme filtering (http/https). However, it does not mention output format, handling of malformed URLs, or any edge-case behavior, leaving significant 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?
The description is one short, front-loaded sentence. Every word earns its place, with no redundant fluff or repetition of schema details.
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 extraction tool with a single parameter and no output schema, the description covers the core purpose and input. However, it omits what the return value looks like (e.g., array of strings), which is a notable gap for a complete understanding.
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 one required string parameter 'text' with no description (0% schema coverage). The description adds the meaning that this parameter is 'free text', which clarifies its nature beyond the schema. It does not elaborate on encoding or formatting, so the compensation is partial.
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 extracts unique http(s) URLs from free text. The verb 'extract' and resource 'unique http(s) URLs' are specific, and it distinguishes itself from sibling text tools like diff_text or regex_test.
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 usage: when you need to pull URLs out of arbitrary text. However, it provides no explicit guidance on when to prefer this over alternatives (e.g., regex_test) and no exclusion criteria. The context 'free text' hints at the input type but does not elaborate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[Local ops] Read-only always_on/loop_health snapshot for the operator’s ADP host (returns available:false on public Vercel). Not a portable product tool.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden and it does well: it discloses read-only safety, host affinity, and the public Vercel failure mode. It does not describe the full return payload, but that gap is minor for a zero-parameter snapshot 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?
The entire description is a single, front-loaded sentence that packs the environment, safety, resource, host, and Vercel behavior. Every phrase earns its place with no padding.
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 no-parameter, no-output-schema local status tool, the description covers purpose, environment, safety, and a key platform-dependent behavior. It could mention what 'available' refers to or differentiate from forge_status, but it is largely complete for selection purposes.
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 and 100% schema coverage (empty schema), so the baseline is 4. The description adds no parameter-specific detail, but none is needed.
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 phrase ('Read-only ... snapshot') and names the exact resource ('always_on/loop_health' on the operator's ADP host). It also distinguishes the tool from siblings by stating it is a local ops tool and 'not a portable product tool.'
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 label '[Local ops]' immediately signals the intended environment, and the explicit warning 'Not a portable product tool' tells agents when to avoid it. It also notes a key context condition ('returns available:false on public Vercel'), but it does not name a specific sibling alternative such as forge_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Public forge status: hub URL, MCP endpoint, conversion API, product count, manifesto surfaces.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It tells the agent that the forge status is 'public' (no auth required) and lists the returned information, but does not mention potential side effects, data freshness, or behavior beyond read-only. For a status tool this is moderate transparency.
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 concise sentence that front-loads the core purpose ('Public forge status') and then lists the specific data surfaces. It is efficient and contains 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?
Given the tool has no parameters and no output schema, the description is reasonably complete: it names the resource (forge status) and enumerates all returned data items. However, it could further explain the format or purpose of these surfaces (e.g., what 'manifesto surfaces' means), leaving a small 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 tool has zero parameters, and the schema is empty. The baseline for a no-parameter tool is 4, and the description correctly omits parameter details since none exist. No parameter information is needed.
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 indicates the tool provides 'public forge status' and enumerates the specific data surfaces (hub URL, MCP endpoint, conversion API, product count, manifesto surfaces). It is distinct from sibling tools which address other utilities, but it lacks an explicit verb like 'get' or 'retrieve.'
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?
No guidance is given on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or use cases, leaving the agent to infer that it should be used whenever forge status is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[Local ops] Get one gbrain note by name (e.g. northern-forge.md). Operator host only.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Note filename, e.g. nf-mcp-flagship.md |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the local scope and host restriction, which are important behavioral traits. It does not detail error handling or return format, but for a simple read operation this is acceptable.
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, front-loaded sentence that efficiently conveys purpose, scope, and an example with no extraneous 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?
Given the tool's simplicity (one parameter, no output schema), the description covers the essential aspects: what, how, and constraints. It lacks a note on alternatives or behavior when the note is absent, but remains sufficient for the tool's 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?
The schema fully describes the 'name' parameter as a note filename with an example. The description adds an alternative example but provides no additional meaning beyond the high schema coverage, 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 clearly states the action ('Get one gbrain note by name') and identifies the resource (gbrain note via filename). It distinguishes itself from sibling tools like gbrain_list and gbrain_search by specifying retrieval by exact name.
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 provides context with '[Local ops]' and 'Operator host only', indicating when this tool is appropriate. However, it does not explicitly name alternatives or exclusions, relying on the implied difference from list/search siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[Local ops] List cached gbrain note names + utility metrics. Operator host only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It discloses that the operation is local, cache-based, and restricted to the operator host, which implies a read-only listing. However, it does not explain failure modes, permissions, or what 'utility metrics' consist of.
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, front-loaded sentence with a clear scope tag and a separate host restriction. Every phrase earns its place; no filler or redundant explanation.
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 tool, the description covers the core purpose and host restriction. The vague phrase 'utility metrics' is a notable gap, as the agent cannot know exactly what metrics are returned or in what form.
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 input schema already shows an empty properties object, and the description adds no parameter information because none is needed.
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 ('List') and resource ('cached gbrain note names') with an added scope ('utility metrics', 'Operator host only'). It clearly differs from siblings like gbrain_get and gbrain_search by indicating a listing/enumeration operation.
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 '[Local ops]' prefix and 'Operator host only' restriction provide clear usage context and an exclusion (do not run outside the operator host). It does not explicitly name alternatives such as gbrain_get or gbrain_search, but the local/cached scoping makes the intended environment clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[Local ops] Search ADP gbrain notes (Justin cache + local NF entities). No secrets. available:false off operator host.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max notes (default 6) | |
| query | No | Keywords (e.g. frigate mcp cash) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits itself. It adds 'No secrets' as a safety note and 'available:false off operator host' as an availability constraint, which are useful beyond the schema. However, it does not clarify the return format, pagination, or whether the operation is strictly read-only, leaving gaps in transparency.
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 sentence, front-loaded with the action 'Search ADP gbrain notes' followed by qualifiers. It avoids wordiness, though the phrase 'available:false off operator host' is somewhat cryptic and could be clearer, but it does not significantly waste space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and 100% parameter schema coverage, the description provides adequate context for a simple search tool: it identifies the data sources, safety (no secrets), and availability. It does not specify the return structure, but given the simplicity of the tool and the clarity of the query/limit parameters, it is reasonably complete.
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 schema covers 100% of the parameters (limit and query) with descriptions, so the baseline is 3. The tool description does not add any extra meaning about how to format the query or interpret the limit, relying on the schema's existing documentation.
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 begins with '[Local ops] Search ADP gbrain notes' which clearly states the verb (Search) and resource (ADP gbrain notes), distinguishing it from siblings like gbrain_get and gbrain_list. The addition 'Justin cache + local NF entities' further specifies the data sources, making the tool's purpose 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?
The description implies usage through 'Search' and mentions 'Local ops', but it does not explicitly state when to prefer this tool over the sibling tools gbrain_get or gbrain_list. There are no exclusions or alternative recommendations, so the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return known Stripe payment link URL for a product if configured (pro unlock).
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does disclose the conditional nature ('if configured'), but does not specify what happens when not configured (e.g., returns null, empty, or errors). No auth, rate limits, or other behavioral context is provided.
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 sentence that conveys all essential information without redundancy. It is front-loaded and every word contributes to the meaning.
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 tool with no annotations or output schema, the description is too sparse. It lacks edge-case behavior (e.g., unconfigured products), parameter semantics, and any additional context an agent would need to invoke the tool reliably.
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 schema has one parameter (product_id) with 0% description coverage. The tool description merely says 'for a product' but does not clarify whether product_id is a Stripe ID, internal ID, or its expected format. It fails to compensate for the schema's lack of documentation.
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 action ('Return'), the resource ('known Stripe payment link URL for a product'), and the condition ('if configured'). It distinguishes itself from sibling tools like get_product and list_live_products by focusing specifically on the payment link.
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: use this tool when you need the Stripe payment link for a product. However, there is no explicit guidance on when not to use it or mention of alternatives, such as get_product for product details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one product by product_id or slug.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | product_id or slug |
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 only states the action ('Get') without detailing return behavior, error handling, or permissions. For a read operation, the verb implies safety but does not explicitly disclose traits like 404 responses or full product object structure.
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 concise sentence with no extraneous words, front-loading the 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?
The description adequately states the tool's purpose and required identifier, but lacks any mention of return format or error behavior. Given the tool's simplicity, it is minimally viable but not fully complete.
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 already provides 100% coverage of the parameter 'id' with the description 'product_id or slug'. The tool description repeats this information, adding no additional 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 uses the specific verb 'Get', identifies the resource as 'one product', and specifies the lookup key ('product_id or slug'). It clearly distinguishes from sibling 'list_live_products' which lists products.
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 usage when a single product is needed by ID or slug, providing clear context. However, it does not explicitly mention alternatives or when not to use, such as comparing with 'list_live_products'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute approximate sunrise/sunset/golden-hour windows for lat/lon/date (no API key). MVP solar math.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitude | |
| lon | Yes | Longitude | |
| date | No | ISO date YYYY-MM-DD (default today UTC) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It discloses that results are 'approximate' and that it uses 'MVP solar math', which is important behavioral context. However, it does not mention potential limitations such as timezone handling, edge cases, or the exact output format, leaving some 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?
The description is a single concise sentence that front-loads the main action ('Compute') and resource ('sunrise/sunset/golden-hour windows'). It includes valuable qualifiers ('approximate', 'no API key', 'MVP solar math') without any redundant wording, making every word earn 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?
Given the absence of an output schema, the description should explain return values, but it only implies outputs through the phrase 'sunrise/sunset/golden-hour windows'. It does not mention timezone or time format, which is relevant for astronomical times. The inclusion of 'approximate' and 'MVP' gives some context, but overall the description is not fully complete for a complex calculation tool.
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% with all three parameters described (lat, lon, date). The description adds no additional meaning beyond what the schema already provides, simply restating 'for lat/lon/date'. Thus, a baseline score of 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?
The description clearly states the tool computes approximate sunrise, sunset, and golden-hour windows for lat/lon/date using specific verbs and a specific resource. It distinguishes itself from sibling tools by focusing on solar calculations, which none of the siblings address. The 'MVP solar math' note further clarifies the scope.
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 provides clear context for usage by mentioning 'no API key', indicating this is a self-contained alternative to API-based services. It also qualifies the tool as 'MVP solar math', suggesting it is for approximate estimates. However, it does not explicitly name alternatives or state when not to use the tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current and longest streak from a list of completed days, with completion rate and the days that were missed.
| Name | Required | Description | Default |
|---|---|---|---|
| dates | Yes | Completed days as YYYY-MM-DD | |
| today | No | Evaluate as of this day (default today, UTC) | |
| allow_gap_days | No | Rest days that do not break a streak (default 0) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as whether the operation is read-only, has side effects, handles invalid input, or enforces rate limits. The description only states what it computes, not how it behaves beyond that.
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, concise sentence that directly states the tool's purpose without any fluff or redundancy. It is well-structured and easy to parse.
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?
The description explains the key outputs (current streak, longest streak, completion rate, missed days), which is critical since no output schema is provided. It lacks some edge-case details but covers the main return values adequately.
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 already provides descriptions for all three parameters, including defaults, so schema coverage is high. The tool description adds no extra meaning about how parameters affect the result, so the baseline score of 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?
The description clearly states the tool computes current and longest streak, completion rate, and missed days from a list of completed days. This is a specific verb-resource-action that distinguishes it from the many unrelated sibling tools.
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 usage when a list of completed dates is available and streak metrics are needed, but it does not explicitly state when to use this tool over alternatives, nor mention any exclusions or prerequisites. It is clear enough but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hash a string with sha256 / sha1 / md5 (hex). Local crypto — no network.
| Name | Required | Description | Default |
|---|---|---|---|
| algo | No | sha256 | sha1 | md5 (default sha256) | |
| text | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: local execution ('Local crypto'), no network dependency, and hex output. It does not detail error behavior for invalid algorithm names, but for a simple hashing tool, this 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?
One concise sentence with all essential information front-loaded. No wasted words, and the security/network note is a valuable extra.
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 tool with no output schema and no annotations, the description covers the primary purpose, algorithms, output format, and local behavior. It doesn't need to explain return values since a hash string is self-evident.
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 50% (algo has description, text does not). The description compensates by clarifying 'Hash a string' implies the text parameter is the input to hash, and the algorithm list matches the schema. This adds meaning beyond the schema for the text 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?
The description clearly states the tool hashes a string using sha256/sha1/md5, specifying the exact algorithms and output format (hex). This distinguishes it from sibling utilities like base64_codec or diff_text, which perform different transformations.
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 provides clear context: this is a local hashing operation with no network usage, which implies when to use it. However, it does not explicitly name alternative tools or state when not to use it, though the simple utility nature makes this less critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a webhook HMAC signature (GitHub / Stripe / Slack / raw schemes). Computes the expected digest, compares in constant time, and checks the replay window.
| Name | Required | Description | Default |
|---|---|---|---|
| algo | No | sha256 (default) | sha1 | sha512 | |
| scheme | No | raw | github | stripe | slack (default raw) | |
| secret | Yes | Shared signing secret | |
| payload | No | Raw request body, byte-for-byte | |
| signature | No | Signature header to check (optional; omit to just compute the expected value) | |
| timestamp | No | Unix seconds or ISO time — required for stripe/slack | |
| tolerance_seconds | No | Replay window (default 300) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It states it 'computes the expected digest, compares in constant time, and checks the replay window,' which are key behavioral aspects. However, it omits details like error handling, whether secret is required, and exact scheme differences, but overall it is reasonably transparent.
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, front-loaded with purpose, and every sentence adds value. It avoids verbosity and clearly explains the core behavior without unnecessary details.
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 7-parameter tool with no output schema, the description conveys the main purpose and key behaviors (constant-time compare, replay window). While it doesn't detail each parameter, the schema already covers that. It is sufficient for an agent to decide when to use it, but could mention potential caveats like timestamp formats or default tolerances.
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 description doesn't need to repeat parameter details. It adds some context (e.g., constant-time comparison, replay window) but does not elaborate on individual parameters (like timestamp format), leaving schema to carry most of the 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 clearly states the tool's purpose: 'Verify a webhook HMAC signature' with specific schemes (GitHub, Stripe, Slack, raw). It distinguishes from sibling tools like hash_text (which hashes) and jwt_decode (which decodes), so the agent knows exactly when to use this tool.
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 usage for webhook signature verification, but does not explicitly mention when to use it versus alternatives (e.g., hash_text for plain hashing). It lacks explicit 'use when' or 'do not use' guidance, leaving some ambiguity about boundary cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[Local ops] Read per-host notes from host_memory_set. Operator host only.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | ||
| host_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full behavioral burden. It discloses that this is a local, read-only, operator-host-only operation, but it does not describe behavior for missing keys, return format, or error 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?
The description is one concise sentence front-loaded with the purpose and includes a clear access constraint. 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?
The tool is a simple getter, and the description covers purpose and access restrictions. However, without annotations or an output schema, the missing param semantics and return behavior keep it from being fully self-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 0%, and the description only implicitly maps 'host_id' via 'per-host'. The optional 'key' parameter is not explained, leaving its role ambiguous despite being a core part of the input 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 uses a specific verb and resource ('Read per-host notes') and explicitly names the companion storage operation (host_memory_set). This clearly differentiates it from the sibling 'host_memory_set' tool.
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 indicates the tool is for reading notes stored by host_memory_set and adds an operator-host-only constraint. However, it does not explicitly state when not to use it or mention alternatives beyond the source name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[Local ops] Save a small per-host note. Local file write only; available:false off operator host.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| value | Yes | Note text (max 2000 chars) | |
| host_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of behavioral disclosure. It reveals that the tool performs a local file write and has an availability constraint ('available:false off operator host'), but these are cryptically stated. It does not disclose idempotency, overwrite behavior, or error handling, leaving significant 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?
The description is concise, with the core purpose front-loaded in the first sentence. The second sentence is terse but adds key constraints. No wasted words, though the phrasing 'available:false off operator host' is awkward.
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?
Given the lack of annotations and output schema, the description does not fully cover the tool's context. It omits return value behavior, error conditions, and parameter semantics. For a simple tool it is minimally complete but leaves too much to inference.
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 only 33% (only 'value' has a description). The description adds no parameter-level detail, forcing the agent to infer the roles of 'key' and 'host_id' from context. It does not compensate for the low schema coverage.
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 'Save a small per-host note' – a specific verb (Save) and resource (per-host note). The phrase 'Local file write only' further clarifies the operation, distinguishing it from a read tool like host_memory_get.
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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of scenarios, prerequisites, or comparisons to sibling tools like host_memory_get. The description merely states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Escape or unescape HTML entities (& < > " ').
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | escape | unescape (default escape) | |
| text | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It mentions the core operation and the entities handled, but does not disclose edge cases such as whether existing entities are double-escaped, behavior for non-listed characters, or the return format. This is minimal but not misleading.
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, front-loaded sentence with no redundancy. It conveys the full purpose and key details efficiently.
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 text transformation tool, the description covers the essential purpose and entity set. However, it does not explicitly describe the return value (since there is no output schema), and the 'text' parameter lacks documentation. Still, it is largely complete for its simplicity.
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% (only 'mode' has a description, 'text' does not). The description adds meaning by specifying the HTML entities involved, which implies the content of 'text', but it does not elaborate on parameter behavior beyond what the schema already states for 'mode'.
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 'Escape or unescape HTML entities (& < > " ')' clearly states the action (escape/unescape) and the target resource (HTML entities), listing specific characters. This distinguishes it from sibling utilities like base64_codec or hash_text, which perform different transformations.
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 usage (when you need to escape or unescape HTML) but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions. It is adequate but lacks contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return ready-to-paste MCP install snippets for Cursor, Claude Desktop, and generic HTTP clients.
| Name | Required | Description | Default |
|---|---|---|---|
| client | No | cursor | claude | generic (default all) |
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 'Return' implies a read-only operation, and the description states what is returned (snippets). However, it does not explicitly mention side effects, auth needs, or error conditions. For a simple utility, this 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 description is a single, front-loaded sentence that conveys all essential information without unnecessary words. It is perfectly sized for the tool's simplicity.
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 tool with one optional parameter and no output schema, the description fully explains what the tool does and for which clients. No additional context is needed to invoke it 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 schema description covers 100% of the parameter 'client' with explicit allowed values and default. The description adds no extra parameter detail, 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 clearly states the tool returns ready-to-paste MCP install snippets for specific clients (Cursor, Claude Desktop, generic HTTP). This distinguishes it from sibling tools like list_mcp_tools, which list tools rather than provide config snippets.
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 context is clear: use this tool when you need install snippets for MCP clients. There are no explicit exclusions or named alternatives, but the description implicitly covers when to use it. The sibling tools are utilities, and this one stands apart as a config-snippet generator.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Infer TypeScript interfaces from a JSON string (or object). Local, no LLM. Caps depth/size for agent safety.
| Name | Required | Description | Default |
|---|---|---|---|
| json | Yes | JSON text to convert (preferred) | |
| root_name | No | Root interface name (default Root) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool runs locally (no network), does not rely on an LLM, and caps depth/size for safety. These are valuable behavioral traits beyond what the schema reveals.
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 clean sentences: first states the purpose, second adds safety and operational context. No fluff, front-loaded, 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 conversion tool, the description covers purpose, behavior, and safety. It doesn't detail error handling or exact return formatting, but the output is inferred as TypeScript interfaces, which is sufficient for the tool's 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 coverage is 100%, so baseline is 3. The description adds nuance by mentioning the input can be a JSON string or object, which is not fully captured by the schema's 'string' type. It also hints at depth/size limits that affect parameter handling.
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 action ('infer') and the resource ('JSON string or object') with a specific output (TypeScript interfaces). It distinguishes the tool from all sibling utilities, which are unrelated conversion/formatting tools.
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?
'Local, no LLM. Caps depth/size for agent safety.' provides context on when to use it (offline, deterministic, safe for agents) without explicit exclusions or alternative tool names. The usage context is clear, but no 'when not to use' is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decode JWT header + payload (no signature verify). For inspection only.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | JWT string |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It explicitly discloses that signature verification is not performed and that it's for inspection only. However, it does not mention behavior for invalid tokens or the return format, which would increase transparency.
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, concise sentence with no filler. It front-loads the key action and caveat efficiently.
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 decode tool with no annotations or output schema, the description covers the core function and main limitation. It could briefly mention what the decoded output looks like, but overall it is sufficiently complete.
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% as the token parameter is described as 'JWT string'. The description does not add extra semantics beyond what the schema already provides, so 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?
The description clearly states the specific action (decode) and resource (JWT header + payload), and adds a critical caveat (no signature verify). This distinguishes it from sibling utility tools like base64_codec or hash_text.
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 'For inspection only' provides clear context for when to use the tool. It also implies not to use it for security verification, though it does not explicitly name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Northern Forge live products (title, url, blurb, monetization). Free core tool for agents.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Optional filter: web_tool | mcp_server | agent_skill | |
| limit | No | Max products (default 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It adds value by specifying the output fields and 'live' status, and 'Free' hints at no cost. However, it does not explicitly state read-only behavior, auth requirements, default limit behavior, or pagination details, which would enhance transparency.
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 short, purposeful sentences. It front-loads the main action and resource, and every word earns its place with no redundant or vague content.
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 list tool with two optional parameters and no output schema, the description provides the resource and output fields, but it omits mention of the kind filter, limit/pagination behavior, and relationship to sibling tools like list_mcp_tools or get_product. This leaves some contextual gaps for an agent deciding to use 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 input schema fully describes both parameters (kind and limit), so the baseline is 3. The description does not add any parameter-specific detail beyond the schema; the parenthetical list focuses on output fields, not 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?
The description clearly states 'List Northern Forge live products' with a specific verb and resource, and enumerates the returned fields (title, url, blurb, monetization). This distinguishes it from siblings like get_product (single item) and list_mcp_tools (a different resource type).
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 'Free core tool for agents' implies it is a basic, freely available listing operation, but there is no explicit guidance on when to choose this over alternatives such as get_product or popular_tools. No exclusions or when-not-to-use conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List this server tools with schemas (self-describe).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 mentions the tool lists tools with schemas but does not explicitly state side effects or safety (e.g., read-only). The behavior is inherently non-destructive, but the description lacks any elaboration beyond the basic function.
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 concise sentence with a parenthetical clarification. Every word earns its place, and the key information is front-loaded.
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?
This is a simple tool with no parameters and no output schema. The description fully explains that the tool lists server tools and schemas, which is complete for such a straightforward self-description capability.
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 adds 'with schemas', which clarifies the output format, but no parameter semantics are needed.
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 the server's tools with their schemas, using the specific verb 'List' and identifying the resource. It distinguishes itself from sibling tools, which are individual utilities, by being a self-describing meta-tool.
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 'self-describe' implies using this tool to discover available tools and their schemas. It provides clear context for when to use it, though it does not explicitly mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[Local ops] Read-only mesh snapshot from operator command-center cache (available:false off-host).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max nodes to return (default all) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description explicitly states 'Read-only' and 'from operator command-center cache' and an availability constraint, disclosing key behavioral traits such as non-mutation, data source (cache), and local-only availability. This exceeds minimal transparency for a no-annotation 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?
The description is a single sentence, front-loaded with '[Local ops]', and efficiently packs context, read-only nature, source, and availability into a concise phrase. Every word serves a purpose with 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?
The description provides source, availability, and read-only nature, and the schema documents the limit parameter. However, with no output schema, it does not explicitly describe the return format or clarify what 'mesh' and 'node' mean, leaving some gaps for a complete invocation picture.
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 only parameter 'limit' is fully documented in the schema with 'Max nodes to return (default all)', and the tool description adds no additional meaning about the parameter. With schema description coverage at 100%, the baseline of 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?
The description states 'Read-only mesh snapshot from operator command-center cache', clearly identifying the resource and read-only nature, and the tool name 'list_mesh_snapshot' implies listing. However, 'mesh' is ambiguous and the description does not explicitly differentiate from other list_* sibling tools.
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 provides clear usage context with '[Local ops]' and an availability constraint '(available:false off-host)', which effectively indicates when not to use (off-host). It does not mention alternatives or specific when-to-use scenarios beyond local ops.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[Local ops] List actions previously appended by queue_action.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max rows (default 20, max 200) | |
| status | No | Optional filter, e.g. "queued" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a read operation via "List" and mentions provenance, but it does not disclose ordering, pagination, side effects, or whether actions are persisted or consumed. Minimal but not misleading.
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 sentence, front-loaded with the "[Local ops]" context, and has no filler. Every word adds value, achieving excellent conciseness.
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?
Given the tool's simplicity (2 optional parameters, no output schema, no annotations), the description is adequate but minimal. It states what it does and its relation to queue_action, yet leaves out potential behavioral details like action lifecycle or return format, which 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?
Schema description coverage is 100%, with both 'limit' and 'status' having clear descriptions in the schema. The tool description adds no further parameter details, but the schema already provides sufficient meaning, warranting the baseline score.
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 a specific verb and resource: "List actions previously appended by queue_action." This distinguishes it from the sibling queue_action tool and other list/status tools by explicitly linking it to the queueing mechanism.
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 provides clear context, indicating it lists queued actions, so an agent knows when to invoke it. However, it does not explicitly mention when not to use it or cite alternative tools, though none are obvious siblings for this exact operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate placeholder lorem paragraphs/sentences (offline).
| Name | Required | Description | Default |
|---|---|---|---|
| sentences | No | Sentences per paragraph 2–8 (default 4) | |
| paragraphs | No | 1–6 (default 1) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosure. It mentions the 'offline' behavior, which is useful, but it does not specify output format, randomness, or other behavioral traits. Since this is a simple, non-destructive generator, the lack of additional detail is acceptable but not complete.
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, front-loaded sentence that maximizes information per word. Every element ('generate', 'placeholder lorem', 'paragraphs/sentences', 'offline') contributes to understanding, 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?
For a simple tool with two optional parameters and no output schema, the description covers the essential purpose and the offline constraint. It could mention that the output is plain text, but that is largely implicit. Given the low complexity, the description is sufficiently complete for an agent to invoke the tool.
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 schema covers 100% of the parameter descriptions (sentences per paragraph and paragraph count with defaults). The description adds no extra parameter semantics beyond what the schema already provides, so the baseline score of 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?
The description clearly states the tool's function with a specific verb ('Generate') and resource ('placeholder lorem paragraphs/sentences'). It also adds a distinguishing detail ('offline'), which helps differentiate it from any online placeholder generators. The purpose 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?
No explicit guidance is provided on when to use this tool versus alternatives. The description implies use for placeholder text, but it does not mention any exclusions or alternative tools. The 'offline' note hints at one benefit but is not framed as a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render Markdown to email-safe HTML with inline styles only (no , no external assets), plus a plaintext alternative.
| Name | Required | Description | Default |
|---|---|---|---|
| markdown | Yes | Markdown source |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It discloses key constraints (inline styles only, no <style>, no external assets) and the output includes a plaintext alternative. However, it doesn't mention potential limitations (e.g., unsupported Markdown features, handling of images, or whether the plaintext is derived from the HTML or the original Markdown). This 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 description is a single, well-structured sentence that front-loads the core purpose and then adds key constraints. Every word earns its place; no fluff 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?
Given the tool's moderate complexity (Markdown conversion with specific output constraints), the description covers the essential behavior: input (Markdown), output (email-safe HTML with inline styles + plaintext alternative), and constraints (no <style>, no external assets). With no output schema, the description adequately explains what the agent can expect. It could mention edge cases or unsupported features, but for a single-parameter tool, this is largely complete.
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 schema has 100% coverage for the single parameter 'markdown' with description 'Markdown source'. The tool description adds context about the transformation (to email-safe HTML) but doesn't add syntax or format details beyond what the schema provides. Baseline 3 is appropriate since the schema already documents the parameter fully.
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's function: 'Render Markdown to email-safe HTML with inline styles only (no <style>, no external assets), plus a plaintext alternative.' It uses a specific verb ('Render') and resource ('Markdown to email-safe HTML'), and distinguishes itself from siblings like 'html_escape' and 'email_clean' by specifying the email-safe, inline-styles constraint and the plaintext alternative.
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 when to use this tool: when you need to convert Markdown to HTML suitable for email, with the explicit constraint of inline styles and no external assets. It doesn't explicitly state when not to use it or name alternative tools, but the context is clear enough for an agent to select it over siblings like 'html_escape' or 'email_clean'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cost of a meeting from attendee count or per-role rates. Returns total, burn per minute, per attendee, and annualised cost if it recurs.
| Name | Required | Description | Default |
|---|---|---|---|
| minutes | Yes | Meeting length in minutes | |
| currency | No | Label only (default USD) | |
| attendees | Yes | Head count, or [{role,count,hourly_rate}] | |
| recurrence | No | daily | weekly | biweekly | monthly | |
| hourly_rate | No | Default loaded hourly rate (default 75) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. It discloses the conditional 'annualised cost if it recurs', the input flexibility (attendee count or per-role rates), and the exact outputs returned. This is sufficient for a simple calculation tool, though it does not describe error handling or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with purpose, followed by a compact output list. Every word contributes value; no filler or repetition of schema details. Excellent structure for the information conveyed.
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?
Given no output schema, the description adequately explains return values. It also conveys the two input modes and the recurrence condition. The schema covers parameter details, so overall the tool is well-specified. A minor gap is not mentioning that currency is label-only (though the schema already covers this), so the description is not misleading.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds mild meaning by linking attendees to 'per-role rates' and recurrence to 'annualised cost', but does not explain formatting or defaults beyond what the schema already provides. No significant additional parameter insight is offered.
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?
Description clearly states the tool calculates meeting cost from attendee count or per-role rates, and enumerates the outputs (total, burn per minute, per attendee, annualised cost). This distinguishes it from all sibling tools, which are unrelated or focus on other calculations.
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 intended use case is implied by the purpose statement but not stated explicitly. No guidance is given for when to choose this tool over alternatives, nor any exclusions or prerequisites. The 'cost of a meeting' framing is self-evident enough to infer usage, but explicit when-to-use context is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current time as ISO-8601 UTC, unix seconds, and optional IANA timezone label (offset only — no full tz DB).
| Name | Required | Description | Default |
|---|---|---|---|
| offset_minutes | No | Local offset from UTC in minutes (e.g. -240 for EDT) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral disclosure. It explicitly says the output formats (ISO-8601 UTC, unix seconds) and discloses a key limitation: the IANA timezone label is derived only from the offset, not a full timezone database. This is useful context that goes beyond the schema, though it does not explicitly state the tool has no side effects.
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, front-loaded sentence that states the core purpose and key limitation without any filler. Every word contributes useful information, making it highly concise and well-structured.
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 stateless tool with one optional parameter and no output schema, the description fully covers the purpose, return formats, and a crucial limitation. The agent has enough information to invoke it correctly without needing further details.
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 schema already documents offset_minutes with an example, giving 100% coverage. The description adds meaning by linking this offset to the optional IANA timezone label, clarifying that the parameter controls the label output. This enriches the parameter semantics beyond the schema's simple 'local offset' description.
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 that the tool returns the current time in ISO-8601 UTC, unix seconds, and optionally an IANA timezone label. It is the only time-related tool among the siblings, so its purpose is unmistakable, even though it lacks an explicit verb like 'get' or 'fetch'.
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 when to use this tool: whenever the current time or timestamp is needed. The parenthetical 'offset only — no full tz DB' provides a caution about its limitations, effectively telling the agent not to use it for full timezone database lookups. However, it does not explicitly name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sum gear pack items in grams. items: [{name, grams, qty?, class?}] where class is base|worn|consumable. Returns total, base weight (the comparable number), pack weight excluding worn, and the three heaviest items.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral transparency. It discloses the return values, the meaning of each output component, and the expected item classes (base|worn|consumable). This exceeds minimal disclosure and gives the agent clear expectations of what the tool computes. It does not explicitly state side effects (e.g., persistence), but the read-only nature is strongly implied by the computation-focused verb and output.
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, front-loaded with the action and resource, and packs essential details into a compact format. Every clause contributes: input structure, class meanings, and output components. There is zero fluff, making it easy for an agent to parse quickly.
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?
The tool is simple (one parameter, no output schema), and the description fully covers what the agent needs: input format, class semantics, and the exact computed results. The absence of an output schema is compensated by listing the four output values. No additional behavioral notes are necessary for this straightforward calculation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'items' benefits from the description's structural detail: '[{name, grams, qty?, class?}]' and the explicit class values. Although the schema already defines the properties, the description adds semantic meaning by explaining that 'class' dictates how weights are aggregated (base vs. worn vs. consumable) and that the output separates these categories. This goes beyond the schema's bare property definitions.
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 verb ('Sum') and resource ('gear pack items'), explicitly scoping the operation to grams. It distinguishes itself from sibling tools by being the only one that computes pack weight metrics, with specific output details (total, base weight, pack weight excluding worn, heaviest items).
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 its usage by defining the exact input format and output, making it clear when to invoke it. It does not explicitly state when not to use it or alternatives, but the specialized nature and sibling context leave little ambiguity. The return fields (e.g., 'base weight (the comparable number)') further guide correct usage for weight comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Percent change from old → new value (and absolute delta).
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Ending value | |
| from | Yes | Starting value |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It discloses that it computes percent change and absolute delta, but doesn't specify return format (e.g., object vs. number), edge cases like division by zero when 'from' is 0, or rounding behavior.
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 efficient sentence that front-loads the core function and the additional delta output. No filler or redundant 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?
No output schema exists, and the description only hints at output via 'absolute delta.' It does not explain the return structure, number formatting, or how invalid inputs (e.g., from=0) are handled, leaving some uncertainty for an agent invoking the tool.
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% ('Starting value' and 'Ending value'), so description adds no new parameter semantics beyond mapping 'from/to' to 'old → new.' This is baseline for full schema coverage.
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?
Clear and specific: 'Percent change from old → new value (and absolute delta)' states the exact computation. Distinguishes from siblings like diff_text (text diff) and unit_convert (unit conversion).
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?
No guidance on when to use this tool versus alternatives. Does not mention any exclusions or note that it's for numeric comparisons only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hot/popular product ranks from conversion analytics (when available). Falls back to catalog seeds.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Default 12 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a key behavioral trait: the source depends on conversion analytics availability and falls back to catalog seeds. This adds value beyond the schema, though it doesn't describe the exact output structure or any side effects, which are unlikely for a read-only ranking 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?
The description is a single, front-loaded sentence that immediately communicates the core function. It is concise with no unnecessary words, earning a perfect score.
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 tool with a single optional parameter and no output schema, the description gives the essential purpose and fallback behavior. However, it does not specify the return format (e.g., array of product IDs vs. objects with scores), which is a gap given the lack of an output schema.
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 schema already fully documents the only parameter 'limit' with its default value (12). The description adds no further explanation about how limit affects results, but since schema coverage is 100%, the baseline of 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?
The description clearly states the tool returns 'Hot/popular product ranks' based on conversion analytics with a fallback to catalog seeds. This specific verb+resource framing distinguishes it from sibling tools like list_live_products and get_product, which focus on listing or fetching individual products.
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 usage for popularity-based ranking and notes the 'when available' condition and fallback behavior, giving clear context for when to use it. However, it does not explicitly name alternatives or state when not to use it, though the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record an analytics event (product_view, product_open, card_click, agent_tool_call).
| Name | Required | Description | Default |
|---|---|---|---|
| meta | No | ||
| type | Yes | ||
| source | No | ||
| product_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a write operation ('Record') but does not mention side effects, validation, idempotency, permissions, or failure behavior. This is a significant gap for a mutation 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?
The description is a single sentence with no wasted words, and the key information is front-loaded. However, it is too terse to cover necessary behavioral details, so it loses a point for sacrificing substance.
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 4 parameters (including a nested object), no output schema, and no annotations, the description is far too sparse. It omits parameter meanings, expected behavior, error handling, and return values, making it insufficient for an agent to invoke the tool effectively.
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 0%, so the description must compensate. It only provides example values for the 'type' parameter, leaving 'product_id', 'source', and 'meta' completely unexplained. No clarification of required vs. optional roles 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 clearly states the tool's purpose with a specific verb ('Record') and resource ('analytics event'), and lists concrete examples of event types. This effectively differentiates it from the sibling tools, which are unrelated utilities.
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 provides no explicit guidance on when to use this tool versus alternatives. Usage is only implied by the verb and context, with no exclusions, prerequisites, or references to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Split a goal+notes blob into Claude / GPT / Grok oriented prompt variants (local, no LLM call).
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | ||
| notes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses a key behavioral trait ('local, no LLM call') indicating no external call, but it doesn't describe side effects, output format, or determinism. For a transformation tool this is acceptable but incomplete, as it could mention whether the input is mutated or what exactly the output looks like.
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 a single, front-loaded sentence that gets straight to the point. There is zero waste, with all words contributing to the meaning.
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?
This is a simple utility tool with two parameters and no output schema. The description effectively covers the input (goal+notes), the operation (split), and the output (prompt variants for Claude/GPT/Grok). It could be more complete by specifying the number of variants or the exact format, but for a tool of this complexity, the essentials are 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 coverage is 0%, so the description must compensate. It mentions 'goal+notes blob' which implies the two parameters are combined into a single blob, giving some semantics beyond the bare schema. However, it doesn't elaborate on the individual meanings of 'goal' and 'notes' or clarify their role in the split, leaving partial clarity.
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 ('Split') and clearly identifies the resource ('goal+notes blob') and the output ('Claude / GPT / Grok oriented prompt variants'). It distinguishes itself from sibling tools by naming the specific models and noting it's local with no LLM call.
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 provides clear context: it's for splitting a goal+notes blob into model-specific prompt variants, with the key qualifier 'local, no LLM call' indicating when to use it (when you don't want an LLM call). However, it doesn't explicitly state alternatives or when not to use it, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[Local ops] Append a proposed action to a local review queue — does NOT execute. Operator host only.
| Name | Required | Description | Default |
|---|---|---|---|
| meta | No | Optional small structured extra context | |
| action | Yes | Plain-English action to queue for review | |
| source | No | Optional caller/agent id (default "agent") | |
| target | No | Optional target host/node |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the transparency burden. It discloses the critical non-execution behavior and the host restriction, which are important for safe use. It doesn't mention return behavior or persistence, but the key side effect (append) and non-side-effect (non-execution) are clear.
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 that packs essential information: scope, action, resource, and a critical safety note. No wasted words, and the most important detail ('does NOT execute') is front-loaded.
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 queue appending tool, the description covers the key points: what it does, its scope, and its non-execution behavior. It doesn't describe return values or follow-up steps, but given the simplicity and 100% schema coverage, it is sufficiently complete for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters, so the description adds little beyond the schema. 'Append a proposed action' maps to the 'action' parameter, but other parameters (meta, source, target) are already well-described in the schema, so no additional meaning is needed.
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 ('Append') and names the resource ('local review queue'), and clarifies it does NOT execute. This distinguishes it from execution tools and the sibling list_queued_actions, making the purpose 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?
It provides clear context with '[Local ops]' and 'Operator host only', and the explicit 'does NOT execute' implies when to use it (queueing instead of executing). However, it does not explicitly name alternatives or state when not to use it, so a small gap remains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate reading time for a blob of text (word/char counts, minutes and mm:ss at a given or default WPM).
| Name | Required | Description | Default |
|---|---|---|---|
| wpm | No | Words per minute (default 200) | |
| text | Yes | Text to measure |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does state the outputs (word/char counts, minutes, mm:ss) and mentions WPM configurability, which is helpful. However, it does not mention assumptions about input text (e.g., plain text vs markup), edge cases like empty text, or the exact return format, leaving some 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?
The description is a single, well-structured sentence that front-loads the core purpose and immediately follows with the output types. No redundancy or wasted words.
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?
The tool is simple, and the schema fully documents both parameters. The description explains the return values (word/char counts, minutes, mm:ss) since there is no output schema. Minor gaps remain, such as not indicating whether text length is limited or if HTML tags are stripped, but for a straightforward utility this is 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% for both parameters, with text and wpm already described, including wpm's default of 200. The description adds little beyond the schema, only using 'blob of text' and 'default WPM,' which the schema already covers. Baseline 3 is appropriate since the schema handles 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 uses a specific verb ('Estimate') and resource ('a blob of text'), clearly stating the tool computes reading time with word/char counts, minutes, and mm:ss. This distinguishes it from all sibling tools, which are other utility functions like word_freq or diff_text, so purpose 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?
The description implies the tool is for measuring reading time, but it does not explicitly state when to use it versus alternatives or provide exclusions. No guidance on when not to use it or how it compares to other text utilities (e.g., word_freq). Usage is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test a JS-style regex against text. Returns match count and up to 20 match slices.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| flags | No | Flags e.g. gi (default g) | |
| pattern | Yes | Regex pattern (no /slashes/) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the return type (match count and up to 20 match slices), which is useful, but it does not explain behavior on no matches, invalid patterns, or side effects. 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 description is two sentences, front-loaded with the primary purpose, and includes a concise summary of return behavior. Every word contributes meaning, with 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?
Given no output schema and no annotations, the description provides enough context for a simple regex tool by specifying the output format (count and slices). It lacks detail on the exact structure of slices, but for a basic test tool the description is sufficiently complete.
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 schema already covers pattern and flags with descriptions, and the description adds the context that 'text' is the target string. Since coverage is 67% and the missing text description is somewhat self-evident, the description adds marginal value over 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 tests a JS-style regex against text, which is a specific verb+resource combination. It also distinguishes from siblings by being the only regex-related tool, making its purpose 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?
The description implies the tool is used for testing JS-style regexes, and the context is clear given no sibling tools serve a similar purpose. However, it does not explicitly state when not to use it or mention alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[Local ops] Run one allowlisted read-only status command (uptime, disk, mem, loop board). No arbitrary shell. Public Vercel returns available:false.
| Name | Required | Description | Default |
|---|---|---|---|
| command_id | No | uptime | disk_usage | mem_usage | always_on_status | loop_board. Omit to list options. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It explicitly states read-only nature and the allowlist restriction, and reveals a key environment-dependent behavior (public Vercel returns available:false). It does not mention return format or error handling, but the read-only constraint is well covered.
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 concise – a single sentence plus a short note. It is front-loaded with the main purpose. The 'Public Vercel returns available:false' clause is slightly ambiguous but not wasteful.
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 tool with one optional parameter and no output schema, the description provides adequate context: purpose, scope, allowed commands, and environment constraints. Missing return format and invalid-input behavior, but the low complexity limits the need.
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%, with command_id already listing allowed values and noting that omission lists options. The description repeats these values without adding extra parameter-level semantics, so the schema does the heavy lifting.
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's function: running one allowlisted read-only status command, and it lists specific commands (uptime, disk, mem, loop board). It also distinguishes itself from an arbitrary shell, making its scope 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?
The '[Local ops]' prefix indicates the intended environment, and 'No arbitrary shell' clarifies when not to use it. The note about public Vercel returning available:false informs deployment limitations. However, it does not explicitly compare to sibling tools like forge_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert text into slug/kebab, snake_case, camelCase, PascalCase, CONSTANT_CASE, and Title Case variants.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to convert |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It does disclose the core behavior of producing multiple case variants, which is useful beyond the schema. However, it does not clarify the return structure (e.g., a single string, array, or object) or how edge cases like special characters are handled, leaving ambiguity.
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, front-loaded sentence that efficiently lists all supported variants with zero wasted words. It 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, so the description should explain what the tool returns. It does not specify whether the output is a string, an array of variants, or an object with named keys. This is a significant gap for an agent trying to predict the tool's 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?
The input schema fully describes the single 'text' parameter with 100% coverage. The description adds nothing beyond the schema's 'Text to convert' definition, 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 uses a specific verb ('Convert') with a clear resource ('text') and enumerates the exact output formats (slug/kebab, snake_case, camelCase, PascalCase, CONSTANT_CASE, Title Case). This distinguishes it from sibling text utilities like hash_text or base64_codec.
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 provides no guidance on when to use this tool versus other text utility siblings. There is no mention of when not to use it, no alternatives, and no context for choosing it over similar utilities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the hours where 2-12 IANA timezones are all inside working hours. Returns the best contiguous window plus a full 24h grid.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | YYYY-MM-DD (default today) — DST is resolved for that date | |
| zones | Yes | IANA zone names, e.g. ["America/Detroit","Europe/Berlin"] | |
| work_end | No | Local end hour, 1-24 (default 17) | |
| work_start | No | Local start hour, 0-23 (default 9) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does disclose the return values (best window and 24h grid) and the 2–12 timezone constraint, but it omits behavioral details such as DST resolution, handling when no overlap exists, or how 'best' is determined. Some behavioral context exists but it is not comprehensive.
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 concise sentences, front-loaded with the core action and immediately followed by the output. No filler or redundant content; every phrase 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 4-parameter tool with no annotations and no output schema, the description gives enough context to understand the primary behavior and return values. It covers the key concept and output structure, though it could be more complete regarding edge cases or the definition of 'best'—but the schema covers parameter details, so the gap is not severe.
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 adds no specific meaning beyond the schema—'working hours' hints at work_start/work_end, but the schema already states these with defaults. No additional parameter semantic value is provided.
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 ('Find') and resource ('2-12 IANA timezones') and clearly states the output ('best contiguous window plus a full 24h grid'). It distinguishes itself from sibling tools like golden_hour_windows by explicitly framing the operation around overlapping working hours across multiple IANA zones.
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 when to use the tool—when you need the hours when 2–12 timezones are all within working hours—but it does not reference sibling tools or provide explicit exclusions or alternative recommendations. This is implied usage rather than direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a numeric value between units: length, mass, volume, time, data size, and temperature.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Target unit, e.g. "mi", "kg", "fahrenheit" | |
| from | Yes | Source unit, e.g. "km", "lb", "celsius" | |
| value | Yes | Numeric value to convert |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states the general conversion capability. It does not mention return format, edge cases (e.g., temperature offset conversions), or unit string normalization, leaving the agent with incomplete behavioral context.
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 sentence and immediately states the tool's purpose. It is front-loaded and contains no redundant words, earning top marks for conciseness.
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?
The description lacks a list of supported unit abbreviations or an explanation of return values. Given that there is no output schema, the agent would need to guess valid unit strings (partial examples exist in the schema) and is not told what the converted result looks like, making the contextual information incomplete.
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 already describes all three parameters (value, from, to) with full coverage, so the description adds no new parameter-level information. The category list (length, mass, etc.) gives high-level context but does not map to specific parameter behavior.
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's verb ('Convert') and resource ('numeric value between units'), and enumerates six unit categories, which distinguishes it from the sibling utility tools (e.g., base64_codec, json_to_ts). This gives the agent a precise understanding of what the tool does.
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 usage when a conversion between these unit types is needed, but it does not explicitly state when to use it over alternatives, nor does it provide exclusions. Since no sibling tool performs unit conversion, alternative guidance is unnecessary, but explicit 'use when' phrasing is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate one or more UUID v4 strings (local crypto.randomUUID / fallback).
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | How many (default 1, max 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that generation uses local crypto.randomUUID with a fallback, which is a useful implementation detail indicating a local, stateless operation. However, it does not mention error behavior (e.g., invalid count), nor explicitly confirm non-mutating side effects, leaving some transparency 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?
The description is a single sentence of 15 words, front-loaded with the core purpose. The parenthetical about crypto.randomUUID/fallback is optional but relevant and does not bloat the text. Every word earns its place, making it an example of conciseness.
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 utility with no output schema, the description is nearly complete. It tells what the tool does and implicitly what it returns (UUID v4 strings). The only missing detail is whether the output is always an array or a single string for count=1, but this is a minor ambiguity and the description is sufficient for practical use.
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 schema already fully describes the only parameter 'count' with default and max values (100% coverage). The description adds little beyond saying 'one or more', which is already implied. Since the schema does the heavy lifting, the description's contribution is redundant, meeting the baseline 3.
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 the specific action 'Generate one or more UUID v4 strings' with a clear resource (UUID v4). It distinguishes itself from sibling utility tools like hash_text or regex_test by being explicit about generating UUIDs. The implementation note (local crypto.randomUUID / fallback) adds relevant context without muddying the purpose.
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 when to use this tool (whenever UUID v4 strings are needed) but does not provide explicit guidance on when not to use it or mention alternatives. No exclusions or caveats are given, so usage guidance is only implied, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WCAG relative luminance contrast ratio between two hex colors (#RGB or #RRGGBB). Reports AA/AAA pass for normal and large text.
| Name | Required | Description | Default |
|---|---|---|---|
| bg | Yes | Background hex color | |
| fg | Yes | Foreground hex color |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the behavioral disclosure burden. It discloses accepted formats (#RGB or #RRGGBB) and that it reports AA/AAA pass for normal and large text, which is more than minimal. It does not mention error handling but that is not critical for this utility.
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 front-loads the core function and reports the output. No unnecessary words 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 tool, the description covers input format, the calculation performed, and the reported results. It does not explicitly state the return value structure, but that is not essential given the simplicity and lack of output schema.
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?
Although the schema already describes 'fg' and 'bg' as foreground/background hex colors, the description adds the supported formats (#RGB or #RRGGBB), providing extra semantic value 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 clearly states the tool computes the WCAG relative luminance contrast ratio between two hex colors and reports AA/AAA pass for normal and large text. It uses a specific verb and resource, making the purpose unmistakable and distinct from sibling tools.
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 its use case: checking color contrast for accessibility compliance. It does not explicitly mention alternatives or exclusions, but the context is clear enough for a tool of this simplicity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Top word frequencies in text (case-insensitive, simple tokenizer).
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| limit | No | Top N words (default 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it is case-insensitive and uses a 'simple tokenizer', which provides some insight into its behavior. However, with no annotations provided, it doesn't mention whether it's read-only, what the return format looks like, or how punctuation and stop words are handled. This leaves significant behavioral aspects undisclosed.
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 concise sentence that front-loads the core function. Every word contributes meaning, 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?
The tool has no output schema, and the description does not specify the return format, ordering of frequencies, or whether a list of (word, count) pairs is produced. Given its simplicity, some information is still missing for a caller to fully understand the result.
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 schema documents the 'limit' parameter with a default value, and the description implies that 'text' is the input string, adding minimal context. Since the description does not explicitly describe the 'text' parameter's format or constraints, it only partially compensates for the low schema coverage.
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 the tool computes top word frequencies from text, naming the resource (text) and the nature of analysis. It distinguishes from sibling text tools by focusing on word frequency rather than formatting or conversion. However, the verb is implicit, so it's not a perfect 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 description provides no guidance on when to use this tool versus alternatives like diff_text or reading_time. It doesn't mention any exclusions or specific use cases. The context is only implied by the phrase 'word frequencies in text'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
csv_selectemail_cleanhabit_streakhmac_verifymarkdown_to_emailmeeting_costpack_weight_sum1 field changedInput schema / properties / items / items / properties / classAdded value: +{
+ "description": "base (default) | worn | consumable",
+ "type": "string"
+}timezone_overlapbase64_codeccron_explaincsv_to_markdowndiff_textextract_urlsforge_loop_statusforge_statusgbrain_getgbrain_listgbrain_searchget_payment_linkget_productgolden_hour_windowshash_texthost_memory_gethost_memory_sethtml_escapeinstall_configjson_to_tsjwt_decodelist_live_productslist_mcp_toolslist_mesh_snapshotlist_queued_actionslorem_ipsumnow_isopack_weight_sumpercent_changepopular_toolspost_eventprompt_variantsqueue_actionreading_timeregex_testrun_safe_cmdslug_caseunit_convertuuid_batchwcag_contrastword_freq
Add one secure layer between your agents and this server.