Focxle: negotiation rooms and locked agreements for B2B AI agents

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

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: no signup/email/form, free, and that Focxle never holds or moves money. It also explains the implications of having an owner vs. not, and the optional business info. This is quite transparent for a registration tool, though it does not explicitly mention persistence or any 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?

The description is reasonably concise, front-loading the core action ('Register in one call') and then expanding with useful details. It is structured with clear sentences and avoids fluff, though it could be slightly tightened without losing value.

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

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

The description covers what the user gets (id and key), optional business info, and the owner concept. It does not describe the exact response format, but it implies the result. For a simple registration tool with no output schema, this is adequate, though mentioning the response structure would improve completeness.

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

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

Schema coverage is 100%, so the schema already documents each parameter. The description adds meaningful context beyond the schema: for 'name' it says 'Leave it out and we make one up,' and for 'purpose' it explains findability. This extra guidance helps the agent decide how to fill parameters.

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

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

The description clearly states the tool's purpose: 'Register in one call.' It specifies the resource (getting a Focxle id and key) and differentiates from all siblings, which focus on agreements, negotiations, payments, etc. There is no ambiguity about what this tool does.

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

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

The description clearly indicates when to use this tool (to register) and explains the outcome. It does not need to exclude alternatives because no sibling tool performs registration. The context is clear enough for an agent to know this is the entry point.

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

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

With no annotations, the description carries the full burden. It discloses the key side effect (raises buyer's score) and the crucial constraint that it never creates unreported payments. This is significant behavioral transparency for a tool of this simplicity.

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 primary actor and action. The key constraint is stated in the second sentence with no fluff. Every word contributes to the tool's usability.

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

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

For a simple 3-parameter tool with no output schema and no annotations, the description explains the actor, the effect on the buyer's score, and the limitation. It does not describe failure cases (e.g., if no payments were reported), but that is implicitly covered. The description is sufficient for correct invocation.

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

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

Schema coverage is 67% (agreement_id has no description). The description adds semantics for 'amount' by explaining it is optional and what happens when omitted. This goes beyond the schema's brief note, though agreement_id remains self-explanatory. Overall, the description enriches parameter understanding.

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

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

The description clearly states the verb 'confirm' and the resource 'buyer paid you under an agreement'. It distinguishes itself from payment recording tools by explicitly saying it never creates a payment the buyer did not report, which is a unique and specific scope.

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

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

It identifies the target user ('For the seller') and the condition for use (confirming reported payments). It implies when not to use it (when the buyer didn't report), but does not explicitly name sibling alternatives. Still, the guidance is clear enough for an agent to select it appropriately.

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

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

With no annotations, the description carries the full disclosure burden. It conveys that the operation is read-only, requires the agreement to be locked, and restricts access to participants ('you are part of'). It also previews the returned history. It does not detail failure modes or exact permission checks, but it is substantially transparent for a getter.

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

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

The description is one dense, front-loaded sentence with no filler. It names the action, the target, the eligibility condition, and the expected returned data without restating the tool name or schema.

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

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

For a tool with one required parameter and no output schema, the description adequately explains both the input context and the return contents. It could add error behavior or explicitly route to siblings for non-locked agreements, but those are minor gaps for a simple read tool.

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

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

The schema only defines agreement_id as a string with 0% description coverage, and the description does not explicitly state that agreement_id identifies the agreement to read. However, the single parameter is self-explanatory, and the phrase 'a locked agreement' clarifies what kind of object the ID refers to. This is minimally acceptable but does not fully compensate for the schema 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?

The description uses a specific verb and resource: 'Read a locked agreement you are part of.' It also enumerates the returned content (terms, approval time, signature, post-agreement events like payments), making the tool's purpose unmistakable and distinguishing it from negotiation_get (pre-lock agreements) and agreement_verify (which implies validation).

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

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

The phrase 'locked agreement you are part of' provides clear context for when to use the tool: only for finalized agreements where the caller is a participant. It does not explicitly name alternatives or state when not to use it, but the implied selection context is strong enough for an agent to route correctly.

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

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

With no annotations, the description must carry the behavioral burden. It discloses that the operation is a read-only 'check' and that it requires no account, which is useful. But it does not describe what the tool returns, whether verification success/failure is signaled in a particular way, or any side effects, leaving the agent partially in the dark.

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

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

Three short sentences with no filler. The purpose is front-loaded, and the invocation alternatives and auth note each earn their place. The description is well-sized for the tool's simplicity.

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

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

For a four-parameter, no-required-fields verification tool, the description covers the essential usage patterns and the access requirement. The main gap is the absence of any statement about what the check returns or how results are formatted, which matters more since there is no output schema. Still, the core selection and invocation knowledge is present.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds real semantic value beyond the schema by explaining the either/or relationship: supply agreement_id, or paste the trio of canonical text, signature, and public key from a copy. This resolves the schema's ambiguous 'Or:' phrasing on the canonical parameter.

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

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

The description opens with a specific verb and resource: 'Check a Focxle agreement has not been changed.' This clearly identifies the operation as integrity verification, which is distinct from sibling tools like agreement_get or agreement_confirm_paid. The alternative invocation modes (agreement_id vs pasted copy) further sharpen the purpose.

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

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

The description gives clear usage context: 'Give its agreement_id, or paste the canonical text, signature and public key from a copy somebody sent you.' This tells an agent how to invoke it, and the 'no account needed' note clarifies access. However, it does not explicitly name when to prefer this over siblings like agreement_get, so it stops short of 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?

With no annotations, the description carries the full burden, and it does so well: it discloses irreversibility ('nobody can change, us included'), the returned agreement_id, and the private rule-break failure mode. This is transparent and actionable.

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, no filler, with the primary action first and consequences and failure modes second. Every sentence earns its place.

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

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

The description covers the main flow, side effects, and rule-based blocking. It does not explicitly say what happens when the user approves but the counterparty has not yet approved, which could matter for an agent interpreting the response. Overall, it is nearly complete.

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

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

Schema coverage is 100%, and the input schema already explains offer_seq's role and the default 'on the table' behavior. The description adds little beyond reinforcing that framing, so baseline 3 is appropriate.

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

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

The description uses a specific verb and resource ('Approve the offer') and explains the unique outcome: both sides approving locks a signed agreement. This clearly distinguishes it from siblings like negotiation_close or negotiation_send.

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

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

It gives clear context for when to use the tool: to approve the current offer and potentially finalize an agreement. It also covers the rule-check scenario, but it does not explicitly name alternatives or exclusions, so it stops short of a 5.

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

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

With no annotations, the description carries the burden. It discloses a key behavior: the negotiation stays on record and cannot be added to. However, it does not mention reversibility, permissions, or what happens to existing data or pending actions. It gives partial transparency.

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

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

Two concise sentences, front-loaded with the purpose, delivering the core action and a key consequence without waste.

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

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

For a simple two-parameter tool with no output schema, the description covers the core action but omits details like what room_id refers to, any prerequisites, or the nature of the result. It is adequate but not fully complete.

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

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

Schema coverage is 50% (room_id lacks description). The description does not explain any parameters, so the required room_id is left undocumented beyond the schema. The description adds no meaning to the parameters, failing to compensate for the schema 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?

The description clearly states 'End a negotiation without a deal' which specifies the action (end), the resource (negotiation), and the condition (without a deal). It also distinguishes from siblings like negotiation_approve which likely ends with a deal. The additional note about staying on record and no more additions clarifies the scope.

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

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

The description implies when to use (when no deal is reached) but does not explicitly name alternatives or provide when-not-to-use guidance. It does not mention the existence of other negotiation tools, leaving the agent to infer from the 'without a deal' phrase.

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

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

With no annotations provided, the description must disclose behavioral characteristics. It mentions 'whether the record is still intact', which hints at integrity but does not clarify what happens if the record is not intact (e.g., error vs. partial data). It also doesn't state whether this is read-only (likely) or requires any authentication or permissions, though the description 'Read' implies no mutation.

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

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

The description is a single, fairly dense sentence that front-loads the core listing of returned content. However, it could be more concise by breaking into two sentences (e.g., first what it returns, then the integrity note). It is not excessively long, but the final phrase about integrity feels tacked on.

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 tool, the description is relatively complete on the return content, but given there is no output schema and no annotations, it should provide more context on the response format, any error conditions, or the nature of 'private notes'. The missing parameter semantics further reduce completeness.

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

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

Schema description coverage is 0%, meaning the parameter 'room_id' is entirely undocumented in both schema and description. The description fails to explain what 'room_id' is, its format, or its role in identifying the negotiation. Since there is only one parameter, the description should have at least mentioned that it identifies the negotiation.

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 explicitly states the verb 'Read' and the resource 'negotiation', and enumerates the specific content returned: entries in order, the offer, approval status, next steps, and private notes. This clearly distinguishes it from sibling tools like negotiation_list (listing negotiations) and negotiation_approve (acting on them).

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

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

The description clearly conveys that this is the tool to use when you want to read a negotiation's full state, including private notes. It does not explicitly name alternative tools or exclusions, but given the sibling set, the read vs. list vs. act distinction is implied strongly enough that an agent would infer when to use it.

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

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

With no annotations provided, the description carries the full burden, and it does meaningfully: it discloses that new users get registered, that the call produces a key, and that the operation is free. These side effects go beyond anything the schema states. It does not cover failure behavior (e.g., invalid join code), but the main behavioral consequences are transparent.

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

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

The purpose is front-loaded in the first sentence, and each clause earns its place. The standalone 'Free.' sentence is terse but conveys a distinct cost signal. Nothing is wasted, though it could be slightly tighter as prose.

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?

Against moderate complexity (3 params, one nested object) with no annotations and no output schema, the description covers the action, trigger condition, side effects (registration, key issuance), and cost. The 'gives you a key' effectively hints at the return outcome. Missing are failure semantics and what the key is used for, but these are minor for a join 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 the baseline of 3 applies. The description and schema jointly reinforce that name and business are only used when the user is new, but the description adds no parameter-specific meaning beyond what the schema already conveys.

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 (join), resource (negotiation), and mechanism (join code sent by the inviting agent), which clearly separates it from siblings like negotiation_open (create) and negotiation_list (view). The conditional registration note further distinguishes it from agent_register.

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 clear context for when to use the tool: when another agent has invited you and sent a join code. It also implicitly addresses the alternative of separate registration by clarifying that new users are registered 'in the same call,' so no separate agent_register step is needed. It stops short of explicitly naming alternatives or 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?

With no annotations provided, the description carries the full burden. 'List' clearly indicates a read-only operation, and 'your' conveys user scope, but the description does not disclose authentication requirements, pagination behavior, or what exactly 'what happens next' includes.

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

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

A single sentence that front-loads the action and resource, then adds ordering and the distinguishing next-step detail. There is no filler or redundant restatement of the tool name.

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

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

For a zero-parameter list tool, the description is largely complete: it specifies scope, ordering, and included content. The main gap is the vague 'what happens next' and lack of output-schema detail, but the operation is simple enough that an agent can still select and invoke it correctly.

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

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

The tool has zero parameters and an empty schema, so there are no parameter semantics to explain. The description reinforces that the tool takes no arguments and simply returns the caller's negotiations and agreements; baseline 4 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 uses a specific verb ('List') and names the exact resources ('negotiations and locked agreements'), adding ordering ('newest first') and a distinguishing payload detail ('what happens next in each'). This clearly differentiates it from single-item sibling tools like negotiation_get and agreement_get.

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

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

The context is clear: use this to get an overview of the user's negotiations and locked agreements. However, it does not explicitly state when not to use it or mention alternatives like negotiation_get/agreement_get for single-entity details, so the guidance 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?

With no annotations provided, the description carries full behavioral disclosure. It reveals that offers are written down and immutable ('nobody can edit it'), that rules set by a human operator are checked privately and never revealed to the other side, and that the service is 'Free'. These are significant behavioral traits that go beyond simple function statements.

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

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

The description is a single coherent paragraph that front-loads the core action and then flows into usage details. Each sentence adds information: what it does, how to specify parties, the join-code alternative, optional first offer, immutability, rule checking, and cost. It's not overly verbose and is well-structured.

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

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

For a tool with a nested offer object and five parameters, the description covers the essential flow: initiating negotiation, choosing counterpart, offering, and rule enforcement. It doesn't describe the response format (e.g., returned negotiation ID), but without an output schema that's not required. It adequately prepares an agent to call the tool correctly.

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

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

Schema coverage is 100%, so all parameters are already documented in the schema. The description adds marginal context: it explains the role and subject in plain terms, and notably clarifies the behavior of with_agent_id (leave it out to get a join code). However, most parameter semantics are already covered by the schema's detailed descriptions, so the description adds limited extra value.

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

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

The description clearly states the tool's purpose: 'Start a negotiation with another business's AI agent.' It specifies the verb 'start' and the resource 'negotiation', and differentiates from sibling tools like negotiation_send (for subsequent offers) and negotiation_join (for joining an existing negotiation). The mention of buyer/seller and deal subject makes the action unmistakable.

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

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

The description provides clear instructions on how to use the tool: specify role and subject, optionally provide an agent_id for Focxle members, or omit it to receive a join code. It also mentions the option to include a first offer. While it doesn't explicitly state when NOT to use this tool (e.g., for sending follow-up offers), the flow is clear and the distinction from siblings is 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?

No annotations are provided, so the description carries the full burden. It discloses meaningful behavior: a new offer replaces the current one, totals are computed, sent content persists ('kept for good'), the other side reads it, and messages are screened for wording that instructs the other agent. It could add auth or error behavior, but the core side effects are transparent.

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

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

Five short sentences, front-loaded with the tool's purpose. Each behavioral detail earns its place, though 'We work out the total' is slightly redundant with the schema's note about Focxle calculating the total. Overall tight and readable.

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

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

Given the lack of annotations and output schema, the description covers the important behavioral guarantees: offer replacement, persistence, visibility to the other side, and message screening. It doesn't explicitly describe return values, confirmation, or error cases, but for a send action with a well-documented schema this is a reasonably complete 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 the schema already documents room_id, message, and every field of the nested offer object. The description adds context about offer replacement and total calculation but does not materially clarify individual parameters beyond what the schema provides. 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 uses a specific verb and resource: 'Send an offer, a counter-offer or a message in a negotiation.' It also clarifies the immediate effect ('A new offer replaces the one on the table'), which distinguishes it clearly from the sibling negotiation_* tools like get, close, approve, and list. Even without naming a sibling, an agent can tell what this tool is for.

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

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

The intended use is implied by the first sentence: use this tool when you need to send something in a negotiation. However, there is no explicit 'when not to use' or routing to alternatives such as negotiation_get for reading or negotiation_approve for accepting. This is adequate but leaves guidance to inference.

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

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

With no annotations, the description carries the full burden. It discloses that the tool returns a link and a short message, that the page asks for no password and no bank details (reassuring safety), and that the owner writes rules in their own words. It doesn't mention rate limits or whether the link expires, but the key behavioral traits are covered.

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

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

The description is concise and front-loaded: it states the primary action first, then explains the flow and the return value. Every sentence adds value, and there's no fluff. It's appropriately sized for a tool with no parameters.

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

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

Given the tool has no parameters, no output schema, and no annotations, the description covers the essential context: what the tool does, what the owner does, what the agent receives, and a safety note. It could mention whether the link expires or if there's a follow-up step, but for a simple link-generation tool, this is nearly complete.

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

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

The input schema has zero parameters, so the description doesn't need to explain parameters. The baseline for 0 params is 4, and the description adds context about what the tool does with no inputs, which is sufficient. No parameter documentation is needed.

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

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

The description clearly states the tool's purpose: generating a link to send to the owner/principal so they can set spending rules. It uses a specific verb ('Get a link'), identifies the resource (the person or business that runs you), and explains the outcome (Focxle checks deals and payments against those rules). This distinguishes it from sibling tools like agreement_get or negotiation_open, which serve different purposes.

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

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

The description implies when to use this tool: when you need to invite the owner to define purchasing rules. It doesn't explicitly name alternatives or state when not to use it, but the context is clear enough given the sibling list. A slight gap is the lack of explicit exclusion (e.g., 'use this instead of X when...'), but the purpose is specific enough that an agent can infer the right context.

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

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

With no annotations, the description carries full responsibility, and it does this well. It discloses side effects (every heads-up is kept on record), conditional outputs (signed approval only when checking is on and answer is yes), registration behavior, and financial safety (Focxle never holds or moves money).

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 action and then explains behavior, outputs, side effects, and reassurance. It is longer than typical but each sentence adds relevant context for a tool with no annotations. Minor extras like 'Free.' and final reassurance slightly reduce conciseness but still serve behavioral transparency.

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 must explain what the caller gets back. It does: a yes/no answer with plain-word reason and a signed approval when applicable. It also covers side effects, registration, no-rules behavior, and the fact that money is not handled. For a tool with this complexityessing and branch logic, nothing essential is missing.

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

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

Schema description coverage is 83%, so the schema already documents most parameters well. The description adds high-level meaning by mapping to 'who you are paying, how much, and what it is for' and mentions agreement checks, but it does not substantially explain parameter formats, defaults, or idempotency beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Tell Focxle before you pay anyone.' It clearly states what is sent, what Focxle does with it, and what the caller gets back. 'Before you pay' and 'heads-up' differentiate it from record-keeping or verification siblings like payment_record and trust_check_agent.

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 says to use this when you are about to pay someone and before the payment happens. It also explains behavior in different circumstances: rules set vs no rules set, registered vs not registered. It does not name alternative tools directly or give explicit when-not-to-use guidance, 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 no annotations, the description carries the full burden. It explicitly uses the verb 'Read', implying read-only behavior, and details the returned content (payments, confirmations, score, tips) and the public link. It adds meaningful context beyond the empty schema, though it does not mention side effects or authentication requirements, which are likely implied for a self-service read tool.

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

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

The description is two concise sentences, front-loaded with the core purpose ('Read your own record'). Every clause adds value: contents, confirmations, score, and the public link. There is no 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 no-parameter, no-output-schema tool, the description covers the essential behavior: what data is returned (payments, confirmations, score, tips) and the public link. It does not specify the link format or error conditions, but given the tool's simplicity, it is sufficiently complete for an agent to understand the expected return.

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?

There are zero parameters, so the schema is trivially covered (100%). The baseline for 0 parameters is 4, and the description adds no parameter-related meaning because none exist. No compensation is needed.

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

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

The description opens with 'Read your own record', a specific verb and resource. It then enumerates the contents: payments, confirmations, score, and improvement tips, plus a public link. This clearly distinguishes it from sibling tools like payment_record (recording) and trust_check_agent (checking others).

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

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

The description clearly states 'Read your own record', indicating it's for viewing one's own payment history. It also provides a concrete use case: sending the public link to businesses. However, it does not explicitly name alternatives or when not to use this tool, 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?

With no annotations, the description fully carries the disclosure burden and does so well: it states the payment is stored on the user's record, affects their score, generates a confirmation link to the business, and grants additional score weight only after confirmation. It also explicitly discloses that sensitive card numbers, account numbers, and keys are stripped before saving.

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

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

Four sentences, all information-bearing and front-loaded. The core action is the first clause, and every subsequent sentence adds a distinct behavioral fact (no connection needed, score impact, confirmation link, data privacy) without repeating schema content.

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

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

For a tool with 8 parameters, nested objects, no annotations, and no output schema, the description covers the what, why, and consequences. It does not explain the response/return value or the confirmation-link mechanics in detail, but those are not required for selecting and invoking the tool correctly.

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

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

Schema description coverage is 75%, so the schema already documents most parameters with meaningful descriptions. The tool description adds general context (record, score, confirmation link, data stripping) but does not add per-parameter meaning beyond the schema, so a baseline 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Write down a payment you already made,' and immediately broadens scope with 'anywhere: a bank transfer, a card, any payment app, any supplier's portal.' It clearly distinguishes the tool as a manual record-keeping action rather than a connected or initiated payment, and the sibling list contains no other tool with this exact record-a-completed-payment function.

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 context is explicit: this is for payments already made, and 'We do not need to be connected to it' tells the agent connection is not a prerequisite. It does not name a specific sibling alternative or an explicit 'do not use when...' condition, so it stops short of full when/when-not guidance.

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

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

With no annotations, the description carries the full burden. It discloses the score's limitation ('stops at 450 and says so'), states that it is free and requires no account, and details what the returned record contains.

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?

Every sentence earns its place: the primary purpose, the return fields, the score limitation, the access requirement, and the sibling alternative. It is front-loaded and free of filler.

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

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

The tool is simple, the schema covers both parameters, and the description fully covers return contents, limitations, access constraints, and the main alternative. No critical operational context is missing.

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

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

Schema description coverage is 100%, so the parameters are already documented in the schema. The description reinforces agent_id as the core lookup key but adds no new parameter-level semantics beyond what the schema provides.

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: 'Check an AI agent before you deal with it.' It enumerates the returned record fields and explicitly distinguishes the tool from trust_check_wallet, making its scope unmistakable.

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 says when to use this tool ('before you deal with it') and names the alternative for crypto wallets. It also notes there is no account requirement, giving practical entry guidance.

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