Mithrandir

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

With annotations already marking the tool read-only and idempotent, the description adds valuable behavioral detail: it uses only approved metadata, returns decision statuses, and explicitly does not prove savings or authorize purchases. This goes well beyond the annotations and clarifies the tool's operational boundaries.

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 three focused sentences with no filler. The core purpose is front-loaded, then the return statuses, then the critical limitations and alternative. Every sentence earns its place.

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

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

Given a complex 10-parameter schema with zero parameter descriptions and no output schema, the description provides a solid high-level frame but not enough to fully guide invocation or interpretation. It explains what the tool returns at a high level, but not how optional inputs influence the result or what the actual response shape is.

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 does not explain any of the 10 parameters or how they map to the stated outcomes. Terms like changed_parts_ppm, needs_shared_state, and local_alternative_available are left undefined, so the description fails to compensate for the schema's lack of 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?

The description names a specific action ('capability preflight') and clearly distinguishes it from content-reading or purchasing tools by stating 'no source content' and 'NEVER proves savings or authorizes a purchase.' It also lists the exact outcomes the tool can produce, making its role unambiguous among the mithrandir siblings.

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 an explicit alternative ('Use the local utility evaluator for complete-task cost evidence') and states what the tool cannot do, giving clear exclusion criteria. However, it does not explicitly define the positive condition for when to choose this tool over sibling tools, leaving 'preflight' to imply the use case.

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?

Despite no annotations providing safety hints (readOnlyHint=false, destructiveHint=false, etc.), the description discloses key behaviors: it costs credits, it has a byte budget for output, and it returns specific elements (quotes, provenance, coverage, continuation). It also notes that no-match is not proof of absence, which is a crucial behavioral caveat. This goes beyond the annotations and provides essential 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 concise (two sentences) and front-loaded with the core function ('Find and rank original text windows across an explicit list of sources') and key distinguishing features (BM25, no semantic search). It packs important behavioral notes (byte budget, no-match caveat, credit cost) without verbosity. Every sentence earns its place.

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

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

For a tool with 7 parameters, no output schema, and no parameter descriptions in the schema, the description is quite complete. It explains the output content (exact quotes, provenance, coverage, continuation) and the byte budget, which is central to the tool's operation. It also explains cost implications. However, it doesn't describe the behavior of specific parameters like 'match_mode' or 'scope_hash', which might be needed for advanced usage. Given the complexity, it's slightly 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?

Schema description coverage is 0%, meaning the description is the only source of parameter semantics. However, the description explains the overall output budget ('whole-response byte budget') but does not detail individual parameters like limit, start, or match_mode. Yet it does clarify that 'artifact_ids' and 'query' are used, and the schema includes detailed constraints. The description's mention of 'explicit list of sources' and 'byte budget' gives context that the schema lacks, but it doesn't fully explain all 7 parameters.

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: 'Find and rank original text windows across an explicit list of sources' with a specific retrieval method (BM25, no semantic search). It distinguishes from semantic search and clearly identifies the resource (sources) and the action (find and rank). This is a specific verb+resource pairing that differentiates it from siblings like mithrandir_search or mithrandir_query.

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 explicitly states that it searches only an explicit list of sources (artifact_ids) and does not search other accounts or the web, which is clarified again in the schema. It also warns that 'No-match is not proof of absence', guiding the agent on interpretation of results. This provides clear context on when to use this tool (when an explicit source list is available) and when not to (when a broader search is needed).

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

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

Annotations declare destructiveHint=true, and the description elaborates: 'Execute spends operator-authorized credits; resume is free.' It also clarifies reuse ('Reuses unchanged partitions') and constraints ('No arbitrary code or semantic inference'). This adds meaningful behavioral context beyond the annotations, such as the credit cost and the requirement for expected_version on writes. No contradiction with annotations.

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

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

The description is a single, dense paragraph that front-loads the primary actions and then adds key constraints. It is concise and avoids fluff. The structure flows logically from actions to behavioral notes. It could be slightly more organized (e.g., bullet points), but it is efficient and 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?

Given the tool's complexity (7 parameters, nested objects, multiple actions, no output schema), the description is incomplete. It does not explain what the response looks like for each action, nor does it cover error handling or edge cases. It mentions match returns 'a compact existing result' but omits details for quote, execute, and resume. The description also fails to clarify the distinction between 'plan' and 'match_plan' or the role of 'max_credits' and 'idempotency_key'. This is a significant gap for an agent to call the tool 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%, so the description must compensate for undocumented parameters. It mentions 'expected_version' and 'source guards' but does not explain the meaning of 'contract', 'sources', 'snapshot_complete', 'reuse_policy', or other fields. The description's mention of 'exact source scope' hints at the sources parameter but lacks specificity. It fails to add semantic value for most parameters, leaving the agent to infer from the schema alone.

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: 'Quote, execute, resume or match a deterministic table capsule.' It enumerates four distinct actions and specifies that match 'validates an exact source scope and returns a compact existing result without debit.' This distinguishes it from sibling tools like mithrandir_query and mithrandir_read, which likely handle general queries. The phrase 'No arbitrary code or semantic inference' further differentiates it as a deterministic 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 description provides some usage context: match returns existing results without debit, execute spends credits, resume is free, and writes require 'explicit complete scope, source guards and expected_version.' However, it does not explicitly state when to prefer this tool over siblings like mithrandir_query or mithrandir_read, nor does it mention exclusions. The guidance is mostly internal to the four actions, not a comparison with alternatives.

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

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

Annotations already mark destructiveHint=true, but the description adds valuable context: 'Saving checks exact quotes and expected_version; it does not verify meaning or truth' and 'source deletion invalidates the capsule.' These disclose validation limits and lifecycle dependencies beyond the annotation flags, enhancing 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 four short sentences, front-loaded with the primary purpose. Every sentence adds distinct information (purpose, content separation, validation behavior, constraints). 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?

Given the complex nested schema (state with 10+ fields, evidence references) and no output schema, the description is too sparse. It does not explain how to construct a valid capsule, what save vs. resume entails, or what happens on success/failure. Critical operational details are missing, making it inadequate for correct invocation.

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 by explaining parameters. It only references 'expected_version' and 'quotes' indirectly, without clarifying the action enum, name pattern, or the structure of the state object. Most parameters (goal, findings, hypotheses, etc.) are undocumented in the description, leaving agents to infer from the schema alone.

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

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

The description states a clear, specific action: 'Save or resume a structured task capsule.' It also clarifies the internal distinction between evidence-backed findings and hypotheses/open questions, which defines the tool's core purpose. This is not a tautology and distinguishes it from generic state 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 for saving/resuming task capsules but does not explicitly state when to use this tool versus siblings like mithrandir_state or mithrandir_context_pack. It mentions constraints (same-account keys, source deletion) but no exclusions or alternative routing. Guidance is only implied.

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

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

Annotations already provide readOnly/idempotent/non-destructive hints. The description adds behavioral value beyond those by disclosing that the body is not loaded and that no processing debit is incurred, which are meaningful operational traits an agent would not otherwise know.

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

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

Two short sentences deliver the essential information with no redundancy: what the tool does, what it avoids, and the cost implication. The key differentiator ('without loading its body') appears early.

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 low-complexity tool with rich annotations, this is nearly complete: purpose, safety, and cost behavior are all clear. The only minor gap is that the return value is not described, though no output schema exists to compensate for that.

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 by clarifying that the artifact_id parameter refers to a stored artifact, tying the only parameter to the tool's purpose. The schema contributes the format pattern, and together they are sufficient for the single 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 ('Inspect') and a clear resource ('a stored artifact'), and immediately distinguishes this tool from siblings like mithrandir_read by stating it operates 'without loading its body.' This makes its role unambiguous among the many mithrandir_* 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 phrase 'without loading its body' and 'No processing debit' clearly imply this is the tool to use when only artifact metadata or status is needed and the full content/costly processing is not. It does not explicitly name alternatives or exclusions, so it stops 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.

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

The description discloses that Mithrandir never signs or holds private keys and that settlement atomically activates the account and returns an API key once within a bounded retry window. These details go beyond the annotations and help an agent understand side effects, though failure/error behavior is not 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?

Three short sentences are front-loaded with the main purpose and contain no padding. Security and settlement behavior are placed efficiently after the primary operation.

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 covers the main outcome and security posture, but with no output schema it omits the challenge response format, failure modes, and the exact condition that selects 'get challenge' versus 'submit signature.' It is adequate but leaves notable gaps for a payment mutation 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 0%, so the description needed to explain the parameters. It only indirectly identifies payment_signature as a wallet-produced signature and gives no meaning to onboarding_id or onboarding_secret, leaving the agent without enough information to construct a correct call.

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

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

The description names a specific resource (x402 payment challenge for an onboarding session) and the two operations: getting a challenge or submitting a payment signature. It is clear about the tool's function, though it does not explicitly contrast it with sibling onboarding tools such as status or reconcile.

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 states the two use modes directly: obtain a payment challenge or submit a wallet-produced signature. This gives clear context for when to call the tool, but it does not spell out when to prefer a sibling or what prerequisites must hold.

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

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

Annotations only mark the operation as destructive/not read-only. The description adds meaningful behavioral context: it mentions using a Base transaction hash, verifying canonical payment proof, and conditionally activating the account. It does not detail failure behavior or side effects when proof is not confirmed, so it is not a full 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?

A single dense sentence that front-loads the core action and includes the essential condition ('if canonical payment proof is confirmed'). There is no filler or redundant restating 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?

With no output schema, no parameter descriptions, and only sparse annotations, the description should explain expected return values, failure modes, and parameter semantics. It explains the high-level flow but omits what the agent will receive back and what happens when proof is not confirmed, leaving meaningful gaps for a mutating operation.

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 for parameter meanings. It only clarifies the transaction hash ('using a Base transaction hash'); onboarding_id and onboarding_secret are not explained beyond their names and patterns. The secret's role and why all three parameters are required are left underspecified.

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

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

The description names a specific verb ('Reconcile') and resource ('submitted but uncertain x402 settlement'), and states the follow-up action ('activate the account'). It clearly distinguishes this from sibling tools like mithrandir_onboarding_start, onboarding_pay, and onboarding_status by describing a distinct reconcile-then-activate flow.

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 'submitted but uncertain' gives a clear trigger condition for when this tool is appropriate. It does not explicitly mention when not to use it or name alternatives like onboarding_status, but the context is clear enough for an agent to recognize the intended use case.

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?

The description adds useful behavioral context beyond annotations: provisional account, bounded, short-lived secret, no credits/API key before settlement. However, annotations already signal destructive and idempotent behavior, and the description does not clarify what, if anything, gets destroyed or reset, or how idempotency manifests.

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

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

Two sentences with no filler; the key action and precondition are front-loaded, and the operational constraints are compactly stated.

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?

It covers the main outcome and prerequisites, but for a 6-parameter start tool with no output schema it leaves parameter semantics and lifecycle behavior (idempotency, what to do with the secret/endpoint) underdescribed. Sibling names help, but the description itself does not fully equip an agent.

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?

With 0% schema description coverage, the description must compensate but only hints at policy acceptance and boundedness. It does not clarify max_amount_atomic, pack_id, label, idempotency_key, or policy_version, leaving most parameters underspecified.

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 an explicit verb+resource ('Start autonomous prepaid onboarding') and clarifies it applies only without an existing Mithrandir account. It names distinct outputs (onboarding secret, x402 endpoint) and a policy prerequisite, which differentiates it from siblings like onboarding_pay, onboarding_reconcile, and onboarding_status.

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 states the key precondition (no existing account), which is a clear when-to-use signal, and implies that status/pay/reconcile tools have different roles. It does not explicitly name alternatives or give a when-not-to-use list, so it falls short of full 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?

Annotations already convey readOnly, idempotent, and non-destructive behaviorhic. The description adds useful context by noting the session is short-lived and that the secret is required for access. However, it does not disclose what happens if the session has expired or if credentials are invalid.

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 exceptionally concise: two sentences, no filler. The first sentence states the core purpose; the second adds the essential prerequisite. 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 read-only, idempotent status-check tool with only two parameters and robust annotations, the description is largely complete. It explains the session type and the required secret, and the low complexity means little additional context is necessary. A brief mention of the expected response could make it fully complete, but the current description 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 description coverage is 0%, so the description must compensate. It indirectly explains that onboarding_id refers to the session and onboarding_secret is the credential returned at creation, which adds real meaning. However, it does not explicitly describe each parameter or their roles in detail.

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

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

The description states a clear verb ('Inspect') and a specific resource ('short-lived autonomous onboarding session'), which makes the tool's purpose immediately understandable. It is distinguishable from obvious siblings like onboarding_start, onboarding_pay, and onboarding_reconcile, though it does not explicitly differentiate itself from generic mithrandir_inspect or mithrandir_state.

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: use this when you need to inspect an onboarding session and have the secret from creation. It provides a useful prerequisite ('secret returned at creation') but does not explicitly state when to use this tool versus alternatives or when not to use it.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds meaningful semantic guardrails: it does not authorize or execute a purchase and makes no model-cost savings claim. This goes beyond the structured annotations without contradicting them.

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, information-dense sentence with no filler. It states what the tool is, what it exposes, and what it does not do, all in an efficient format.

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

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

For a zero-parameter read-only catalog, the description provides enough context about contents and non-purchase behavior. It does not define the exact return shape, but since there is no output schema, this is a minor gap; 'prepaid packs and billing principles' indicates the subject matter well.

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 no parameters, so there is no parameter burden on the description. It clearly describes the catalog content, which is sufficient for a zero-argument tool.

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 names a specific resource ('commercial catalog for the managed Mithrandir service') and a specific action ('Shows prepaid packs and billing principles'). It also disambiguates from sibling tools by explicitly stating it does not authorize or execute a purchase.

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

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

The description gives a clear use case—retrieving pricing/pack/billing information—and an explicit exclusion: it is not for purchasing. However, it does not name sibling alternatives such as mithrandir_quote or mithrandir_onboarding_pay, so an agent must infer which other tool handles purchase execution.

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?

The annotations are all false and provide no behavioral signal, so the description carries the full burden. It discloses meaningful traits beyond the schema: no SQL/code execution, bounded results entering context, the need to check complete/next_start, and exact decimal aggregation. This is substantive and directly useful for an agent.

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 with no filler; the primary capability is front-loaded, and each sentence adds a distinct piece of information: function, boundedness, and pagination. This is appropriately sized for the tool's complexity.

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 nested plan, no output schema, and multiple sibling tools, the description covers the core operation modes, bounded-result behavior, and pagination signal. It omits response shape, error cases, and how output_budget_bytes interacts with limit/start, so it is adequate 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?

Schema description coverage is 0%, but the description's verbs map reasonably onto plan fields: 'filter/project' to filters/select/group_by, 'exact decimal aggregation' to aggregate, and 'bounded result' to limit/output_budget_bytes. It still leaves artifact_id and several nested plan fields to be inferred from the schema, making this only minimally viable.

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 specific verbs and resources: 'filter/project JSON records or CSV' and 'perform exact decimal aggregation.' This clearly conveys what the tool does and distinguishes it as a query/transform operation. It does not explicitly contrast itself with sibling tools like mithrandir_read or mithrandir_search, which keeps it from 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 phrase 'Only a bounded result enters context' tells the agent this tool is appropriate when a controlled, limited result set is desired rather than a full dataset. 'Check complete/next_start' gives actionable post-request guidance. However, it does not explicitly state when to prefer this over alternatives or when not to use it.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description reinforces this by stating it does not spend credits or authorize purchases, which adds little beyond the annotations. The only new behavioral detail is the artifact_ids requirement for context-pack quotes, which is a parameter constraint rather than a behavioral trait. No contradiction with annotations.

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

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

The description is two sentences, front-loaded with the core purpose and safety guarantee. It is efficient and free of fluff. Minor loss for not structuring the artifact_ids note more clearly, but overall it is concise.

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 quote tool with no output schema, the description should explain what the tool returns (e.g., price in credits) and how the operation parameter affects the quote. It does neither. The artifact_ids requirement is a start, but the description is incomplete for an agent to invoke the tool correctly across all operation types.

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 for parameter meaning. It only mentions that context-pack quotes require artifact_ids, leaving input_bytes, ttl_seconds, artifact_id, and the operation enum unexplained. This is insufficient for an agent to correctly construct a quote request, especially with 5 parameters and a required enum.

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: to inspect the service-credit price before execution. It also clarifies it does not spend credits or authorize purchases, which distinguishes it from payment/execution tools. However, it does not explicitly name sibling alternatives, so it lacks the explicit differentiation seen in top-tier definitions.

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 'before execution' and notes that context-pack quotes require artifact_ids, which is a concrete prerequisite. It does not explicitly state when not to use the tool or name alternative tools (e.g., mithrandir_pricing). The guidance is present but not comprehensive.

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

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

Annotations are all false, so the description carries the burden. It does disclose two behavioral traits: bounds prevent silent oversized results, and source hashes are integrity checks, not proof of truth. However, it omits any side-effect warnings, auth requirements, or response format details, which are critical given no annotation support.

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 brief and efficient, with the primary action front-loaded. Both sentences serve a purpose, but the second sentence on hashes is somewhat tangential and could be placed later. Overall it is concise without 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 tool with 5 parameters, no output schema, and no annotation hints, the description is inadequate. It fails to explain how start/length and pointer interact, what happens if both are provided, the meaning of output_budget_bytes, or what the return value looks like. An agent would need to inspect schema constraints alone and still lack crucial usage context.

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 explain parameters. It implies start/length map to character slice and pointer maps to JSON Pointer, but it never explicitly maps them, and it does not explain output_budget_bytes or artifact_id semantics. The description adds minimal value beyond the schema constraints.

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 ('Read') and the two resource types (character slice, JSON Pointer), making it distinguishable from generic tools. However, it does not explicitly name any sibling to differentiate from, such as mithrandir_search or mithrandir_inspect, so it relies on the agent to infer differences.

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 exclusions. The agent is left to guess whether this is the right choice for a given request.

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 helpful annotations (all false), the description carries the full burden. It discloses several behaviors: case-sensitivity, output bounding by bytes, pagination via next_start, and a security note that stored text is untrusted. It does not explicitly state it is read-only, but the search semantics imply non-destructive behavior. These details add valuable context beyond the annotations.

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

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

The description is three concise sentences, each adding distinct value: the core behavior, the output bounding, and pagination plus a security warning. It is front-loaded with the primary purpose and contains no filler. Excellent structure 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?

For a tool with 6 parameters, no output schema, and no annotations, the description is incomplete. It does not explain the meaning of limit, start, context_chars, or how to construct a valid query. It also lacks details on the return format beyond 'spans with source hashes' and error handling. An agent would struggle to call this correctly without additional information.

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 indirectly explains output_budget_bytes ('bounded by output bytes') and pagination ('next_start'), but does not explain artifact_id, query, limit, start, or context_chars. The description adds some semantics but leaves most parameters unexplained, which is insufficient given zero 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 it is a literal case-sensitive search that returns exact spans with source hashes. It specifies the resource (stored text) and the operation (search). It does not explicitly differentiate from sibling tools like mithrandir_query, but the 'literal case-sensitive' qualifier implies a distinct behavior. Overall, the purpose is clear and specific.

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 such as mithrandir_query or mithrandir_read. It only mentions using next_start for additional matches, which is internal pagination advice, not a usage guideline. There is no explicit context for selecting this tool over others, leaving the agent to infer.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds valuable context by clarifying that it is a security contract description, not a claim of deployment security, which sets accurate expectations for the agent.

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 core purpose (machine-readable description of the trust model) and then a clarifying caveat. There is no unnecessary verbosity; every sentence earns its place.

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

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

For a no-parameter, read-only tool without an output schema, the description is sufficient: it states what the tool provides and warns against over-interpretation. It could specify the exact output format, but 'machine-readable' gives a reasonable hint, and the low complexity keeps this from being a major gap.

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

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

The tool has zero parameters, so the description need not explain parameter behavior. According to the rubric, a 0-parameter tool gets a baseline of 4, and the description does not introduce any confusing parameter-related language.

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 provides a machine-readable description of the v17 Cognitive Membrane trust model, listing its key components (origin-bound authority, task-scoped exact-call capabilities, replay protection, egress control, two-phase effectful actions). This is specific and distinguishes it from siblings that likely perform operations or assessments rather than describe a security model.

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 it (to understand the trust model) and explicitly states what it is not (proof of vulnerability-free deployment), which suggests it is not for security auditing. However, it does not name alternative tools like mithrandir_assess or mithrandir_inspect, leaving some ambiguity about exactly which sibling to use for vulnerability checks.

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

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

Annotations already indicate destructiveHint=true, and the description adds meaningful context: 'State is agent-authored, not verified facts' and the need for expected_version to prevent lost updates. These go beyond the annotation and inform the agent about data quality and concurrency 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?

The description is two sentences with no fluff, front-loaded with the main purpose. Every sentence adds value, and the structure is clean and efficient.

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 5 parameters, a nested object, no output schema, and no sibling differentiation, the description is incomplete. It lacks parameter details, return behavior, and usage context, leaving the agent to infer critical information.

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 explains expected_version's purpose; it does not explain name, state, artifact_ids, or action semantics. For a 5-parameter tool with a nested object, this is insufficient.

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 action and resource: 'Save or resume task checkpoints.' It distinguishes the tool's core function from generic operations and is not a tautology. However, it does not explicitly differentiate from sibling tools, though the checkpoint domain is specific enough.

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. It mentions a requirement for saving (expected_version) but that is a parameter constraint, not a usage guideline. There are no references to sibling tools or conditions for selecting this tool over others.

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

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

Annotations are neutral (all false), so the description carries the burden of disclosing behavior. It adds a size limit and a caution about large outputs, which is useful, but it does not disclose other behaviors like persistence, overwrite semantics, or return values. It adds some value beyond annotations, but leaves gaps.

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

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

Two sentences with no fluff: the first states the purpose and limit, the second provides a critical warning. Information is front-loaded and 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 3-parameter tool with no output schema, the description should at least clarify the role of each parameter and whether anything is returned. It covers the content and size, but leaves kind and label unexplained and says nothing about the result of the store operation. Given the neutral annotations, more context is needed for confident invocation.

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 for parameter explanations. It mentions 'content' and the 16 KiB size limit, but does not explain the 'kind' (text/json/csv) or 'label' parameters. The enums and defaults are in the schema, but the agent gets no guidance on how to choose them, leaving important semantics unclear.

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

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

The description states a specific verb ('Store') and resource ('small note, text or JSON string') with an explicit size limit, making the core function clear. It does not explicitly contrast with sibling tools, but the name and the mention of 'small' help distinguish it from other mithrandir operations.

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 by warning not to paste large tool outputs here and directing them to the host SDK, but it does not explicitly name an alternative mithrandir tool or state when to prefer this over siblings. Guidance is present but only implied.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds value by clarifying there is no financial side effect (no purchase authorization) and no sensitive wallet exposure, which is meaningful given payment-related siblings, but it does not add further context such as data freshness or behavior when credits are exhausted.

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

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

Two sentences, each pulling weight: the first states the core function, the second draws a safety boundary relevant to the sibling set. Nothing is redundant or extraneous.

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 parameterless, strongly annotated, read-only inspection tool, the description is nearly complete: it names the exact scope (credits and storage) and excludes the relevant side effects. The only gap is that no output schema exists and the description does not hint at the return shape, leaving the agent unsure whether the response delivers the balance figure it needs.

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?

With zero parameters, there is nothing the description needs to document; the empty schema and 100% coverage fully define the invocation surface. The description correctly implies the tool takes no arguments by not referencing any. Baseline 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?

The description uses a specific verb and resource ('Inspect remaining prepaid credits and current storage'), clearly stating what the tool does. The negation 'Does not authorize a purchase or expose a wallet' helps separate it from purchase/pricing-related siblings like mithrandir_onboarding_pay and mithrandir_quote, though it does not distinguish it from other inspection tools such as mithrandir_inspect or mithrandir_state.

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 'Does not authorize a purchase' clause implicitly tells an agent this tool is for checking status before financial actions, not for performing them. However, it never names an alternative tool to use for purchases nor gives any condition for choosing this tool over the inspect/state/search siblings, so routing 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.