AtlasClose Governance Demo

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

Annotations only declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, leaving the actual effect of 'authenticate' ambiguous. The description fills that gap by stating the call is non-privileging (no capability grants, no matter admission) and that requested capabilities are silently ignored, plus the credential prerequisite from the discover-produced locator.

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 short sentences, zero filler, and the operational status marker plus the core 'identify' action are front-loaded. Every clause carries a distinct fact: precondition, outputs, non-effects, credential source.

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

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

With no output schema, the description carries the return-value burden and does so (actor_id, actor_token), while also covering the credential prerequisite and the negative behavioral guarantees. Nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning for enrollment_token by specifying its provenance (the locator named by atlas.discover) and reinforces that capabilities is inert. Name and model_id are left entirely 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 verb and resource ('Identify yourself to Atlas') and declares exact outputs ('Returns actor_id and actor_token'). It also fends off misreadings by stating what the call is not ('Grants no capabilities and does not admit you to a matter'), which separates it from siblings like atlas.request_capability and atlas.claim_purpose.

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

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

The '[OPEN: no admission needed]' marker gives a clear precondition for use, and it points to atlas.discover as the source of the enrollment secret. It stops short of naming the alternative path explicitly in the description text (atlas.enroll appears only in the schema for enrollment_token), so it is clear context without full when/when-not routing.

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

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

Annotations only supply readOnlyHint=false, so the description carries most of the behavioral load and does so well: it discloses that the signature "does not grant authority," that Atlas will not name or assign a principal, and that certain fields are withheld before admission. These are non-obvious state and trust semantics an agent could not infer from the schema. It doesn't characterize failure modes or what the binding actually persists, so it's not 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?

The bracketed prerequisite tag is front-loaded, and the remaining sentences are dense but purposeful — each covers a distinct rule (required inputs, source of the declaration, omitted fields, principal semantics, next call). There is some redundancy with the schema on the principal clause, but no wasted framing.

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 10-parameter, annotation-thin mutation tool with no output schema, the description covers entry conditions, required parameters, field-omission rules, trust caveats, and the required successor call. The main gap is what a successful bind returns (beyond the implied matter_id) and what refusal looks like. It is complete enough to invoke correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: authority_acknowledgment must be the declaration_text from atlas.discover (a cross-tool provenance link the schema doesn't give), and it explains the pre-admission omission rule for matter_id/objective_id/objective_text as a group. The principal explanation largely duplicates the schema wording, which caps it below 5.

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 concrete action — "Admit yourself by signing the declaration" — and names the two required inputs, so the agent knows this is the admission/binding step rather than a generic write. It is distinguishable from credential-only siblings like atlas.authenticate because it is framed as a declared admission gated on a declaration text. The verb "bind actor" itself is somewhat internal jargon, so it isn't quite a textbook 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 gives explicit sequencing: "enroll, then atlas.bind_actor" as a prerequisite and "After it succeeds, call atlas.institutional_view" as the follow-up, which is strong when-to-use guidance. It also states a clear when-not rule for matter_id/objective_id/objective_text ("Omit ... none is disclosed before admission"). It does not compare itself against near-neighbors such as atlas.authenticate or atlas.present_identity, which keeps it 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?

With only readOnlyHint=false in annotations, the description does the real work: it discloses that the session and credential are destroyed while the matter, declarations, and room stamps persist, and that a room departure is recorded first. That is exactly the durable-vs-ephemeral context an agent needs; it omits auth/rate-limit detail but those are minor here.

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 short sentences, front-loaded with the admission requirement and the core effect, with no wasted filler. The bracketed jargon ('NEEDS ADMISSION', 'matter remains... room stamps') is terse but each clause carries new information.

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

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

For a 2-parameter session-ending tool with no output schema and minimal annotations, the description covers prerequisites, side effects, and what survives the call. Only a note on what the caller receives or how to re-enter later 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 coverage is 100% with both parameters fully documented (including the 'optional when bound to exactly one matter' nuance), so the schema carries this dimension. The description adds no parameter-level information beyond what is already structured.

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 effect: 'Exit Atlas. Ends this session and retires this credential.' That distinguishes it from the generic room tools, though the boundary versus atlas.leave_room is only implied ('if you are inside a room, Atlas records the departure before the session ends').

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 bracketed '[NEEDS ADMISSION: enroll, then atlas.bind_actor]' gives an explicit prerequisite sequence for using the tool. It stops short of naming when NOT to check out or pointing at a genuine alternative among siblings.

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 declare readOnlyHint=false, openWorldHint=false, destructiveHint=false, leaving the semantics of the write unexplained. The description supplies the non-obvious behavioral fact that this call 'grants nothing and does not admit you' and is not a binding or authority, which prevents an agent from mistaking a recorded claim for an actual grant. It does not describe what is returned or what happens on failure.

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 action and the admission prerequisite are front-loaded, which is good, but the description then spends two sentences on a repetitive negation chain ('not enrollment, not a declaration, not a binding, not a matter association, not principal verification, and not authority') plus a restated prohibition. Consolidating the negatives would sharpen it without losing information.

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

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

For a mutation tool with no output schema, the description covers prerequisites and non-effects but says nothing about the result of a successful claim, error conditions, or whether the claim can be revised. An agent knows how to gate the call but not what it gets back, leaving a real 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?

Schema description coverage is 100%, so the baseline is 3, but the description adds a genuine constraint absent from the schema: 'Do not send a matter id or an objective id.' It also reinforces that both principal and purpose are free-form ('in your own words'), though that wording largely duplicates the schema. The extra negative guidance nudges it above baseline.

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

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

States a specific action on specific inputs ('State the principal you claim and the purpose you claim, in your own words') and fences it off from adjacent operations (enroll, bind_actor, declaration, matter association, verification, authority). The affirmative purpose is clear, though it is delivered mostly through a negative enumeration, so it is slightly weaker than a crisp verb+resource statement.

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 bracketed precondition '[NEEDS ADMISSION: enroll, then atlas.bind_actor]' gives an explicit prerequisite sequence, which is exactly the routing information an agent needs. The negation list further implies the conditions under which other tools apply, but no alternative is named as the tool to use *instead* for a different intent, so it stops short of a full when/when-not/alternative statement.

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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds genuinely new behavioral context: nothing about a matter, objective, evidence, filing, authority, or room is disclosed before admission, and authentication/enrollment do not themselves admit you. That gating behavior is not derivable from the annotations or schema.

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 open-access constraint is correctly front-loaded in brackets, and the description is short. However, the closing two sentences are redundant ('Authentication and enrollment grant nothing. Enrollment does not verify a principal and does not admit you') and the text is more atmospheric than 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?

For a zero-required-parameter entry-point tool with no output schema, an agent needs to know what discovery yields — capabilities, context, or a pre-admission view? The description explains the gate but not the payload, leaving the core value of the call undefined.

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

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

Schema description coverage is 100%, so both parameters are already documented. The description only adds the consequence of omitting actor_token ('you are outside'), which the schema already frames as an optional credential. Baseline 3 is appropriate when the schema carries the parameter semantics.

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

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

The description establishes that atlas.discover is the 'front door' usable without admission, which does differentiate it from admission-gated siblings like atlas.enter_room. However, it never states what the tool actually returns or does once called — no verb+resource for the output. An agent knows it is allowed to call it, but not what it gets back.

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?

'[OPEN: no admission needed]' and 'With no actor_token you are outside' imply this is the tool to call before enrolling or authenticating. That is useful implicit routing, but there is no explicit 'call this first, then use X' statement and no comparison against siblings like atlas.enroll or atlas.authenticate.

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?

Goes well beyond annotations by disclosing the return values (actor_id, actor_token), the requirement to pass actor_token in later calls, the caveat that the session is not a credential, and the explicit scope limits (no capabilities, no Matter access, no principal verification). Annotations only mark it non-read-only; the description supplies the real behavioral profile.

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 key admission gating ('[OPEN: no admission needed]') and packs routing, return values, and scope caveats into a few dense sentences with no filler.

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

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

Despite having no output schema, the description names what is returned and how to use it, and clarifies what the call does not grant. Combined with annotations, an agent has everything needed to invoke it correctly.

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

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

Schema description coverage is 100%, so all three parameters are already documented in the schema, including the UNVERIFIED nature of 'principal'. The description adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Enroll a remote actor at this Front Door') and immediately distinguishes itself from the sibling atlas.authenticate by naming the differing method (no installation enrollment secret). An agent can select it 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?

Explicitly frames when to use it ('[OPEN: no admission needed]', without the installation secret) and names the alternative path (atlas.authenticate) for the secret-based method. The routing decision between the two enrollment routes is fully spelled out.

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 key behavioral traits: it's a non-destructive read/add-evidence operation (consistent with readOnlyHint: false indicating mutation via evidence addition), requires an actor_token, returns a name in 'you_are_in', and handles a CHALLENGE_REQUIRED case with proof-of-work details. This adds significant context beyond annotations, though it doesn't specify what happens if the practice area is unavailable or error details.

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 compact and front-loads the main purpose, with subsequent sentences efficiently covering scope, return value, token requirement, and challenge handling. No sentence is clearly redundant, though the aside about 'Consumer Pulse copy' might be slightly 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?

Given no output schema, the description explains the return value ('you_are_in') and the challenge flow. For a tool with a required token and optional challenge parameters, it provides enough context to invoke correctly. Missing details on error handling or what 'add evidence' entails limit completeness slightly.

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 33%: only actor_token is described in the schema; challenge_nonce and challenge_solution have no schema descriptions. The tool description explains the challenge mechanism and when to provide these parameters, adding some meaning. However, without clear type/format details for the challenge parameters, the description only partially compensates.

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: it puts the user into a private synthetic copy of the server's practice matter, with 'you_are_in' returned. It distinguishes itself from other tools by describing the synthetic copy and the limited read/add-evidence scope. However, it does not name a sibling alternative like enter_room, leaving some ambiguity.

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 mentions a condition: 'only if the operator turned it on,' and describes the action's effect, but does not explicitly state when to use this versus other room-entry tools (e.g., atlas.enter_room) or what prerequisites are needed beyond the actor_token. Usage is implied but not fully guided.

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 only readOnlyHint=false in annotations, the description carries the behavioral burden and does so well: it discloses that Atlas rechecks the lock server-side, that a LOCKED room writes no stamp and grants no authority, and that an OPEN room appends a stamp and scopes you to that single room. It does not describe the response shape or any rate/idempotency 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?

Three tight sentences plus a bracketed gate, front-loaded with the admission prerequisite and then the two outcome branches. Every sentence carries operational meaning with no filler.

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

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

For a mutation tool with no output schema, it covers the key success/failure branches and the admission precondition. Domain terms ('stamp', 'declaration', 'authority') are used without definition, which slightly limits completeness, but 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 100%, so all three parameters (room_id, matter_id, actor_token) are already documented, including the optional-when-single-matter rule. The description adds no parameter-level syntax or format detail beyond implying the admission prerequisite, so the baseline 3 is appropriate.

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

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

The description gives a specific verb and resource: 'Cross one room threshold,' making clear this is the room-entry operation. It distinguishes the entry case ('places you inside that room only'), but never names the contrasting siblings such as atlas.leave_room or atlas.request_room_access, so sibling differentiation is left implicit.

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 a concrete prerequisite chain ('[NEEDS ADMISSION: enroll, then atlas.bind_actor]') and the conditions under which the call succeeds vs fails (OPEN vs LOCKED room). It stops short of routing the agent to alternatives when admission is missing (e.g., request_room_access) or when the room is locked.

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 openWorldHint=true, and the description usefully adds that a request is not a grant, that consequential capabilities are refused without prior Human grant and even then held for a Human decision, and that the result carries the primary actor block. This is real authorization behavior beyond the safety flags, though error/refusal response details are left implicit.

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 prerequisite is front-loaded in a bracketed tag, and each sentence contributes (admission, non-granting transport, capability naming, refusal semantics). The prose is dense and parenthetical-heavy, which slows parsing, but there is little wasted text.

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

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

For a four-parameter mutation tool with no output schema, the description covers admission prerequisites, capability discovery, payload semantics, and the consequential-act gating. It is nearly sufficient, with only the shape of returned/refused results left under-described beyond the 'primary actor block' remark.

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

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

Schema coverage is 100%, so the per-field descriptions already carry baseline meaning. The description nonetheless adds value by tying 'capability' to concrete act names and their payload shapes (e.g. evidence.append with payload {content}) and by noting payload belongs to the named capability, which the schema states only abstractly.

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+resource ('Request an external act') and clarifies the core mechanism: the act is named by a 'capability' string such as evidence.append or release:outside. It distinguishes itself from the transport/authorization layer ('Transport does not grant it'), but does not explicitly separate itself from generic siblings like atlas.use or atlas.room_act.

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 prerequisite chain clearly ('NEEDS ADMISSION: enroll, then atlas.bind_actor') and routes the agent to atlas.list_capabilities to discover which act names it holds. It also flags that release:outside is refused unless granted by the Human. It stops short of saying when to choose this over sibling action tools, so not a full 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?

Annotations only declare readOnlyHint=false, so the description must carry behavioral weight. It notes the tool 'does not seal a ruling and does not choose a disposition,' clarifying scope, and states admission prerequisites. However, it doesn't describe what filing does to the proceeding, whether it's reversible, 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 admission requirement, then states the action, then exclusions. Slightly jargon-heavy ('O-VESTED', 'constituted magistrate') but every sentence contributes.

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 mutation tool with no output schema and only one annotation, the description covers prerequisites and some exclusions but leaves gaps: what happens on success, what the proceeding state looks like after filing, and how it differs from related submission tools.

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

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

Schema coverage is 100%, so the schema documents all four parameters. The description adds no parameter-level detail beyond the schema, which is the baseline expectation when coverage is complete.

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 clear verb ('file') and resource ('argument or counterargument on an open O-VESTED proceeding'), which is specific. It distinguishes from siblings loosely by naming 'magistrate_execute' is not this, but doesn't cleanly contrast with submit_evidence or raise_challenge.

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 gating condition '[NEEDS ADMISSION: enroll, then atlas.bind_actor]' and an exclusion ('The constituted magistrate does not file. One actor does not file both.'), but these are phrased as cryptic rules rather than explicit when-to-use guidance against alternatives like raise_challenge.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the meaningful auth prerequisite (must be admitted via enroll + bind_actor), which is useful context beyond annotations, but it says nothing about the response or rate/scope 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?

It is a single short line, which is efficient, but the front-loaded bracket note is followed by an ambiguous sentence whose second half ("followed by the primary actor result") does not clearly earn its place or convey meaning.

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

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

There is no output schema, so the description carries the burden of explaining what is returned, and it does not. Combined with a vague purpose statement, the definition is too thin for an agent to call this correctly beyond the schema's parameter docs.

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

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

Schema coverage is 100%, so both actor_token and matter_id are fully documented in the schema, including the "optional when bound to exactly one matter" nuance. The description's mention of "bound matter" only loosely echoes matter_id and adds no syntax or format detail. Baseline 3 is appropriate.

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

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

"Minimum assignment for a bound matter" largely restates the name/title (get_assignment) and never defines what an "assignment" actually is. The trailing clause "followed by the primary actor result" is cryptic and does not clarify the verb or resource. An agent cannot confidently distinguish this from siblings like atlas.get_context or atlas.get_matter.

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 bracketed note "[NEEDS ADMISSION: enroll, then atlas.bind_actor]" names the prerequisite workflow and the sibling tools to run first, which is genuine routing guidance. However, it gives no when-to-use vs when-not-to-use against alternatives, nor what distinguishes this from other read tools.

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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds a meaningful behavioral fact the annotations do not carry: this call requires prior admission via atlas.enroll then atlas.bind_actor. It omits what the returned authority looks like, but the auth prerequisite is the valuable disclosure.

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 fragments, with the gating prerequisite front-loaded before the purpose clause – nothing is padded. The bracketed tag is slightly cryptic scheme shorthand, which keeps it from a 5.

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

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

For a 2-parameter read-only tool with full schema coverage the definition is workable, and the admission prerequisite is covered. With no output schema, however, the agent gets no hint of what 'authority' is returned as (scopes? capabilities? a token?), which leaves a real 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?

Schema description coverage is 100%, and the schema already explains both actor_token and the matter_id conditional ('optional when bound to exactly one matter'). The description adds no syntax or format detail beyond that, so the baseline 3 applies.

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

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

The description states a specific verb+resource: retrieving the authority actually granted to the calling actor, which is clearer than a tautological restatement of 'get authority'. It does not, however, distinguish itself from nearby siblings like atlas.list_capabilities or atlas.get_assignment, 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 bracketed prerequisite (enroll, then atlas.bind_actor) tells the agent exactly what must happen before this call, which is real usage guidance. It stops at 4 because no alternative tool is named for the case where the agent wants a different view of permissions.

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 cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds real context beyond them: the admission prerequisite and the fact that the response is scoped to a minimum working set rather than a full event log, which sets expectations about payload size and content.

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 fragments with the gating prerequisite front-loaded in brackets. Nothing is wasted, though the telegraphic style ('Minimum working context, followed by the primary actor result') costs some clarity relative to its brevity.

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 read tool with no output schema, the description covers the prerequisite, the safety profile (via annotations), and roughly what is returned. The exact shape of 'primary actor result' remains undefined, but that is a minor gap at this complexity.

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

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

Schema coverage is 100%, so both parameters are already documented in the schema. The description adds nothing about actor_token or matter_id beyond implicitly pointing at the enrollment flow, so the baseline 3 applies.

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

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

The description names the resource ('working context') and hints at the return ('followed by the primary actor result'), but 'minimum working context' is jargon that doesn't tell an agent concretely what data comes back. The exclusion 'Not the event log' does differentiate it from a sibling, which lifts it above pure vagueness.

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 an explicit precondition sequence (enroll, then atlas.bind_actor), which is genuinely useful routing information. However, it doesn't say when to call this instead of related reads such as atlas.get_matter, atlas.institutional_view, or atlas.discover – only the admission gate is covered.

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?

Beyond the readOnly/idempotent/non-destructive annotations, it discloses the admission and matter.read capability gate, the conditional inclusion of evidence_records, the full set of returned fields, and an epistemic caveat that a claim is not a judgment or established fact. That is substantial behavior disclosure the structured fields do not provide.

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 prerequisite and core purpose are front-loaded in the first clause, and each trailing sentence carries meaning about response contents or epistemic status. Slightly dense but nothing is redundant 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?

With no output schema, the description shoulders the return-value burden and does so for the admitted case by listing evidence_records fields. It does not describe the base response when the actor lacks matter.read, leaving a minor 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?

Schema description coverage is 100%, so both parameters are already documented, including matter_id's optionality when bound to a single matter. The description adds no parameter-level syntax or format detail beyond the schema, so the 3 baseline 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 concrete verb+resource ('Get matter', 'Matter state from the docket') and enumerates what the response contains. It does not explicitly distinguish itself from siblings like atlas.get_assignment, atlas.get_authority, or atlas.get_resulting_state, so an agent must infer the boundary.

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 bracketed '[NEEDS ADMISSION: enroll, then atlas.bind_actor]' gives an explicit prerequisite chain, and the 'hold matter.read' condition clarifies access. It stops short of naming when to prefer this over sibling state-read tools such as get_resulting_state, so no exclusion 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 declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds a genuine behavioral fact beyond them: the tool requires admission via atlas.enroll followed by atlas.bind_actor, an auth prerequisite not visible in the annotations or schema. It stops short of describing what the returned records contain.

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 compact fragments with the prerequisite correctly front-loaded, so nothing is wasted. The trade-off is under-specification rather than excess: the body sentence is a noun phrase that conveys very little, which is terseness, not efficiency.

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 rich annotations and 100% schema coverage, the remaining burden is describing the return value, and there is no output schema. "Verification records for a matter" is too vague to tell an agent what it will receive (receipts? signatures? status?), so the definition is adequate but leaves a real gap for a query tool.

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

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

Schema description coverage is 100%, so both matter_id and actor_token are fully documented in the schema, including the "optional when bound to exactly one matter" nuance. The description contributes no additional parameter meaning, which is the expected baseline when the schema does the heavy lifting.

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

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

The description names a resource ("verification records for a matter") but the phrasing is a bare noun fragment with no verb, and "resulting state" in the name/title is never explained. An agent cannot confidently distinguish this from siblings like atlas.get_matter, atlas.get_context, or atlas.get_authority 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?

The bracketed prerequisite "[NEEDS ADMISSION: enroll, then atlas.bind_actor]" gives real, actionable routing to two sibling tools, which is more than most definitions offer. However, it never states when to call this tool versus other state/introspection tools such as atlas.get_context or atlas.get_matter, so selection 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable context beyond annotations: the admission prerequisite chain (enroll, then bind_actor) required before this call will be meaningful.

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?

Extremely short and front-loaded: prerequisite first, then the purpose. The bracketed notation is slightly cryptic, but every clause earns its place with no filler.

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

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

For a simple read-only, non-destructive status check with 0 required parameters and 100% schema coverage, the description supplies the essential prerequisites and the core return meaning ('whether a Human decision is pending'). There is no output schema, but the one-line purpose effectively conveys what the agent gets back.

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

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

Schema coverage is 100%, so matter_id and actor_token are already fully documented in the input schema, including the 'optional when bound to exactly one matter' nuance. The description adds no parameter meaning beyond the schema, which is the correct baseline of 3 when the schema does the heavy lifting.

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

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

The description states what the tool determines (whether a Human decision is pending), which is a specific resource/state check. The verb is implicit rather than explicit, and no sibling is named for differentiation, but an agent can tell this is a status query about pending human decisions.

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

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

Usage is implied by the name and purpose, and the tool routes the agent to its prerequisite siblings (atlas.enroll, then atlas.bind_actor). However, it gives no explicit when-to-use vs alternatives guidance and no exclusion conditions, so it is minimum-viable rather than strong.

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, so the safety profile is covered. The description adds genuine context the annotations cannot: the required admission sequence (enroll then bind_actor) and the explicit mutation boundary ('You do not unlock doors'). It does not cover failure behavior if admission is missing, so it stops short of 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?

Four short sentences with the admission prerequisite front-loaded as a bracketed callout, which is the right thing to put first. The 'enter / request access / return / exit' clause is a little padded but does describe view content rather than repeating the 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, the description carries the burden of describing what comes back, and it does so reasonably: rooms on the matter, OPEN vs LOCKED states, the reasons behind locks, and the available entry/exit paths. Prerequisites are stated. The reliance on 'hall'/'door' metaphor is the only real gap for an agent trying to map results to domain entities.

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

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

Schema description coverage is 100% and both parameters (actor_token, matter_id) are fully documented in the schema, so the baseline is 3. The description adds nothing about parameter format, token lifecycle, or the single-matter default that isn't already in the schema.

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

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

The sentence 'Lists every room on this matter, which doors are OPEN, which are LOCKED, and why' gives a concrete verb (lists) and resource (rooms plus their access states), which distinguishes it from action siblings like atlas.enter_room and atlas.request_room_access. The framing 'The hall, after admission' is atmospheric rather than informative, but the operational purpose is recoverable.

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 prerequisite chain is explicit ('NEEDS ADMISSION: enroll, then atlas.bind_actor'), and 'You choose among OPEN doors. You do not unlock doors' implies this is diagnostic rather than an access-granting action. However, no sibling is named as the follow-up for actually entering or requesting access, so the agent must infer from atlas.enter_room / atlas.request_room_access.

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 annotation only supplies readOnlyHint=false; the description carries the real behavioral load by disclosing the side effect (a leaving stamp is appended to the declaration) and two important non-effects (session is not ended, no authority is granted). This scoping is exactly what an agent needs before invoking a state-mutating call.

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 zero waste, and the most decision-relevant item (the admission prerequisite) is front-loaded in brackets. Nothing repeats the schema or the annotations.

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-output-schema, mutation-flagged tool, the description covers what the call does, what it does not do, and the precondition. The only gap is that it never names where the agent lands/continues next (enter_room, checkout), but that is a minor omission.

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

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

Schema description coverage is 100%: both actor_token and matter_id already document their origin (atlas.enroll/atlas.authenticate, atlas.bind_actor) and the optionality condition. The description's admission prerequisite is consistent with that but adds no new parameter-level information, so the baseline 3 applies.

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

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

States a concrete verb and resource (return from the current room to the hall) and names the side effect (appending a leaving stamp). It is distinguishable from its closest siblings: enter_room is the inverse, and the explicit 'does not end the session' separates it from checkout.

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?

Leads with the precondition '[NEEDS ADMISSION: enroll, then atlas.bind_actor]', which tells the agent exactly what must happen first. The closing 'does not end the session and does not grant authority' implicitly routes the agent to checkout for termination, but no alternative tool is named outright, so it falls just 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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds behavioral context annotations cannot express: the admission sequence required before use (enroll then atlas.bind_actor) and the confinement to Atlas's own record types. It does not describe result shape or limits, but with no output schema that is a modest 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?

The admission prerequisite is usefully front-loaded, but the middle clause "FIND is not READ PRIVATE CONTENT is not MODIFY is not DECIDE is not EXECUTE" is a run-on negation list that is hard to parse and spends significant space restating scope already covered by the following sentence. Tighter phrasing would let the real constraints land faster.

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, read-only lookup with annotations and full schema coverage, the description covers the essentials: admission prerequisite, scope boundary, and the sibling to use for out-of-scope content. What an agent still lacks is any hint of what a returned 'record' contains or how results are ranked/paged, though the absence of an output schema limits how much the description should be expected to carry.

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

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

Schema description coverage is 100%, so both parameters are already documented in-schema ('What you want to find or ask, in plain words' and the credential token). The description adds no syntax, format, or constraint detail beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ('Locate an Atlas-MCP record') and narrows scope to "Atlas's own records only (its source, rules, rooms, filings and their versions)." It explicitly carves itself away from business-document search and points to atlas.get_matter, so an agent can distinguish it from at least one sibling without opening schemas. It does not distinguish itself from the very close librarian.* siblings (resolve, related, provenance, version_history).

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 prerequisite chain ("[NEEDS ADMISSION: enroll, then atlas.bind_actor]") and a clear when-not boundary ("does not search business documents such as invoices or purchase orders") with the alternative named (atlas.get_matter). It lacks guidance on when to choose this over librarian.resolve/related/provenance, which is the most likely confusion given the sibling set.

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 value beyond that: the admission prerequisite and the scope disclaimer 'Not a ruling on its truth or legal effect' tell the agent the output is informational and non-authoritative, which is not captured in the schema or 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 short, but front-loading is weak: the purpose is buried after a bracketed prerequisite, and the 'FIND is not READ PRIVATE CONTENT is not MODIFY is not DECIDE is not EXECUTE' chain is cryptic and reads more like a slogan than actionable information. Nothing is wasted in length, but clarity suffers.

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

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

There is no output schema, so the description should explain what provenance data is returned (format, fields, pagination), and it does not. Annotations cover safety and the prerequisite is stated, but an agent still cannot predict the response shape.

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

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

Schema description coverage is 100% (actor_token and artifact_id are both fully documented), so the schema carries the parameter burden. The description adds no syntax, format, or cross-parameter detail beyond the schema, making the baseline 3 correct.

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 identifies a specific resource (provenance for an Atlas-MCP artifact) and distinguishes it from reading/modifying/deciding via the chained negative clause. However, the head phrase 'Provenance recorded for an artifact' is a noun phrase that never states the verb, so it is ambiguous whether the tool retrieves or writes provenance, and it does not differentiate from siblings like librarian.version_history or librarian.related.

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 bracketed '[NEEDS ADMISSION: enroll, then atlas.bind_actor]' supplies a concrete prerequisite sequence, which is genuinely useful routing information. There is no guidance on when to prefer this over librarian.find, .related, .resolve, or .version_history, which are the obvious 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 declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety and idempotency are covered by structured data. The description adds two genuinely useful bits beyond that: the admission/auth requirement and the constraint that it only records pre-existing relations and "does not invent links." It stops short of describing what is recorded or returned.

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 admission prerequisite is usefully front-loaded, but the chain "FIND is not READ PRIVATE CONTENT is not MODIFY is not DECIDE is not EXECUTE" is cryptic filler that consumes space without conveying a clear instruction. The core action sentence is buried after the bracket and competes with the noise.

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, read-only, idempotent tool with full schema coverage and no output schema, the description covers the prerequisite and the key behavioral constraint. It is close to adequate, though it never explains what "recording" a relation actually produces or how it differs from librarian.provenance/version_history.

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

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

Schema description coverage is 100%, so both parameters are already fully documented in the schema, and the description adds no syntax or format detail beyond them. Baseline 3 is appropriate when the schema carries the parameter burden.

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?

"Records the docket already relates to an identifier" states an action plus resource, and "Does not invent links" narrows the scope versus inventing relationships. However the phrasing is convoluted and the trailing slogan ("FIND is not READ PRIVATE CONTENT is not MODIFY...") muddies rather than clarifies what the tool actually does. An agent can infer it records an existing relation but must work for it.

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 bracket prefix states a concrete prerequisite (enroll, then atlas.bind_actor), which is real usage guidance, and "Does not invent links" implies when this is appropriate. There is no explicit when-not or named alternative among siblings like librarian.resolve or librarian.find, so the guidance is implied rather than spelled out.

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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds genuinely new context: the admission/enrollment prerequisite and the deliberate non-disambiguation behavior ('ambiguous matches stay ambiguous'), which an agent could not infer from annotations alone.

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 prerequisite is usefully front-loaded, but the 'FIND is not READ PRIVATE CONTENT is not MODIFY is not DECIDE is not EXECUTE' chain is opaque jargon that consumes space without clearly helping an agent decide anything. The purpose sentence earns its place; the taxonomy is questionable.

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 read-only lookup with full schema coverage, prerequisites, idempotency, and ambiguity behavior are all present. Only the shape of the resolved record is unstated, which is minor given there is no output schema to lean on.

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

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

Schema description coverage is 100%, so both parameters (identifier, actor_token) are already fully documented in the schema. The description adds no syntax, format, or edge-case detail about the identifier beyond what the schema says, so the baseline 3 applies.

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

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

The first sentence gives a specific verb (Resolve) and resource (an institutional identifier to the Atlas-MCP record that carries it), which clearly separates it from atlas.librarian.find and the other librarian siblings. The trailing 'FIND is not READ...' taxonomy is cryptic, but the core purpose is stated unambiguously.

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 bracketed prefix states an explicit prerequisite chain ('NEEDS ADMISSION: enroll, then atlas.bind_actor'), and 'Ambiguous matches stay ambiguous' sets expectations versus a disambiguating search. There is no explicit when-not rule beyond the jargon taxonomy, so it falls short of a 5.

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

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

With annotations covering readOnly, idempotent, and non-destructive behavior, the description still adds useful context: the admission prerequisite and the specific behavior that it does not mark one current unless the docket says it superseded another. The final negative chain is confusing but consistent with 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 short but poorly structured: a prerequisite is front-loaded ahead of purpose, and the final chain 'FIND is not READ PRIVATE CONTENT is not MODIFY...' is cryptic and largely repeats annotation coverage. Several words do not earn their place.

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

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

There is no output schema, so the description should explain what version history returns or how versions are represented. It instead leaves the core behavior opaque and omits return format, ordering, or pagination details.

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

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

Schema description coverage is 100%, so both parameters are already documented. The description mentions 'carry an identifier' and admission, but adds no syntax, format, or meaning beyond what the schema provides, so baseline 3 applies.

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

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

The description never states a clear verb and resource for what the tool returns. 'Incorporated records that carry an identifier' is vague and does not explain that this retrieves version history, nor does it differentiate from siblings like atlas.librarian.find or atlas.librarian.provenance.

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 a prerequisite ('[NEEDS ADMISSION: enroll, then atlas.bind_actor]') but no guidance on when to choose this tool over alternatives. The line about FIND/READ/MODIFY/DECIDE/EXECUTE is cryptic and does not provide usable selection criteria.

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 covered. The description adds the admission prerequisite (enroll → atlas.bind_actor), which annotations do not carry and which is genuinely behavioral. It still says nothing about output shape, scoping to a matter, or what happens with an unadmitted token.

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?

It is short, but it is a sentence fragment with a bracketed prerequisite prepended and no verb, so it reads as a note rather than a front-loaded statement of what the tool does. Every clause is dense with jargon, which reduces rather than improves parseability.

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, two-parameter list tool with full schema coverage and no output schema, the essential prerequisite is disclosed. What is missing is the return shape and scoping (does matter_id narrow the list?), which the description would need to supply since no output schema exists.

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

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

Schema description coverage is 100% and both parameters (actor_token, matter_id) are fully documented in the schema, including the optional-when-single-matter rule. The description contributes no additional parameter meaning, so the baseline 3 applies.

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

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

The description is a noun phrase rather than a verb+resource statement, and 'Granted capabilities and acts this actor cannot perform' is syntactically ambiguous — it is unclear whether the tool returns one list or two, or what an 'act this actor cannot perform' means. It does identify the resource domain (capabilities for the current actor), so it is more than a restatement of the name, but not specific enough to distinguish it cleanly from siblings like atlas.request_capability or atlas.get_authority.

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?

'[NEEDS ADMISSION: enroll, then atlas.bind_actor]' gives a concrete prerequisite chain the agent must satisfy first, which is useful usage context. However, it says nothing about when to prefer this over atlas.get_authority or atlas.get_assignment, and no exclusion conditions are 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 only readOnlyHint=false available, the description carries real weight: it discloses the required auth path (enroll → bind_actor, token from enroll/authenticate), sequencing rules, and two explicit constraints ('Workers cannot seal', 'Do not send a ruling'). It does not describe the return artifact or idempotency, but it meaningfully exceeds the single annotation.

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?

Roughly three short sentences that each carry content: prerequisite, action, and constraints. The bracketed admission requirement is front-loaded, and there is no filler, though the compressed jargon trades clarity for brevity.

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 multi-actor, mutating workflow step with no output schema, the description covers prerequisites, preconditions, and prohibitions reasonably well but never says what a successful call produces (the 'return'), how it relates to atlas.magistrate_referral, or whether retrying is safe. An agent can sequence the call but not fully predict the outcome.

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

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

Schema description coverage is 100%, and the field-level descriptions already explain that actor_token comes from atlas.enroll/authenticate and matter_id is optional when bound to exactly one matter. The description adds no parameter syntax or format detail beyond that, so the baseline of 3 applies.

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

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

The description names the resource (the magistrate) and a specific action pair — 'constitute the warm magistrate or receive its authenticated return' — and explicitly distinguishes itself from sending a ruling (contrast with atlas.magistrate_referral). However, the domain jargon ('warm magistrate', 'authenticated return', 'seal') leaves an agent without a plain-language statement of what the tool actually accomplishes.

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 a hard prerequisite chain ('[NEEDS ADMISSION: enroll, then atlas.bind_actor]') and a state precondition ('Argument and counterargument must already be filed by other actors before the return is received'), plus a prohibition ('Do not send a ruling'). What it does not do is say when to prefer this over the sibling atlas.magistrate_referral, so the usage routing is implied rather than explicit.

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

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

Annotations only declare readOnlyHint=false. The description adds real behavioral context beyond that: the caller does not supply a disposition, does not become the Magistrate, and does not receive the Magistrate credential, plus the admission requirement. These negative guarantees help the agent predict the side effects, though what the tool actually returns or mutates is still unstated.

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 admission prerequisite in brackets, then delivers the action and its boundaries in a compact two-sentence block. The triple negative ('does not supply... does not become... does not receive') is slightly repetitive but each clause carries distinct boundary 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?

Covers the auth prerequisite and behavioral boundaries for a 4-parameter write operation, and there is no output schema to explain. Still missing is what a successful referral yields (a credential, a reference id, a state change) and what error conditions look like, which an agent needs to chain this call 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 100%, so all four parameters (question, matter_id, actor_token, related_matter_id) are already documented in the schema. The description adds no parameter-level detail, so the baseline 3 for a fully-covered schema 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 concrete verb+resource: 'Present a question to the Clerk,' and clarifies the effect ('The Clerk constitutes a Magistrate'). The action is identifiable, but the domain jargon (Clerk, Magistrate) is only circularly defined and the sibling atlas.magistrate_execute is never contrasted, so the agent cannot fully distinguish the two from the text alone.

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 bracketed '[NEEDS ADMISSION: enroll, then atlas.bind_actor]' gives an explicit prerequisite, which is genuine when-to-use guidance. However, no alternatives are named (e.g., when to use referral vs atlas.magistrate_execute), and no conditions for exclusion are given, so routing remains 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?

The description asserts "Read only," while the annotation declares readOnlyHint=false, a direct conflict in the safety signal an agent relies on. The remaining context (practice mode, separate refusal log, credential requirement) is useful, but the contradiction undermines the behavioral claim.

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, front-loaded sentences with no filler: mode, action, scope, prerequisite. Every clause 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?

For a single-parameter, no-output-schema read tool, the description covers origin of the data (separate refusal log), the caller's own scope, and the auth prerequisite. Return shape and pagination are absent but no output schema exists to define them, leaving a minor 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?

Schema description coverage is 100% and the single actor_token parameter is fully documented in-schema (including where to obtain it), so the schema carries the semantics. The description only restates that the token is required, adding no format or scope detail beyond it.

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 ("list your own refused calls") and pins the scope to the caller's own actor plus the dedicated refusal log, which separates it from the institutional/audit siblings. It does not explicitly name a sibling alternative, but the scope qualifiers make the target unambiguous.

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

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

"Practice mode" and "Requires your actor_token" give implied context and a prerequisite, but there is no explicit when-to-use/when-not or pointer to an alternative way to inspect refusals. Usage is inferable rather than 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 readOnlyHint=false the annotations only signal that this writes something; the description supplies the substance: it records the claim, records what this connection showed, records that nothing is verified, and grants no authority. That is a genuinely informative write-side contract that goes well beyond the annotation flags, and it is consistent with destructiveHint=false.

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 compact sentences plus a front-loaded bracketed routing tag; every clause carries weight and the key scoping caveat is stated twice for emphasis. Slightly repetitive in the token/admission/authority wording, but no dead weight.

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

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

There is no output schema and the tool is conceptually simple, so the description's behavioral contract plus the fully documented schema covers what an agent needs to call it. It omits edge details such as whether repeat calls overwrite prior claims, which keeps it from a 5.

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

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

Schema description coverage is 100%, so all five parameters (including the meaning of 'principal' as UNVERIFIED) are already documented in the schema. The description adds no per-parameter syntax or constraints beyond that, which is the expected baseline when the schema does the heavy lifting.

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

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

The description gives a specific verb and resource ('State who you claim to be' / record an identity claim) and explicitly negates the authority-granting behavior of siblings like atlas.authenticate, atlas.enroll, and atlas.use ('no token, no admission, no authority'). It does not name a sibling directly, so it falls just short of a 5, but the contrast is unambiguous.

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

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

The '[OPEN: no admission needed]' tag establishes the condition under which this tool is the right choice: when the caller has not been admitted. The repeated 'grants no token, no admission, and no authority' clause implicitly routes agents seeking real authority to authenticate/enroll. No explicit when-not statement is given, so 4 rather than 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 asserts 'Read only', but the annotations declare readOnlyHint=false, directly contradicting the stated safety profile. Although it usefully discloses the practice-mode/copy-only scoping, the explicit read-only claim against a non-read-only annotation is a serious inconsistency.

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?

It is a single sentence with the scoping constraints front-loaded, so an agent learns the domain and step before the payload detail. Slightly dense and jargon-heavy, but no sentence 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?

There is no output schema, and the description does describe the returned payload (two conflicting records, the Magistrate question, the copy's standing), which is helpful. But with a contradictory readOnlyHint and no clarity on whether the call changes state, it leaves a material gap for an agent deciding whether the call is safe.

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

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

Schema description coverage is 100% and both parameters (matter_id, actor_token) are documented in the schema itself. The description adds no parameter-level syntax, format, or default information beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description names a specific resource and scope: 'Practice mode, Consumer Pulse copy only (Magistrate demo, step 1)' and enumerates the returned content (the two disagreeing records, the fixed Magistrate question, the copy's standing). It is clearly distinct from siblings like atlas.pulse_data or atlas.pulse_memo, though it uses a noun phrase rather than an explicit verb.

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?

'Magistrate demo, step 1' situates the call in a sequence and 'Practice mode, Consumer Pulse copy only' constrains where it applies, which is implied usage guidance. However, it names no alternative tool and gives no explicit when-not-to-use condition, so an agent must infer the routing.

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

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

The description states 'Read only,' but the annotation declares readOnlyHint=false, which directly contradicts the claimed read-only behavior. Although the description does add useful data-reliability context (J-0001 labels KNOWN / INFERRED / CONFLICTED), the explicit contradiction of the annotation makes this a serious transparency failure.

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 front-loads the scoping constraint and the returned data types with zero filler. The dense colon-separated clauses and internal jargon ('Panel B', 'J-0001') slightly reduce readability.

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 only two well-documented parameters and no output schema, the description does cover the return contents (survey, forecast, Panel B numbers plus labels). However, it omits format/volume expectations and its read-only claim conflicts with the annotations, leaving the behavioral picture 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 100%, and both actor_token and matter_id are fully documented in the schema (matter_id even cross-references atlas.enter_demo). The description adds no parameter-level detail, so the baseline of 3 applies.

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

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

The description identifies the specific resource (the SYNTHETIC survey, forecast and Panel B numbers) and scopes it to 'Practice mode, Consumer Pulse copy only,' which distinguishes it from pulse_inbox, pulse_memo, and pulse_verify_receipt. It lacks an explicit verb (retrieve/read/fetch), so the action is only implied by the tool name.

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

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

The scope condition 'Practice mode, Consumer Pulse copy only' gives a when-to-use signal, but no alternatives are named and there is no statement of when-not-to-use or prerequisites beyond the actor_token requirement. Usage is implied rather than fully guided.

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?

readOnlyHint=false lowers the bar, and the description adds real behavioral context: the access gate ('without the right code you see nothing') and the failure mode for wrong codes with a named error token (HANDOFF_GUESS_LOCKED, rate-limited). It stops short of describing whether the call changes any state despite readOnlyHint=false, or details of the rate limit.

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?

It is front-loaded with the scoping constraint before the mechanics, and every clause carries information (scope, gating, code format, failure behavior). The long parenthetical and dense domain jargon ('Consumer Pulse copy', 'purpose limit') make it heavier than needed, but nothing is padding.

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

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

With no output schema, the description still signals what comes back (memos with labels and a purpose limit) and covers the access gate and error behavior for a 4-parameter gated tool. It leaves 'purpose limit' and any pagination or ordering undefined, but nothing essential to invoking the tool correctly is missing.

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

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

Schema coverage is 75%; matter_id, session_id, and actor_token are documented in the schema, while handoff_code has no schema description. The description compensates for that gap by explaining the code's origin and format ('the short code like PULSE-ABCD-EFGH-IJKL shown to the visitor when the first AI's memo was accepted'), which adds meaning beyond the bare string type.

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 conveys that this surfaces memos handed to the caller under a handoff_code, along with their labels and purpose limit, and scopes it to 'Practice mode, Consumer Pulse copy only'. It never uses an explicit verb like 'list' or 'retrieve', so the action is inferred from 'inbox' plus the memo collection it describes, and it does not name which sibling (pulse_memo, pulse_data, pulse_use) it differs from.

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 scope and preconditions ('Practice mode, Consumer Pulse copy only', requires a handoff_code, 'Without the right code you see nothing'), which implicitly tells the agent when this applies. However, it gives no explicit when-to-use versus pulse_memo, pulse_use, or pulse_data, and no statement of what to do instead when you lack the code.

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 declare readOnlyHint=false, so the description carries the burden and does it well: it discloses the success outcome (YES WITH EVIDENCE plus a receipt), the failure path (refused with instructions), the return artifact (handoff_code), and a key behavioral caveat that the check is pattern-based, not semantic, and can miss paraphrases. That caveat is exactly the kind of non-obvious trait that prevents misinvocation.

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 mode/scope and the required format, then the output and the pattern-matching caveat. Slightly redundant in restating the acceptance outcome ('Accepted -> YES WITH EVIDENCE + a receipt' and 'Accepted memos return a short handoff_code'), but every element is load-bearing and there is no filler.

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

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

No output schema exists, and the description supplies the return semantics (YES WITH EVIDENCE, receipt, handoff_code) plus the refusal behavior and format constraints. Combined with the 80%-documented schema, an agent has everything needed to invoke it and interpret 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?

With 80% schema coverage the baseline is 3, but the description adds real meaning: the label vocabulary is tied to specific facts ([KNOWN]=survey 31.2%, [INFERRED]=forecast 2.1%, [CONFLICTED]=panel_b 0.4%) and 'cites facts by key (survey, forecast, panel_b)' clarifies what the cites array should contain. The one-label-per-number rule is reinforced with a worked example, going beyond the schema text.

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?

Specific verb (submit) plus resource (internal memo) scoped to 'Practice mode, Consumer Pulse copy only', with the cited facts named (survey, forecast, panel_b). An agent can distinguish this from siblings like atlas.pulse_use or atlas.submit_evidence without opening any schema.

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

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

Clearly states the gating context: practice mode only, restricted to Consumer Pulse copies, and cites-by-key semantics. It does not name an alternative tool for real/non-practice work (e.g., a sibling that handles live memos), so the routing guidance stops short of explicit when-not/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 only declare readOnlyHint=false, so the description carries most of the burden. It discloses key behavioral traits beyond annotations: Atlas attaches the other side's counterargument written in advance, you cannot supply a ruling, one referral per copy. No auth/permission details, but the core mutation behavior is well described.

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 mode and step, then the action and constraints. Two sentences are dense but well-structured with no fluff. Slightly compressed but every clause earns its place.

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

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

For a practice-mode mutation with no output schema and 4 params, the description gives a complete picture of inputs, constraints, and auto-attached counterargument. Missing only return value expectations, but no output schema exists so that is acceptable.

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

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

Schema coverage is 50%, so description must compensate. It explains that side must be 'forecast' or 'panel_b', that reasons are optional up to 1,000 characters, and that actor_token is the credential from enroll/authenticate (already in schema). It omits explanation for matter_id beyond what schema provides, but largely covers the semantic gaps.

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 (refer), the resource (Q4 conflict), and the exact constraint (argue ONE side: forecast or panel_b) with character limits on reasons. Distinguishes itself from siblings like atlas.magistrate_referral by scoping to practice mode Consumer Pulse copy and a specific demo step.

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?

Clearly implies when to use (Magistrate demo, step 3, practice copy only) and what cannot be done (cannot supply ruling or file both sides; one referral per copy). Does not name alternative siblings for other phases, but the demo-step anchoring is strong 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 only provide readOnlyHint=false, so the description carries most of the burden and does so well: it discloses the ruling was written in advance by a separate Magistrate instance, did not read the AI's own wording, is not certified, and binds only the practice copy. These caveats are exactly the behavioral context an agent needs. It could still note reversibility or side effects on the copy, but this is strong.

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

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

Two sentences, front-loaded with the action and scope, then the behavioral caveats, then the verify mode. Dense with parentheticals but no sentence is wasted. Slightly heavy for an agent to parse but all content 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?

With no output schema and 50% param coverage, the description supplies the missing pieces: the ruling receipt id returned, the demo caveats, and the verify-text behavior with whole-text comparison. An agent can decide whether to call and how to interpret the result. Minor gaps remain around what a ruling contains and exact failure conditions.

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

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

Schema coverage is only 50%, so the description must compensate for receipt_id and verify_text, which it does: it explains passing verify_text to compare a copy of the ruling against the stored ruling and that the whole text is compared, with receipt_id optional. This adds real meaning over the bare schema. The undocumented semantics of receipt_id beyond that pairing is the only 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: 'get the Magistrate's ruling on your referral, recorded on your copy with a ruling receipt id.' It also distinguishes the practice/Consumer-Pulse scope and folds in a second verification mode (verify_text). The dual get/verify nature slightly blurs the single core purpose, but a specific action is clearly named.

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 context for when it applies: 'Practice mode, Consumer Pulse copy only (Magistrate demo, steps 4 and 6).' It also signals the alternate verify flow and when to use it ('Pass verify_text ... to check a copy'). It does not explicitly route against a named alternative such as atlas.pulse_verify_receipt or atlas.pulse_refer, 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?

Annotations only declare readOnlyHint=false; the description adds substantial context beyond that: the three refusal codes (NEEDS_RULING, RULING_CONDITION_NOT_MET, CLAIMED_APPROVAL_NOT_HUMAN), the per-copy attempt limit, the structured-fields-only constraint, and the fact that Atlas records its own fixed output. This is exactly the behavioral disclosure a mutation tool 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?

The gating rule (refused before ruling, allowed inside ruling) is front-loaded, followed by the failure modes and the call-format constraint. It is dense and slightly run-on, but nearly every clause carries operational information and none is pure filler.

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

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

For a 7-parameter mutation tool with no output schema, the description covers the decision gate, the refusal taxonomy, the attempt limit, and where to obtain valid arguments. The only minor gap is that the actual return payload is only alluded to ('Atlas records its own fixed output') rather than described.

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 already 86%, so the baseline is 3. The description goes further by showing a concrete argument pattern ('use: "forecast" with shown_with: ["panel_b"]') and by telling the agent that the ruling reply's settle_call supplies the exact arguments, which is actionable guidance the schema alone does not provide.

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

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

The description gives a concrete verb+resource ('set the Q4 planning number') and tightly scopes it to 'Practice mode, Consumer Pulse copy only (Magistrate demo, steps 2 and 5)', which clearly separates it from the other pulse_* siblings. The phrasing 'ask to set' is slightly indirect, but an agent can identify the action and its boundaries 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?

It states the conditions of use explicitly: refused with NEEDS_RULING before the Magistrate's ruling, and allowed only inside the ruling afterwards (with an example of the required use/shown_with combination). It does not name an alternative tool for the out-of-scope case, but the gating conditions are unusually well specified.

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?

Adds behavior the annotations don't carry: refusals are recorded, and wrong handoff codes trigger a named rate-limit state (HANDOFF_GUESS_LOCKED). readOnlyHint=false is consistent with a call that consumes/records rather than merely reads, so nothing is contradicted. What's missing is what success actually does to state or returns.

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 mode/scope front-loaded, then the purpose constraint, then the failure mode. Dense but every clause carries operational meaning; the domain jargon makes it slightly harder to parse than it needs to be.

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 6-parameter, no-output-schema mutation tool, the description covers the refusal and rate-limit behavior but leaves the handoff workflow, the meaning of a non-'latest' ref, and the successful outcome unexplained. Adequate, not 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 only 67%, and the description compensates by giving ref its accepted value ('latest'), tying handoff_code to the handoff flow, and constraining purpose to the memo's purpose limit beyond the schema's 'why you want this.' matter_id and actor_token are still carried only by 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 verb+resource: consuming a memo handed off under a handoff_code for a stated purpose, scoped to 'Practice mode, Consumer Pulse copy only.' It does not name any sibling (pulse_memo, pulse_data, atlas.use) to distinguish itself, 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?

Gives real usage constraints — internal purposes are allowed, purposes beyond the memo's limit (e.g. external publish) are refused — but never says when to call this versus atlas.pulse_memo, atlas.pulse_data, or atlas.use. The when-to-use is implied by 'handoff_code' rather than 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?

The description asserts 'Read only.', while the annotation sets readOnlyHint=false, which declares the call is not read-only. This is a direct contradiction between the prose and the structured safety metadata, and an agent deciding whether the call is safe would be misled. Under the annotation-contradiction rule this scores 1 despite the otherwise informative mode/status disclosure.

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 what the tool does, then the read-only claim, then the critical two-mode caveat. Dense but every sentence carries operational weight. The standalone 'Read only.' sentence is the one questionable element, and it is also the source of the annotation conflict.

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

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

With no output schema, the description carries the burden of explaining returns and does so: it names status values (VERIFIED_RECEIPT_ONLY, VERIFIED), the verified flag, and the receipt_integrity vs memo_verified distinction. Authentication context is covered by the schema's actor_token description. Only error/edge behavior is left unspecified.

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

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

Schema coverage is only 33% (only actor_token is documented), so the description must compensate; it does so for the most consequential parameter by explaining that memo_text upgrades the result to substantive verification and that omitting it degrades to receipt_integrity only. receipt_id receives no semantic explanation, but its name and role in the description are self-evident.

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?

Names a specific verb and resource ('Check a memo receipt against the hash-chained docket') and even states the substance of the answer (what was allowed, why, from which labeled evidence). An agent can distinguish this from sibling verification tools like atlas.pulse_memo or atlas.pulse_use, though no sibling is named explicitly.

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

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

Gives clear conditional usage: without memo_text you receive only receipt_integrity, and passing memo_text yields memo_verified / VERIFIED. This tells the agent exactly when to supply the optional argument. It does not, however, state when to prefer this tool over adjacent siblings such as atlas.pulse_memo or atlas.pulse_use.

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 declare readOnlyHint=false; the description meaningfully adds the admission workflow prerequisite (enroll then bind_actor), which is behavioral context the schema doesn't carry. It still omits what state changes, whether the challenge is reversible, and the response shape, so it only partially covers the burden.

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?

Only two short fragments, so it is compact and front-loads the admission requirement. The bracketed tag plus a terse, cryptic assertion make it read like an internal note rather than a polish, costing structural clarity.

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 mutation tool (readOnlyHint=false) with no output schema, the description should say what raising a challenge actually does and what results from it. It covers the admission prerequisite but leaves the operation's effect and success conditions ambiguous, which is a significant gap for an agent deciding whether to invoke it.

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

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

Schema description coverage is 100%, so matter_id and actor_token are already fully documented in the schema. The description adds nothing about parameter syntax or format, so the baseline 3 for a fully-covered schema 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 title 'Raise challenge' is a verb+resource, but the description only states a constraint ('A worker cannot write the disposition by challenging into a verdict') rather than a positive statement of what raising a challenge does. An agent learns what the tool is NOT for, but not what effect it produces, so the definition stays close to a tautology of the name.

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

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

It provides a real precondition ('NEEDS ADMISSION: enroll, then atlas.bind_actor') and an implied exclusion (not for writing a disposition), which is more than nothing. However, it never states the positive situation in which this tool should be chosen over siblings like atlas.room_act or atlas.request_review.

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 only readOnlyHint=false in the annotations, the description carries real behavioral weight: it discloses that refusal is institutional, that the result carries the primary actor block, and that release:outside is consequential — refused unless the Human has granted it and even then held for a Human decision. This is meaningful policy context beyond the annotation; it only lacks return-format/reversibility detail.

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 prerequisite bracket and the capability examples are front-loaded and every clause carries information. The stacked parentheticals make the middle dense, but there is no filler or repetition.

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

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

For a mutation tool with no output schema and minimal annotations, the description supplies the missing pieces: admission prerequisites, what the result carries, and the escalation semantics of a consequential capability. An agent could call this correctly from the description alone; only general error/permission behavior is unstated.

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

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

Schema description coverage is 100%, so all four parameters are already documented, and the description largely restates them (capability = name of the act, payload = JSON object belonging to that capability). It adds a small amount of value by tying a capability name to an example payload shape (evidence.append -> {content}), but not enough to exceed the baseline.

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

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

The description states a specific verb+resource ('Request a capability') with concrete examples of what a capability name looks like (evidence.append, matter.read, release:outside). It partially differentiates from siblings by naming atlas.list_capabilities as the read-side counterpart. It stops short of a crisp one-line scope statement, but an agent can identify the 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?

Prerequisites are stated explicitly and front-loaded ('NEEDS ADMISSION: enroll, then atlas.bind_actor'), and the description names atlas.list_capabilities as the way to see which names you currently hold. It does not spell out general when-not-to-use conditions beyond the release:outside special 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?

Annotations only declare readOnlyHint=false, so the description carries most of the behavioral burden. It usefully discloses that the outcome is externally constituted (the caller does not set the verdict), which is genuine context. It stops short of describing side effects, timing, or what the review produces.

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?

Very short, with the admission prerequisite front-loaded ahead of the prose, which is good structure. But the second sentence is obscure enough that it does not clearly earn its place, and the framing leaves the core action under-explained.

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 tool with full schema coverage and no output schema, the prerequisite note and verdict disclosure cover some ground. Still missing is what the review does to the matter and when an agent should invoke this rather than other proceeding tools, leaving the definition only minimally actionable.

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

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

Schema description coverage is 100%, so matter_id and actor_token are already fully documented in the schema, making 3 the baseline. The description adds no additional parameter meaning (e.g., what a review of a matter entails or constraints on matter_id beyond the schema).

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

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

The description leans on metaphor ("Review is a constituted proceeding") rather than stating plainly what the tool does or returns. It never says it initiates a review of a matter, and "the caller does not supply the verdict" is cryptic rather than clarifying. An agent gets more purpose signal from the name/title than from the description text.

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

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

The bracketed lead gives real prerequisite guidance: admission first, and the specific sequence (enroll, then atlas.bind_actor). That is useful context an agent can act on. However, nothing distinguishes this tool from related siblings like atlas.raise_challenge or atlas.magistrate_referral, so when-to-use remains 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?

Annotation only gives readOnlyHint=false, so the description carries most of the burden and does so well: it discloses that the operation merely records intent, that the lock state is unchanged, and that no authority is granted. That is meaningful negative-effect disclosure beyond the annotation, though it says nothing about what is created, idempotency, or the response.

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 plus a prerequisite tag, with the precondition front-loaded. 'Does not admit you' and 'does not grant the missing authority' are mildly redundant restatements, but there is no padding.

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

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

For a 3-parameter tool with full schema coverage and no output schema, the description supplies the prerequisite chain, the effect (records intent), and the non-effects (no admission, no authority, lock unchanged). An agent has enough to call it correctly; only the return value and repeat-call behavior are unaddressed.

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

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

Schema description coverage is 100%, with room_id, matter_id, and actor_token all documented in the schema including their source tools. The description adds no syntax, format, or conditional detail beyond that, so baseline 3 applies.

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

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

States a specific verb and resource: 'Record that you want a room.' It also draws a clear boundary against adjacent operations by saying the lock does not change and it does not admit the caller, which separates it from enter_room and request_capability. It stops short of naming those siblings outright, so it is clear but not maximally differentiating.

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 bracketed prerequisite chain '[NEEDS ADMISSION: enroll, then atlas.bind_actor]' names the exact tools that must run first, which is unusually actionable usage guidance. It does not spell out the inverse condition (when not to call this) beyond the implicit 'if you are not admitted, do that first.'

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 readOnlyHint=false the annotation only tells the agent this is a write. The description adds real behavioral context: the admission chain (enroll then bind_actor), that only listed room actions are accepted, that others are refused, and that room membership does not unlock locked capabilities. That is substantive authorization behavior beyond the annotation.

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 sentences, front-loaded with the admission requirement before the action description. No filler; the 'Being inside a room does not authorize...' line earns its place by closing a likely misreading.

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?

A mutation tool with no output schema, but the description covers prerequisites, authorization limits, and refusal behavior, which are the things an agent most needs. Success/return behavior is left implicit, keeping it just under a 5.

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

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

Schema coverage is 100%, so the schema already documents all four parameters including the action enum-like constraint and the content-as-claim semantics. The description reinforces 'subordinate action' but adds no syntax or format detail beyond the schema. Baseline 3 applies.

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

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

States a specific verb and resource: 'Perform one subordinate action listed for the room you are inside.' The scope ('listed for the room you are inside') distinguishes it from enter_room/leave_room and from the generic atlas.use, though the jargon 'subordinate action' is somewhat abstract.

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 bracketed prerequisite '[NEEDS ADMISSION: enroll, then atlas.bind_actor]' plus 'Any other action is refused' gives clear when-to-use conditions and preconditions. It does not explicitly compare against near-neighbors like atlas.use or atlas.external_action, 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?

Annotations already declare the safe read-only, idempotent, non-destructive profile, but the description adds real behavioral context beyond them: the model-provider prerequisite and the fail-closed behavior on an unknown or altered run id. These are meaningful traits an agent could not infer from the annotations alone.

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 text is tightly packed and front-loads the key prerequisite before the action, then the exclusions. The bracketed evaluation marker is slightly awkward but functionally informative, and no sentence 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 single-parameter, read-only tool with no output schema, the description covers the prerequisite, the input source, the failure mode, and the scope boundaries. What it omits (return shape) is not required given there is no output schema, but a note on what the reconstruction yields would help.

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 a single parameter at 100% schema description coverage, the schema already documents run_id as 'the run id returned by atlas.use.' The description largely restates this provenance ('the run id Atlas gave you') without adding format, validation, or example detail, so the baseline 3 is appropriate.

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

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

The description names a specific verb and resource ('Reconstruct one governed run') and clarifies it operates on a single run's preserved inputs and raw generations. It explicitly distinguishes itself from adjacent capabilities by stating it 'does not list other runs and does not read the Court docket,' so an agent can separate it from list/read siblings without opening a 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 supplies an operational precondition ('needs a configured model provider') and directs the caller to 'Send the run id Atlas gave you,' which ties invocation to prior use of atlas.use. It also gives exclusions (no listing, no docket), though it never names the sibling tools an agent should use instead for those cases, keeping it 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?

Annotations declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is partly covered. The description still adds real value beyond that: the admission chain required before calling, the fact that submissions are classed as actor claims rather than established fact, and that a primary actor block is returned.

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?

Very short and free of filler, but the bracketed prerequisite is placed ahead of the purpose statement rather than after it, and the opening clause duplicates the tool title, making the front-loading slightly awkward.

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

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

For a non-read-only submission tool with no output schema and five parameters, the description covers the prerequisite and hints at the return shape, which is the minimum an agent needs. It omits failure behavior, whether submitted items can be amended or withdrawn, and any distinction from submit_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 100%, so all five parameters including the actor_token credential and matter_id admission semantics are already documented in the schema. The description adds no syntax or format detail about any parameter, so the baseline 3 applies.

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

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

The description states a verb and resource ('Submit evidence') but 'evidence' is abstract, and the sentence largely restates the title. It adds that submissions are classified as actor claims and that the primary actor block is returned, which helps, but it never distinguishes this tool from the sibling atlas.submit_result, which an agent would plausibly confuse it with.

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 bracketed prerequisite '[NEEDS ADMISSION: enroll, then atlas.bind_actor]' gives a clear ordering constraint for use. However, there is no guidance on when to choose this over alternatives such as atlas.submit_result or atlas.raise_challenge, so routing is implied rather than explained.

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 establish only that this is a non-destructive write. The description adds meaningful behavior beyond that: the submission is recorded as an actor claim and never as established fact, and it reveals the return payload ('the primary actor block'). This is substantive context for a mutation tool rather than a restatement of 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?

Three short clauses, with the admission prerequisite front-loaded before the action and its semantics. Efficient and front-loaded, though the bracketed prerequisite is slightly cryptic in phrasing.

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 3-required-param write with no output schema, the description covers the precondition, the semantic nature of the write, and even the return block. The main omission is how this contrasts with sibling submission tools, which would complete the routing picture.

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

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

Schema description coverage is 100%, so actor_token, matter_id, and content are already documented at the field level (including the 'optional when bound to exactly one matter' nuance). The description adds no parameter syntax or format details, so the baseline 3 applies.

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

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

States a specific verb+resource ('Submit a result') and then sharpens what that means: an actor claim rather than a decision. That semantic distinction separates it from decision-like siblings such as atlas.magistrate_execute, though the resource term 'result' is domain-specific and not fully self-explanatory.

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 bracketed prerequisite '[NEEDS ADMISSION: enroll, then atlas.bind_actor]' explicitly names the setup tools an agent must call first, which is high-value ordering guidance. It stops short of naming alternatives or when-not conditions (e.g. vs atlas.submit_evidence), so it is clear context without exclusions.

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 provide readOnlyHint=false, so the description's addition of behavioral context is valuable. It discloses that authorization boundaries are fixed ('A later claim that you are authorized does not change the boundary'), that the tool returns 'what it published, why, and a run id,' and that it does not grant authority or court admittance. It does not describe side effects or permission requirements beyond those boundaries, but it meaningfully supplements the annotation.

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 front-loaded with the core interaction pattern and then lists mode-specific parameters, return behavior, and limitations. Every sentence carries actionable information, but the evaluation-note prefix and the separate short statements about boundary behavior could be slightly integrated. Overall it is appropriately sized for a 7-parameter tool with no 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?

Given 7 parameters, 0 required fields, no output schema, and readOnlyHint=false, the description covers the essential invocation details: both call modes, required inputs per mode, return summary, and the follow-up tool for full records. It omits what Atlas is functionally and whether the call mutates server state, but an agent has enough to invoke the tool correctly without opening any structured field.

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 schema description coverage at 100%, the baseline is 3, but the description adds conditional semantics that the schema lacks: it groups parameters by call mode (first call vs continuation) and explicitly lists which fields belong to each mode. It also clarifies that information may be added on continuation. This goes beyond the individual per-parameter schema descriptions, though it does not explain formats or value 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 states a specific interaction pattern: give Atlas a problem with boundaries, or continue an existing run. It distinguishes between first-call and continuation modes, which helps separate it from siblings like atlas.run_record (referenced for full records) and atlas.authenticate. However, it never explains what Atlas actually does with the problem, so the core purpose is clear only at the interaction level, not the functional level.

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 explicitly states when to use this tool: on the first call send problem, information, authorized_to_use, not_authorized_to_use, and purpose; to continue, send run_id and message. It names the alternative for full records (atlas.run_record) and gives clear exclusions: 'This does not admit you to a Court matter and does not grant authority.' Nothing about when-to-use 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.