Gloam

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

Annotations already declare readOnly, idempotent, non-destructive behavior, but the description adds material context beyond them: keys are kept on the local machine, and the resulting server can sign and pay (shield, private pay, x402, MPP, spending limits). The key-custody statement is a genuine security property an agent should know before recommending it. It still doesn't say what the response looks like (commands as text vs. executed install).

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?

One sentence, front-loaded with the core action ('Commands to install the local Gloam MCP server'). The parenthetical capability list (shield, private pay, x402, MPP, spending limits) reads as marketing rather than selection-relevant detail, but it is not enough to break the structure.

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-optional-parameter, read-only helper with full annotations and no output schema, the description covers what it produces, which clients it supports, and the security posture. The only real gap is clarifying that it returns commands rather than executing the install.

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 single enum parameter is fully described, so the baseline is 3. The description's client list loosely mirrors the enum but is incomplete (no 'gemini', no 'all'), so it neither adds reliable meaning nor compensates for anything missing.

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 output — install commands for the local Gloam MCP server — and enumerates the target clients, which distinguishes it from siblings like gloam_info or gloam_create_payment_request. It is slightly ambiguous whether the tool performs an install or merely returns commands, and the name 'connect_full_agent' doesn't perfectly match 'commands to install'.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no sibling is named as an alternative. The reader must infer from 'Commands to install' that this is the onboarding/setup entry point rather than a runtime payment 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 cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely new behavioral context: the payload rides in the URL fragment so the payer's browser never transmits it to a server, the payer must review and confirm in-app, and the credential requirement is explicit ('your public Gloam address, never a key'). That is exactly the kind of beyond-schema disclosure this dimension rewards.

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 outcome, then the mechanics, then the prerequisite. Every clause earns its place — no restating of the title or schema fields.

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 should ideally state that the tool returns the link string; it says it 'makes a link' but never explicitly names the return value. Everything else an agent needs — privacy model, payer flow, credential requirement, network/asset context — is present, so the gap is minor.

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 per-parameter docs for format, length limits, defaults and enums, so the schema carries the burden. The description only echoes the fields ('address, amount, asset and note') and reinforces that the address is public, adding little beyond what the schema already states. 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 states a specific verb and resource ('Make a link that asks someone to pay your Gloam address') and immediately scopes it as private. No sibling tool creates payment requests, so there is nothing to confuse it with, and the follow-up sentences pin down exactly what artifact is produced.

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 explains what the link does and the flow it triggers, which implies when to use it, but never states an explicit condition or names an alternative (e.g. gloam_plan_deposit or gloam_mpp_how_to). An agent can infer the use case but gets no guidance on when this is the wrong 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 readOnlyHint, idempotentHint, destructiveHint=false, so the safety profile is largely covered. The description adds genuinely new context beyond that: the server never holds funds and never accepts a private key, recovery phrase, or note secret — an important trust boundary an agent should know before calling anything here. It does not describe what the response contains, keeping it below 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?

Two tight sentences with zero filler, front-loaded with the scope statement and the call-to-action, followed by the security caveat. 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 zero-parameter, read-only info tool with no output schema, the description covers the content categories an agent would get back and the trust model. It could say a bit more about the shape of the returned information, but nothing needed to call it 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?

The tool takes no parameters, so per the rubric the baseline is 4. The description correctly implies a zero-input call and there is nothing further to document.

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 content scope — what Gloam is, what the hosted server can do, and where to sign or spend — which is more than a restatement of the title. It doesn't explicitly contrast itself with siblings like gloam_mpp_how_to or gloam_networks, but the orientation framing plus 'Call this first' implicitly separates it as the entry point.

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?

'Call this first' is an explicit, actionable trigger that tells the agent exactly when to invoke it. There is no when-not guidance and no sibling is named as an alternative, so it stops short of full routing instruction, but the sequencing advice is clear.

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 beyond that: it returns code, and a charge settles as a private transfer in a Gloam vault where the chain sees no amount, asset, payer or payee. That privacy/behavioral detail is the main value-add.

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 what the tool does and then the settlement/privacy detail. No filler, though the package name and protocol parenthetical are slightly dense.

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 how-to tool with two fully documented optional parameters and no output schema, the description gives enough to call it correctly and sets expectations about returned code and vault settlement. It is complete without being exhaustive.

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 enums fully described (role: pay/charge/both; network: tempo/robinhood), so the schema carries the parameter burden. The description adds no role or network semantics beyond it, which is the expected baseline 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 specific verb+resource: it is a how-to guide for paying or charging privately over MPP, naming the protocol (HTTP 402) and the package (@gloamtrade/mppx-gloam). This is clearly distinct from action siblings like gloam_create_payment_request or gloam_plan_deposit, though it never explicitly contrasts itself with gloam_info, the nearest documentation sibling.

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 only implied: an agent can infer this is the reference to read before implementing MPP payments, since it returns 'code'. There is no explicit when-to-use / when-not-to-use statement and no routing to alternatives such as gloam_info or gloam_connect_full_agent.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds value by enumerating the returned content (vault addresses, per-chain deposit assets, explorers, RPCs, faucets), but says nothing about auth requirements, freshness, or whether these are live mainnet/testnet values.

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

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

A single front-loaded sentence with no filler, and the most useful content (networks, vault addresses, deposit assets) comes first. It is a dense run-on list, but 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 carries the burden of describing return contents, and it does so explicitly by listing vault addresses, assets, explorers, RPCs and faucets. Missing only chain/environment disambiguation against the info siblings, which is minor for a read-only reference 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% and the single enum parameter already documents both values plus the 'omit for both' behavior. The description never mentions the network filter, so it adds no meaning 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 concrete resource (Gloam's networks) and enumerates the payload: vault/pool addresses, deposit assets per chain, explorers, RPCs, and faucets. An agent knows exactly what this tool returns. It does not, however, distinguish itself from the sibling gloam_info or gloam_vault_stats, which plausibly overlap.

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

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

The description is purely declarative and gives no when-to-use guidance, no exclusions, and never mentions the sibling tools it might be confused with (gloam_info, gloam_vault_stats). The only routing hint ('Leave out for both') lives in the schema, not the description.

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, destructiveHint=false, and idempotentHint=true, so the safety profile is covered; the description adds real value beyond that by clarifying the human-in-the-loop signing flow and stating exactly what the plan comprises. It stops short of describing size/rate limits or output format details, but the key behavioral contract is disclosed.

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?

One dense sentence with a colon-delimited list that front-loads the purpose and ends with the most important caveat about not signing. 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?

With no output schema present, the description carries the return-value burden and does so by naming the three outputs an agent will receive (steps, public/private disclosure, app link). Combined with full schema coverage and annotations, nothing material is missing for correct invocation.

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

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

Schema description coverage is 100%, with defaults and enum values already documented in the schema. The description adds no parameter-specific guidance (e.g., amount formatting or asset resolution nuances) beyond what the schema provides, 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 ('Plan a deposit into a private Gloam balance (a shield)') and immediately enumerates what the plan contains (steps, public/private breakdown, app link). This clearly separates it from siblings like gloam_create_payment_request and gloam_vault_stats without needing 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 scopes the tool's role with 'Does not sign or send anything; you sign in your own wallet in the app,' which tells the agent this is a pre-execution planning step, not a state-changing call. It gives a clear condition for use but does not name a sibling alternative for the actual execution path.

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 readOnly/idempotent/non-destructive, so the bar is lower. The description adds meaningful behavioral context beyond annotations: it discloses data scope ('totals only, no wallets') and caching ('cached about a minute'), which directly affects how an agent should interpret freshness.

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, front-loaded with the core action and resource, then the field enumeration and caching caveat. 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 single-parameter, no-output-schema read tool with annotations covering safety, the description supplies enough: what data is returned, scope limits, and caching. Minor gap is the absence of any hint about output shape, though 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%, so the enum values and 'leave out for both' behavior are already documented in the schema. The description adds no parameter-level 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?

Specific verb+resource: reads public vault totals from chain, enumerating what is returned (holdings, deposit/transfer/cashout/message counts). Distinct from siblings, which are action-oriented (create, deposit, verify). Lacks explicit sibling differentiation but purpose 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?

Usage is implied by the read-only stats framing and the network parameter's 'leave out for both' guidance, but there is no explicit when-to-use or when-not-to-use guidance versus alternatives like gloam_info or gloam_networks.

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, so the safety profile is covered. The description adds real value on top: it enumerates the server-side checks (ZK proof validity, Gloam vault origin, recipient, expiry, live vault state) and reassures that proofs hold no secrets, which informs an agent's handling decisions.

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 accepted proof types; the second sentence covers behavior and the no-secrets caveat. Nothing is padded or redundant.

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 what verification returns, and it never says whether the result is a boolean, a pass/fail report, or the individual check outcomes it just listed. The list of performed checks strongly implies the return content, but the actual response shape is left to inference.

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 parameter and schema coverage is 100%, so the schema already documents the 'proof' string and its prefixes. The description's enumeration of the same four prefixes is useful orientation but adds no syntax or format detail beyond the schema, matching the baseline-3 case.

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 (check/verify) and resource (a Gloam proof), then enumerates the four proof prefixes it accepts (gloamfunds1:, gloampay1:, gloamroll1:, gloamdisc1:). No sibling tool performs verification, so the agent can route here 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 opening 'a Gloam proof someone shared with you' gives clear triggering context, and the reference to gloam.trade/verify anchors the equivalent offline behavior. It does not state any when-not condition or name an alternative tool, but no plausible alternative exists among the siblings.

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