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

With no annotations, the description carries the full load and does disclose meaningful behavior: the read is free and charges no credits, and it is scoped to "this key". It doesn't cover auth prerequisites, latency, or freshness of the balance, which is a minor gap for a zero-arg status read.

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

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

Three short sentences, front-loaded with what is returned, followed by when to use it and the cost profile. Every sentence earns its place with no 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?

An output schema exists, so return-shape detail is unnecessary, and the description still previews the two returned values. For a parameterless read tool this is 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 tool takes zero parameters, so there is nothing to document and no ambiguity about arguments. Baseline of 4 applies.

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

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

States a specific verb (show) and resource (this key's remaining Singularis credits plus the cloud-equivalent dollars of compute delivered). The billing/account scope clearly separates it from the compute siblings (solve_heat, gemm, fft, etc.).

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

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

"Use before a large job, or when a user asks what Singularis has cost or saved" gives two concrete trigger conditions. It does not name alternative tools or state when not to use it, but the usage context is unambiguous.

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

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

No annotations are provided, so the description carries the full burden and largely meets it: it discloses the return value (blurred array or written path), adds a mass-conservation check, and warns that cost scales with pixels * sigma. It does not state whether writing to out_path overwrites existing files or what formats are writable.

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?

Front-loads the operation and resource, then packs inputs, return, and cost into short clauses with no filler. The keyword-list style ('smoothing, denoising, scale-space, preprocessing') is slightly loose but compact and informative.

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 an output schema present, the description needn't detail return formatting, yet it still names the return. Given no annotations, it covers safety-adjacent behavior, cost, and all four parameters adequately; only edge cases like overwrite semantics and supported output formats are missing.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it clarifies that 'image' is an inline array while 'path' is a file reference, that 'sigma' is in pixels, and that 'out_path' is optional and only for image files. The either-or relationship between path and image is captured, though the sigma default of 1 is left to the schema.

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

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

States a specific operation (Gaussian blur) on a specific resource (2D array or .npy/.png/.jpg image) with the controlling parameter (sigma). This is clearly distinguishable from siblings like singularis_fft, singularis_gemm, and singularis_compress.

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

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

Gives concrete use-case context ('smoothing, denoising, scale-space, preprocessing'), which tells the agent what class of problem this solves. It stops short of explicit when-not-to-use conditions or naming a sibling alternative, so it is clear context without routing guidance.

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

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

With no annotations, the description carries the full burden and does well: it states the lossless guarantee, the default output naming, and the existence of an exact-restore verification (hash of trial restore equals original). It omits overwrite behavior, permission/auth needs, and file size or rate limits.

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?

Front-loads the core purpose and usage, then parameter details, then the sibling routing. Efficient overall, though the return-value sentence is partly redundant given the tool has an output schema.

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

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

For a simple two-parameter tool with an output schema and no annotations, the description covers purpose, when to use, parameters, and the verification guarantee. Missing edge-case behavior (overwrite handling, failure modes) keeps it from being 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?

Schema coverage is 0%, so the description must compensate, and it does: path is described as a local file path and out_path is documented with its default (path + '.sing'). It does not cover path format constraints such as relative vs. absolute paths, leaving a small gap.

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

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

States a specific verb (Compress) and resource (a file) with a defining qualifier (exactly, lossless, bit-exact restore) that distinguishes it from sibling singularis_decompress. An agent knows immediately 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?

Explicitly lists use cases (archives, datasets, logs, model checkpoints, anything that must come back identical) and routes to singularis_decompress for the inverse operation. It implies when-not (anything not requiring bit-exact restore) but never states it outright.

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

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

With no annotations, the description carries the full burden, and it does disclose real behavior: bit-exact restoration and a post-restore hash check. However, it says nothing about overwrite behavior when out_path is omitted, handling of corrupt/non-.sing input, or any permission requirements — meaningful gaps for a mutation tool with zero annotation coverage.

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

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

Three short clauses, front-loaded with purpose, then inputs, then return value. No filler and no repetition of the tool name.

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

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

For a two-parameter, single-purpose tool with an output schema present, the description covers purpose, inputs, and return shape adequately. The return-value sentence partially duplicates the output schema, but the remaining gap is behavioral (error/overwrite handling) rather than structural.

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, and it does map both parameters at a basic level: path is the .sing file, out_path is optional. It does not explain what the default output location is when out_path is omitted, which is the main semantic ambiguity left open.

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

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

States a specific verb and resource ('Restore a file compressed by singularis_compress') and adds the distinguishing guarantee 'bit-exact'. It explicitly names its inverse sibling, so an agent can separate it from singularis_compress without inspecting either schema.

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

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

It gives clear context for when this tool applies ('a file compressed by singularis_compress', '.sing path'), which effectively routes the agent to it after a compress call. It stops short of explicit when-not guidance or failure/edge-case conditions, so it is not a 5.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose the return shape ('the recipe's result and its check, with cost') and flags that invocation has a cost, which is genuinely useful. It says nothing about behavior on an unknown/invalid recipe name, size limits, or whether dispatch mutates state, leaving meaningful gaps for a generic executor.

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

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

Three tight sentences: what it does, when to use it, what it returns. The examples are compact and load-bearing, and the routing condition is front-loaded. 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?

An output schema exists, so return values need not be detailed, yet the description still summarizes them. For an open-ended dispatcher with a free-form payload object, pointing at singularis_recipes as the schema source is the right move. The unexplained 'size' parameter is the one remaining hole.

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% across three parameters, so the description must compensate. It explains 'recipe' (a name from the library) and 'payload' (JSON payload) and helpfully redirects to singularis_recipes for per-recipe payload schemas. However, the third parameter 'size' is never mentioned or explained anywhere, so the compensation is only 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?

States a specific verb and resource ('Run any job from the Singularis recipe library by name') and immediately grounds it with concrete examples ('ridge', 'circulant_solve', 'kron_apply'). It explicitly separates itself from the named siblings by saying it is for tasks that 'are not one of the named tools', so an agent can route between dispatch and singularis_gemm/singularis_fft/etc. without opening schemas.

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

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

Gives a clear selection rule ('Use when a numerical task is not one of the named tools') and points to singularis_recipes for the valid names and schemas. That is actionable routing, though the exclusion is phrased against an unnamed list rather than naming a specific alternative tool, so it falls just short of fully explicit when/when-not guidance.

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

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

With no annotations, the description carries the full burden and does much of it: it discloses the return shape ([real, imag] pair with first axis), the Parseval energy check, that inputs/outputs may be inline or .npy paths, and the O(N log N) cost profile. It omits failure modes (invalid shapes), whether input arrays are mutated, and any overwrite semantics for file paths.

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?

Purpose leads, followed by inputs, outputs, the inverse round-trip, and complexity — each short sentence adds distinct operational information with no filler or repetition of the schema.

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

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

An output schema exists, so return values need not be re-explained, yet the description still supplies the essential pair shape and energy check. Combined with the clear input-format guidance, an agent has enough to call the tool; only edge-case behavior and x/path mutual exclusivity are missing.

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

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

Schema description coverage is 0%, so the description must compensate, and it largely does: x is 'inline or path', the inverse flag's meaning and the required round-trip input format ([real, imag] pair) are spelled out. It does not clarify resolver precedence when both x and path are supplied, which is the one real ambiguity.

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

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

States a specific verb and resource ('Fast Fourier transform (or inverse) of a real 1D signal or 2D field') and enumerates the target workloads (spectra, convolution, circulant systems, filtering). An agent can immediately distinguish this from siblings like singularis_solve_heat, singularis_gemm, or singularis_blur.

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

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

Provides clear usage context via the application list and gives an explicit recipe for the inverse case ('pass that same [real, imag] pair back as x with inverse=true'). However, it names no alternatives or when-not-to-use conditions, so routing between this and any overlapping sibling is left to inference.

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

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

With no annotations, the description carries the full burden and does well: it discloses that inputs may be inline or file paths, that output is inline or a .npy path, that a Freivalds-style probe residual check is performed, and that cost scales with 2*m*n*k. It omits any authorization, resource, or failure-mode caveats, keeping it below a 5.

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

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

Front-loads the operation, then usage, then inputs, then return behavior, then cost — a sensible order for an agent scanning for relevance. It is dense but each clause adds information; a slightly shorter phrasing of the input/output duality would be tightening, not a defect.

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?

An output schema exists, so return-shape details need not be restated, and the description wisely adds only the non-schema facts an agent needs: inline vs .npy delivery, the verification probe, and the cost model. For a batched dense multiply with seven arguments, nothing essential is missing.

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

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

Schema description coverage is 0%, so the description must compensate, and it largely does: it maps a, b, c0 to inline values and a_path, b_path, c0_path to file paths, and explains beta as the C0 scaling factor via the formula. It does not state that all arguments are optional/defaulted, but the semantic roles are clear.

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

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

States the exact operation as a formula (C = A @ B, optionally A @ B + beta * C0), which is unambiguous and machine-checkable. It is readily distinguishable from siblings like singularis_matrix_exponential, singularis_fft, and singularis_blur, each of which names a different linear-algebra kernel.

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

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

Gives clear usage context: 'Use for any large dense multiply, including batches expressed as one tall matrix,' which tells the agent the intended workload shape. It stops short of naming an alternative tool or an explicit when-not-to-use condition, so it earns a 4 rather than a 5.

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

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

With no annotations, the description carries the full burden and does reasonably well: it discloses that input may be inline or a file path, that a vector argument switches the operation to e^{tA}v, that output includes a residual check, and that cost scales as n^3. It omits any statement about matrix assumptions (square, real vs complex) or failure behavior for non-square input.

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?

Front-loaded with the core computation, then use cases, then the selection rule, then input/output facts — a sensible priority order. Dense but each sentence carries information; the domain list is slightly padded but justifiable for discoverability.

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?

An output schema exists, so return values need not be re-explained, and the description still usefully notes the residual check. Given moderate complexity and a 5-parameter schema at 0% coverage, the main gap is the unexplained vector_path parameter and the mutual exclusivity of inline vs path inputs; otherwise the agent has enough 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?

Schema description coverage is 0% for all five parameters, so the description must compensate. It partially does: it names matrix/path as alternative input forms, gives t's role and default, and marks vector as optional. It never mentions vector_path or explains that matrix and path are mutually exclusive mirrors, leaving one parameter completely undisclosed.

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

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

States a specific mathematical verb+resource (compute e^{tA} and its action on a vector) and enumerates concrete application domains: time evolution, Markov chains/rating migration, linear ODEs, graph diffusion. No sibling tool computes a matrix exponential, so the agent can place it instantly against solve_heat, gemm, fft, etc.

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

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

Gives an explicit selection rule: 'Use instead of a dense expm whenever n is in the hundreds or more, or when you need a verifiable residual.' That is clear when-to-use guidance tied to problem size and a verification need. It does not state when-not to use it or what the fallback is for small n, leaving that to inference.

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

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

With no annotations, the description carries the burden and does add real behavioral context: it discloses the cost model ('Free') and describes the shape of the listing (input schema, check, cost measurement). It stops short of stating read-only semantics or any rate limits, but for a zero-parameter listing call the risk surface is small.

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

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

Three tight sentences with the purpose front-loaded, followed by the usage condition, the next step, and a one-word cost note. The terminal 'Free.' fragment is terse but earns its place by answering a likely agent question about cost.

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?

An output schema exists, so return values need no explanation, and the zero-param schema means no argument caveats are required. Combined with explicit when-to-use guidance and the dispatch handoff, an agent has everything needed to call this correctly.

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

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

The tool takes zero parameters, so the baseline is 4; there is no parameter semantics for the description to add or omit. The description correctly spends no words on arguments.

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

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

States a specific verb (List) and resource (the Singularis recipe library), and spells out exactly what each entry contains: job kind, input schema, returned check, and cost measure. It is clearly distinguishable from the named computation siblings (singularis_solve_heat, singularis_gemm, etc.), which it implicitly covers as a superset.

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

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

Gives an explicit trigger condition ('when a task is numerical but not covered by the named tools') and names the exact follow-up tool (singularis_dispatch) with the sequencing ('then run it with'). An agent knows both when to reach for this and what to do next.

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

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

With no annotations, the description carries the full burden and does well: it discloses that one call saves and reuses the key (no repeat calls needed), the required inputs, the starting-credit return, and a caveat about unapproved countries. It does not mention auth/prerequisite state or any rate limiting on the registration itself, which is the only real gap.

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

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

Four tight sentences, front-loading the purpose before the usage trigger and parameter notes. Slightly denser than necessary in the final sentence about country availability, but every sentence carries 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?

Although an output schema exists (so return values aren't strictly required in the description), the description still notes the starting-credits return, plus the error trigger and country caveat. For a small 3-param bootstrap tool this is close to complete; only prerequisite/auth nuance is absent.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: country is tied to an ISO format ('such as US'), agent_name is characterized as 'short', and operator_contact is explicitly optional. That covers all three parameters with enough meaning to fill them correctly.

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

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

States a specific verb (register/get) and resource (Singularis API key) scoped to 'this agent', which is unambiguous and clearly distinct from the numerics/compute siblings. An agent can tell instantly this is a bootstrap/credential tool, not a computation 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?

Gives an explicit trigger condition: 'Use when any Singularis tool reports error=no_api_key.' It also flags the not-yet-available case (outside approved countries) so the agent knows the failure mode. Nothing is left to inference.

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

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

With no annotations at all, the description carries the full behavioral burden and mostly does not: it never says where the data goes, whether the submission is public, whether it can be retracted, or whether authentication is required. For a tool whose entire function is transmitting user data and a review, those omissions are material.

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?

Purpose is front-loaded in the first clause and the parameter glosses follow in one dense sentence. The parenthetical 'optional, and appreciated' is slightly soft and the closing hardware remark is a bit chummy, but nothing is redundant or padded.

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

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

The output schema exists, so return values need not be explained, and the parameter list is complete. What is missing is the surrounding contract for a submission tool with zero annotation support: required auth/registration state and what happens to the shared data.

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, and it does: it glosses all six parameters (review, post_url, prior_cloud_usd, singularis_usd, speedup, hardware) with enough meaning to fill them correctly. It stops short of formats or units (e.g. speedup as a multiplier vs. a duration, USD as a raw number).

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

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

States a specific verb and resource ('Share your Singularis results') and immediately enumerates the payload it accepts, which cleanly separates it from the compute siblings (solve_heat, gemm, fft, etc.). It does not name a sibling explicitly, but no reasonable agent would confuse it with the numeric solvers.

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 says the call is 'optional, and appreciated', implying it should be used after obtaining results, and notes 'GPU optional for even greater results'. There is no explicit when-not-to-use, no statement of prerequisites (e.g. whether a registered key is needed despite singularis_register_key existing), and no alternative named.

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

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

With no annotations, the description carries the full burden and does well: it discloses boundary-condition semantics ('dirichlet' fixed at initial boundary values), the default ('periodic'), what is returned (final field plus a conservation/residual check), and the cost model ('scales with steps * cells'). It omits stability/CFL constraints, which matter for a diffusion stepper, and any failure modes.

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?

Front-loaded with the equation, then usage, then inputs, then returns, then cost — a logical progression. It is dense but every clause carries information; the only mild redundancy is the return-value sentence, which overlaps the output schema.

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

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

For a 7-parameter numerical solver with an output schema, the description covers inputs, output, boundary variants, and computational cost, which is nearly everything an agent needs. The notable remaining gap is numerical stability guidance (relationship between dt, dx, and D) and expected failure behavior on stiff parameters.

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%, yet the description maps every one of the 7 parameters: initial (nested list inline or file path), diffusivity D, dt, steps, dx, and boundary. Critically it supplies the valid boundary values and defaults the schema leaves as a bare string, and explains what 'dirichlet' means operationally, fully compensating for the empty schema descriptions.

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

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

States a specific verb+resource ('Solve the heat (diffusion) equation u_t = D * laplacian(u) on a 1D or 2D grid'), names the mathematical model, and clarifies the operational scope (stepping an initial field forward in time). It also notes the same equation underlies Black-Scholes pricing and thermal spread, so an agent understands both the literal and applied purpose without opening the schema.

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

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

Gives a concrete use condition ('use instead of writing a stencil loop whenever steps * cells is large') and two application domains, which tells the agent when this beats hand-rolling numerics. It does not, however, contrast against numerical siblings such as singularis_blur or singularis_fft, which could plausibly serve overlapping diffusion-like workloads.

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