remit

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

With no annotations, the description must carry the full behavioral burden. It usefully discloses the four analysis dimensions it reports on, implying a non-destructive read comparison, but it never states read-only status, whether inputs must be valid/compilable programs, what happens on parse errors, or the shape of the result.

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

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

Two tight sentences, front-loaded with the verb and the analytical question it answers. The rhetorical question format efficiently conveys the diff dimensions without padding, and the usage cue trails as a short second sentence.

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 no output schema and no annotations, the enumerated check categories effectively preview the return content, which is a strength. But the undocumented host parameter and the absence of input format expectations leave the definition short of what an agent needs to invoke it 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?

Schema description coverage is 0% across three required parameters, so the description must compensate. It implicitly maps old_program/new_program to the two compared versions, but the required "host" parameter is never explained, nor is the expected format of a program string, leaving a real 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 and resource ("Compare two versions of a program") and enumerates exactly what the comparison surfaces: resource gains, higher worst-case calls/cost, new tagged data flows, new approval sites. That is far more specific than the name alone, though it does not explicitly differentiate itself from siblings like remit_check or remit_run_fixtures.

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

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

"Use this after editing a program" gives a clear timing cue for invocation, which is genuinely useful context. However there is no guidance on when NOT to use it, no mention of alternatives (e.g., remit_check for validation), and no prerequisites stated.

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

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

With no annotations, the description carries the full burden, and it does disclose meaningful behavior: errors come back with locations and hints, and success yields the authority manifest with resources, worst-case calls/cost, approval sites and flows. It never explicitly states that the operation is non-mutating or what auth/prerequisites apply, but the 'type-check' verb makes the read-only nature inferable.

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

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

Two dense sentences, front-loaded with the action and then the return contract. No filler, 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?

There is no output schema and no annotations, so the description must explain return values — which it does in detail for both the failure and success paths. The remaining gap is the unstated safety profile (side effects, prerequisites) for a tool whose params are otherwise fully enumerated.

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 does name all three parameters and adds real meaning for policy ('optional policy TOML', matching the nullable default in the schema), but it leaves the format of program and host ambiguous — path vs inline source is not clarified — so 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: 'Type-check a program against a host interface (and optional policy TOML).' That is far more precise than a restated name, and the checker role is easy to distinguish from siblings like remit_run_fixtures or remit_authority_diff, but no sibling is named or contrasted, so it stops short of a 5.

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

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

The description implies when the tool applies (static checking of a program against a host, with policy as an optional overlay), but gives no explicit when-to-use/when-not guidance and never points at alternatives such as remit_run_fixtures for executing rather than checking.

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

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

With no annotations, the description carries the full burden. It discloses the two modes and the returned artifacts, which is genuinely useful, but says nothing about where examples come from, whether listing is filtered/paginated, or permission needs.

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 compact sentence with the primary action front-loaded. The parenthetical file list is dense but earns its place by naming the return payload.

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

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

No output schema and no annotations, so the description is the only source of truth. It covers modes and artifacts but leaves ambiguous what the list form returns (names, paths, and structure), which an agent needs to chain this 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 coverage is 0%, so the description must compensate. It does convey that 'name' selects a single example and that examples are identified by name, but does not clarify name format or whether it matches directory names.

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 specific verbs (list / return one) and the resource (example apps), plus the concrete artifacts returned (program, host.rmti, policy.toml). It is distinguishable from siblings like remit_check or remit_format, though it never names them.

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 'or return one ... by name' phrasing implies the selection condition: omit name to list, supply name to fetch one. That is usable context, but there is no explicit when-to-use guidance or statement of what this tool is not for.

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 one useful trait (comments are preserved), but says nothing about whether the input is mutated or whether a new string is returned, how invalid programs are handled, or any error 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?

A single front-loaded sentence with the key behavioral caveat (comments preserved) attached directly to the action. Nothing is wasted.

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 transformation tool with no annotations and no output schema, the description is minimally adequate but leaves gaps: what canonicalization entails, whether the return is the formatted program, and how errors surface. The agent can call it, but not confidently predict 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?

Schema description coverage is 0% and the single 'program' parameter is documented nowhere. The description mentions 'the program' but adds no meaning about its expected syntax, source, or whether it is a file path, raw source text, or identifier.

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

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

The description names a clear verb (return) and resource (the program in canonical format), and the parenthetical clarifies an important output trait. It distinguishes itself reasonably from siblings like remit_check or remit_authority_diff, though it never defines what 'canonical format' concretely means.

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

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

There is no guidance on when to reach for remit_format versus remit_check, remit_run_fixtures, or the other siblings, and no preconditions or exclusions are stated. The agent must infer usage purely from the tool name.

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

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

No annotations are provided, so the description carries the full burden. It discloses the two retrieval modes (default guide vs section='spec') but says nothing about read-only safety, output size, or whether other section values exist.

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 front-loads the default behavior before the alternate mode. Zero waste.

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 read-only documentation retrieval tool with an output schema present (so return values need not be described), the definition is nearly sufficient. The only gap is the lack of sibling differentiation.

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 bare 'section' string param relies entirely on the description, which usefully explains the default ('guide') and the alternate value ('spec'). It substantially compensates, though it leaves open whether other section values are valid.

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 (Return) and resource (quick guide / full language specification), so the agent can tell it retrieves documentation for the remit language. It is clear but does not explicitly differentiate itself from siblings like remit_examples or remit_format.

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 implies usage by disclosing the default behavior and the switch to get the full spec, but it never states when to prefer this over remit_examples or remit_format, nor any when-not conditions. Usage 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 offline execution, auto-granted approvals, that no real capability is invoked, and the return shape (result plus list of calls). It omits failure/error behavior and fixture format expectations.

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

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

Four sentences, front-loaded with the core action, then layering the offline/auto-approval caveats. Every sentence adds information; only mild redundancy in restating offline guarantees twice.

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, so the description's mention of the return values is valuable, and the safety profile is covered. But with no annotations and all five parameters undocumented, an agent still lacks 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?

Five parameters at 0% schema coverage, and the description explains none of them individually. 'program', 'host', 'fixtures', 'inputs' and 'policy' get no format, required-vs-optional, or example guidance, so an agent must guess at their content.

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 (run a checked program on JSON fixtures) and adds scope-defining detail ('OFFLINE', 'canned capability and model outputs'). It is clear what the tool does, though it never names or contrasts with siblings like remit_check that may overlap.

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 offline/auto-approved framing implies a testing use case, but there is no explicit when-to-use, when-not, or alternative ('use remit_check for X'). Usage is left to inference against five sibling tools.

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