Agent Economic Trust

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 contributes that the data is registry-observed and enumerates the content categories, but says nothing about pagination, time window, or volume limits for what could be a large history.

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: the first states what is read and from where, the second states when to use it. Everything is front-loaded and 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?

With no output schema, the description usefully enumerates the returned content (counts, outcomes, counterparties, value, risk), which is the right compensation. It still omits any statement about history depth or whether the result is bounded, so it is strong 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?

There is only one parameter and schema description coverage is 100% ('Agent identifier used in Economic Passports'), so the schema already carries the semantics. The description only implies the agent scoping ('for a specific autonomous agent') without adding format or source details, matching the baseline for high-coverage schemas.

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 (read) and resource (economic history) scoped to a single autonomous agent and to data 'observed by this registry', which separates it from sibling operations like record_outcome or verify_economic_passport. It does not name a sibling directly, but the registry-scoped history framing 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?

'Use when you need transaction counts, outcomes, counterparties, value, or current observed risk before deciding what to do' gives a concrete triggering situation and even the decision context. It stops short of naming an alternative tool (e.g. trust_before_action) or an exclusion, so it is clear context rather than full routing guidance.

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

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

Annotations already declare this is a non-read-only, non-destructive, non-idempotent, closed-world operation, so the safety profile is covered. The description adds a genuinely useful behavioral note that the tool is free during beta and charging is disabled. It stops short of describing what a monitor does operationally (persistence, ownership, alert delivery), which a mutation tool with annotations could still benefit from.

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

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

Two tight sentences with the purpose front-loaded and the usage condition immediately after. The beta/pricing clause is relevant but slightly tangential to invocation, keeping it just short of ideal.

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 three-parameter creation tool with no output schema and no auth/permission annotations, the description covers purpose and trigger but leaves gaps: ownership semantics, whether creation is idempotent, and how a created monitor is identified. Adequate to make the call, incomplete for the mutation it performs.

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

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

Schema description coverage is 0% across three parameters, so the description carries the full burden and largely fails to. It gestures at score/risk-band/decision changes, loosely implying score_drop_threshold, but never explains subject_agent_id versus owner_agent_id or what happens if owner_agent_id is omitted.

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 and resource ('Create continuous monitoring') and scopes it to 'one agent counterparty,' which is clear and actionable. No sibling tool offers comparable monitoring, so explicit differentiation isn't required, but the description doesn't distinguish itself from the broader trust-verification siblings either.

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 concrete trigger condition — 'Use when an agent wants recurring alerts if the counterparty score, risk band, or decision changes materially' — which tells the agent exactly when this tool fits. It does not name alternatives (e.g., trust_before_action for one-off checks), so there is no explicit 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?

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, and openWorldHint=false, so the safety and retry profile is covered structurally. The description adds the genuinely useful 'append-only' trait, which tells the agent records are immutable and new entries accumulate. It omits that non-idempotency means repeat calls create duplicate passports, and says nothing about permissions, so it is solid but not rich.

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, zero filler, and the core action is front-loaded before the usage condition. Every phrase 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 non-idempotent write with no output schema and six parameters, the description covers purpose and timing but leaves the agent guessing about what is returned (e.g., a passport identifier needed by verify_economic_passport), whether prior trust_gate_id linkage is expected, and whether repeat calls are safe. Adequate at the minimum-viable level, not more.

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 only 17%, with five of six parameters carrying no schema prose, so the description must compensate. It only says 'recording the parties and economic context,' which loosely gestures at principal_id/agent_id/counterparty_agent_id and amount/currency but never clarifies their meaning, format, or relationship. This is a clear gap against a low-coverage 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 states a specific verb and resource: 'Create an append-only Economic Passport recording the parties and economic context of one agent-to-agent transaction.' That is precise and distinguishable from the sibling verify_economic_passport by the create/verify contrast. It stops short of explicitly naming the sibling it is not, so it lands at 4 rather than 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?

It gives clear timing context: 'Use after a transaction is agreed or initiated so its eventual outcome can become evidence.' That tells the agent when in the transaction lifecycle to call it and hints at the downstream handoff to record_outcome. No explicit alternatives or exclusion conditions are named, so it is a 4, not a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds only that the payload spans several metric families, without saying anything about pagination, freshness, scoping, or auth requirements.

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 verb and the returned content, with the purpose clause second. The metric enumeration is dense but each item is informative given no output schema exists to carry that 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?

With no output schema, the description carries the burden of describing what comes back, and it does so by naming the metric categories. For a zero-parameter read tool with full annotation coverage, this is close to sufficient; only freshness/pagination details are missing.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool is 4. No syntax or filtering semantics are 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?

States a specific verb ('Read') plus an explicit enumeration of the resources returned (calibration, labeled outcomes, false-ALLOW rate, regression results, discovery metrics, monitors, verified revenue). That distinguishes it clearly from siblings like record_outcome and create_trust_monitor, which write or verify rather than report aggregate trust metrics.

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 second sentence gives a use case ('audit whether the trust model is improving safely'), which implies when the tool is appropriate. However, it names no alternatives and gives no exclusions or prerequisites, so routing decisions relative to the other trust/economics tools are left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered structurally. The description adds the useful framing that this is a zero-side-effect pre-flight check guarding paid calls, but it leaves 'x402 activation state' unexplained and gives no sense of the returned shape.

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

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

Two sentences with zero filler; the what (read pricing/activation state) is front-loaded before the when (pre-flight before paid functionality). 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?

With no parameters, no nested objects, and a full annotation set, little is left to describe; the description covers both intent and trigger. The one gap is that no output schema exists, so the response fields the agent should branch on remain 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?

The tool takes zero parameters (additionalProperties false), so there is no parameter semantics burden and the baseline of 4 applies. The description correctly implies a parameterless global read.

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: 'Read the current pricing and x402 activation state', which is concrete and not a restatement of the name. It does not explicitly differentiate itself from any sibling, though none of the listed siblings (trust monitors, passports, metrics) overlap with pricing, so confusion risk is low.

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

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

Gives an explicit trigger: 'Use to determine whether a Trust Check or Monitor is free or paid before invoking paid functionality.' This tells the agent the exact precondition for calling it. It stops short of naming a specific alternative tool or stating when-not-to-call.

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 destructive=true, non-idempotent, non-readonly. The description adds meaningful context beyond them: outcomes are 'immutable evidence' (append-only, no correction path) and they feed calibration of prior Trust Gate decisions, implying real downstream consequence. It doesn't mention auth/validator requirements or whether a duplicate append is rejected.

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

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

Three short sentences, front-loaded with the action before the precondition and the rationale. Every clause (append, precondition, immutability, calibration consequence) contributes information 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 5-parameter mutation with no output schema and zero schema descriptions, the description covers purpose, timing, and immutability but leaves parameter-level semantics (especially validator_id and evidence_hash) unexplained. Adequate to call correctly but with a clear gap on how to populate the non-obvious fields.

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

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

Schema description coverage is 0% across 5 parameters, so the description carries the burden and largely fails: it never explains the outcome enum values, passport_id format, or the roles of validator_id, evidence_hash, and notes. 'Outcome' and 'Economic Passport' map loosely to two fields, but the other three are undocumented in both schema and description.

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 (append) and resource (final observed outcome to an Economic Passport), which is unambiguous and clearly distinct from siblings like verify_economic_passport or trust_before_action. It does not explicitly name which sibling to prefer in a given situation, so it falls just short of the top mark.

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

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

'Use only when the transaction result is known' gives a concrete precondition and implicitly excludes premature/best-guess recording. There is no explicit statement of alternatives or what to do if the result is unknown, so it stops short of full when/when-not coverage.

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 indicate it is not read-only and not idempotent, consistent with a tool that generates a decision. The description adds meaningful behavioral context: it returns ALLOW, REVIEW, or DENY with evidence and confidence, and clarifies that REVIEW signals insufficient evidence. It does not disclose side effects, rate limits, or whether the evaluation depends on external data that could be stale, but the output semantics are unusually well specified for a non-read-only 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?

Two sentences, front-loaded with the purpose and trigger, followed by the return values and a precise definition of REVIEW. No filler or redundancy.

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 5-parameter decision tool with no output schema, the description covers purpose, trigger, return values, and the ambiguous REVIEW case. It omits what evidence is returned, how confidence is computed, and whether the call has side effects (e.g., logging, monitoring creation). These gaps are moderate given the tool's complexity, but not fatal for an agent 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 80%, so the schema already documents most parameters including action examples and amount semantics. The description does not add parameter-level detail beyond what the schema provides, though it does connect the action parameter conceptually to the tool's purpose. Baseline 3 is appropriate given the high schema coverage.

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

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

The description states a specific verb ('evaluate') and resource ('agent counterparty') and scopes it to a clear trigger ('before an irreversible economic action'). It enumerates concrete examples (paying, hiring, delegating, releasing escrow, granting rights) that distinguish it from sibling tools like issue_economic_passport or verify_economic_passport, which appear to be credential operations rather than pre-action risk evaluation.

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 clearly states when to use it ('before an irreversible economic action') and defines the meaning of the REVIEW outcome for decision routing. However, it does not explicitly contrast with alternatives like agent_economic_history or record_outcome, leaving some ambiguity about whether this is a pre-check or a post-hoc analysis tool.

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 this as a read-only, idempotent, non-destructive, closed-world operation, so the safety profile is covered. The description usefully adds that the outcome history is immutable, but says nothing about what verification entails, how failure/invalid passports are reported, or any auth requirements.

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

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

Two tight sentences, front-loaded with the action and followed by the triggering condition. No filler, though it is brief enough that a little more operational detail would still fit comfortably.

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 one-parameter read tool with no output schema and annotations covering safety, this is nearly complete: it says what is retrieved and when to call it. The remaining gap is the un-explained identifier and verification failure behavior.

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 is a single required parameter, passport_id, and schema description coverage is 0%, so the schema provides no meaning at all. The description never explains what a Passport ID is, its format, or where it comes from, leaving the parameter semantics unaddressed.

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 pair (retrieve and verify) and a specific resource (an Economic Passport plus its immutable outcome history). It implicitly distinguishes itself from the write-oriented sibling issue_economic_passport, though it never names alternatives 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?

It states two concrete triggering conditions: a counterparty presenting a Passport, or a need to inspect transaction evidence. That is clear usage context, but it offers no exclusions or pointers to alternatives such as agent_economic_history.

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 safety profile (readOnly=false, idempotent=false, destructive=false, openWorld=true), so the description's lower bar is met by adding that the token is temporary and that verification produces a binding. It does not say what happens on verification failure, whether an existing binding is overwritten, or whether the binding is reversible. Useful context, but gaps remain for a non-idempotent write.

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 core action stated first and the availability precondition second. Every clause carries information the agent needs.

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-idempotent write tool with no output schema and two partially undocumented parameters, the description covers purpose and a prerequisite but omits failure behavior, binding lifecycle, and what the caller receives on success. Adequate but leaves real gaps.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It adds that 'token' is temporary and that the second parameter is an 'agent identifier', which maps to subject_agent_id. It does not explain that subject_agent_id is optional or what value shape either parameter expects.

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 (verify) plus the resource (a temporary Moltbook identity token) and the secondary effect (binding the verified assertion to an agent identifier). This cleanly distinguishes it from the sibling verify_economic_passport, which operates on a different artifact. 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?

It gives one explicit precondition – 'Available only after the Moltbook developer identity integration is configured' – which is genuine usage guidance. However, it names no alternatives and does not say when to prefer this over verify_economic_passport or what to do if the integration is not set up. Implied usage only beyond the prerequisite.

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