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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether this operation mutates state, whether it overrides an existing connection, what happens on failure, or whether it is idempotent. 'Connect' hints at a state-changing action but does not explain consequences.

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 concise sentence with no fluff or repetition. It is appropriately front-loaded in that the action is immediately clear, though its brevity comes at the cost of missing behavioral and usage details.

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 this tool has no annotations, no output schema, and only a generic body parameter, the description is too incomplete. An agent would not know what to put in the request body, whether prior authentication is required, or how this tool fits into the broader authentication and merchant workflows suggested by the sibling tools.

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

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

The input schema only defines a generic 'body' object with no specific properties and additionalProperties allowed. Schema description coverage is marked at 100%, so this receives the baseline score of 3, but the description adds no meaningful detail about what the body should contain or how to identify the session and merchant.

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

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

The description states a clear action ('Connect') and a specific resource ('an authenticated session to a merchant'). It is not a tautology and gives an agent a basic sense of the operation, though the word 'Connect' remains somewhat abstract without more context about the HTTP/API semantics.

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 guidance about when to use this tool versus siblings like authentication_initiate, no mention of preconditions such as having an authenticated session or a merchant ID, and no hint about whether this should be called before or after other authentication steps.

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 of behavioral disclosure. 'Start authentication' does not state side effects, return behavior, session implications, or required credentials. It is too minimal to be transparent about what the tool does beyond its literal name.

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 to the point of being under-specified. It is not padded with redundant text, but it fails to earn its place because it offers no useful information beyond the tool name. A description of this length is under-specification, not effective conciseness.

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 one opaque body parameter, no output schema, and a sibling named authentication_connect, the description is far too incomplete. An agent cannot know what fields to send, what the response will be, or how this step fits into the larger authentication flow. This is a substantial gap for a tool that initiates a process.

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 describes the only parameter as 'JSON request body', which gives the parameter a name and type but no structural detail. Since schema description coverage is 100%, the baseline is 3; however, the tool description itself adds no meaning about what the body should contain or how authentication initiation is configured.

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

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

The description is essentially a paraphrase of the tool name: 'Start authentication' restates 'authentication_initiate' without specifying what starting authentication entails, what resource is affected, or how it differs from the sibling authentication_connect. It lacks enough substance for an agent to know what this tool actually 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?

There is no guidance about when to use this tool versus authentication_connect or other siblings. No context, prerequisites, or exclusions are provided. The bare phrase 'Start authentication' leaves the agent to guess whether this is the correct 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Create a card' only conveys that this is a mutating operation; it says nothing about required permissions, side effects, idempotency, validation behavior, or error conditions. This is insufficient for a creation 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 extremely short and has no wasted words, which is structurally clean. However, it is under-specified to the point of being barely more useful than the tool name itself, so it does not fully earn its place as an explanatory definition.

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

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

For a mutation tool with no annotations, no output schema, and a generic JSON-body parameter, the one-sentence description is not complete. An agent needs information about the expected request shape, preconditions, and consequences 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?

Although schema coverage is reported as 100%, the only parameter is an opaque 'body' object with additionalProperties allowed, so the schema does not define card fields. The description also gives no guidance on what the request body should contain, leaving an agent unable to construct a valid payload.

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 operation ('Create') and resource ('a card'), so an agent can identify what the tool does. It is not vague, and the sibling tool card_details signals a different action. However, the description adds no scope details and does not actively distinguish it from the other create tools in the sibling list.

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 guidance on when to use this tool versus alternatives such as request, wallet_create, or collection_initiate. It does not mention prerequisites like requiring an existing user, wallet, or authentication session, so an agent must infer the appropriate call context entirely from the tool name.

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 of behavioral disclosure. The word 'fetch' implies a non-destructive read, but the description omits any context about authentication, rate limits, required prior state, or how errors and responses behave. This is minimal behavioral transparency.

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

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

The description is a single short sentence with no filler. It is front-loaded, easy to parse, and contains nothing that needs to be reorganized or trimmed.

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 one flexible body parameter, no output schema, and no annotations, this description is too thin. It fails to explain how the caller specifies which card to look up, what response shape to expect, or how this tool relates to card_create and similar sibling tools. An agent would likely need external documentation or examples to call 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 only parameter, 'body', is described in the schema only as 'JSON request body' with any properties allowed, which gives an agent no concrete guidance on what to send. The tool description adds no parameter meaning, such as which card identifier or fields the body should contain.

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

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

The description names a specific action and resource: 'Fetch card details.' This clearly identifies it as a read operation for a card, and it distinguishes itself from card_create and wallet_details at a basic level. However, it does not elaborate on what 'details' include or explicitly differentiate itself from other sibling tools.

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

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

There is no guidance on when to use this tool rather than card_create, wallet_details, or the generic request tool. It also does not mention prerequisites such as whether a card must already exist before details can be fetched.

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 present, so the description must carry the behavioral disclosure burden. 'Get' weakly implies a read-only operation, but the description does not state whether authentication is needed, whether any side effects occur, what the response contains, or how errors manifest. The read implication is inherent to the verb and adds little beyond it.

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 short sentence, which could be concise, but it is under-specified: it uses no meaningful space to convey tool behavior or parameters. The brevity provides no informational value beyond the tool name.

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

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

With no annotations, no output schema, and a nested 'body' parameter that is entirely undisclosed, the descripion is gravely insufficient. An agent cannot determine what to send, what to expect back, or how this tool fits into a workflow. This is completeley inadequate for even 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 single parameter 'body' is documented only as 'JSON request body' with additionalProperties allowed, which conveys nothing about required fields, structure, or format. The schema description coverage is 100% only because the sole property's description is trivially generic. The tool description adds no parameter meaning, so an agent cannot construct a valid request body.

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 'Get collection order info' has a clear verb ('Get') and resource, but 'info' is undefined and the term 'collection order' is never explained. It does not differentiate from siblings like collection_initiate, wallet_transactions, or request, leaving an agent unable to know what this tool uniquely retrieves.

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 guidance on when to use this tool versus alternatives. No mention of prerequisites, required context (e.g., an existing collection ID), or exclusions. The description provides no framing for selection.

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 present, so the description must carry full behavioral disclosure. It implies a mutating action ('initiate') but does not state side effects, idempotency, authorization needs, or whether the order is created synchronously or asynchronously. This is a significant gap for a mutation 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 a single short sentence with no fluff, but it is under-specified rather than effectively concise. Critical operational details are absent, so the brevity hurts usability instead of enhancing clarity.

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

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

Given a generic body parameter, no output schema, and no annotations, the description must explain what a collection order is, what data to send, and what response to expect. It provides none of that, making the tool effectively uncallable without external knowledge.

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 describes the only parameter as 'JSON request body' with additionalProperties allowed, offering no structural detail. The description contributes no parameter information, so an agent cannot determine what fields belong in the body. Although schema coverage is 100%, the coverage is boilerplate, and the description fails to compensate.

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 ('Initiate') and a resource ('collection order'), making the core action clear. It is not a tautology and can be differentiated from the read-oriented sibling 'collection_info' by the action word, though it does not explicitly compare itself to other action tools like 'transfer_direct'.

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 guidance on when to use this tool, when not to, or which sibling to prefer. The description mentions no alternatives or conditions, leaving the agent to infer usage solely from the name.

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 of behavioral disclosure. 'List countries' implies a read-only operation, but it does not state whether output is paginated, sorted, filtered, or what the response shape is.

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 extremely concise and front-loaded, with no wasted words. It is appropriately sized for a simple listing tool, though it is terse enough that it misses some helpful behavioral context.

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 there is no output schema and no annotations, the description does not fully explain what the caller should expect. An agent can infer that it returns countries, but not whether they are names, codes, objects, or how many results are returned.

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 already documents the single body parameter as 'JSON request body', so schema coverage is high. The description adds no additional meaning about how or whether this body should be used, but it does not need to compensate much because there is only one optional 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 states a clear action and resource: 'List countries.' It is specific enough to distinguish this tool from siblings like wallet_create or transfer_direct, and there is no competing country-listing tool in the sibling list. However, it does not elaborate on what kind of country data is returned.

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 guidance about when to use this tool versus alternatives, nor any exclusions or prerequisites. The usage context is only implied by the name and 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?

No annotations are provided, so the description carries the full burden. 'List job types' implies a read-only operation, but it does not disclose response format, pagination, authorization needs, or whether the optional body affects behavior.

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

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

The description is front-loaded and free of fluff, which is positive. But it is borderline under-specified: a single three-word sentence provides no structural context beyond the bare operation.

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

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

For a tool with one optional body parameter and no output schema, the description is too lean. It does not explain the request body semantics, return shape, or any invocation notes, so an agent can select the tool but cannot confidently construct a request.

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% (the single 'body' parameter has a description), so the baseline is 3. However, the description adds no information about what the body should contain, and 'JSON request body' is generic.

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 a clear resource ('job types'), so an agent understands the core operation. It does not compare against sibling list tools like list_endpoints or countries, so it lacks explicit sibling differentiation.

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 guidance on when to use this tool versus alternatives, nor any mention of exclusions or context. An agent must infer usage entirely from the minimal 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?

No annotations are provided, so the description carries the burden. The verb 'List' implies a read-only operation with no side effects, but the description does not explicitly state that, nor does it mention response format, pagination, or authentication 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 with no filler. The core action is front-loaded, and the filter guidance is immediately actionable.

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, optional-parameter discovery tool, the description plus full schema coverage is sufficient to select and invoke it. The only gap is that no output schema or return-format hint is provided, but that is a minor omission for a listing operation.

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

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

Schema coverage is 100%, so query and folder are already documented. The description adds value by naming concrete folder values (Wallet, User, Card, Verification, Omnichain), which helps an agent construct meaningful filters beyond the generic schema text.

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

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

The description opens with a specific verb and resource: 'List MoiPayWay API collection endpoints'. It clearly distinguishes this as an introspection/discovery tool from the sibling tools, which are concrete operations like wallet_create or transfer_direct. The folder examples further clarify 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 this tool is used to discover/filter API endpoints, and it gives usable filter examples. However, it does not explicitly state when to prefer this over siblings such as request, nor does it explain the intended workflow 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?

No annotations are provided, so the description carries the full burden for behavioral disclosure. It does not state whether this tool can issue writes (POST) or modifications to external financial systems, what error behavior looks like, whether authentication is required, or what the response format is. For a financial API tool, this is a meaningful gap.

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

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

Two sentences, zero filler. The core instruction and the discovery pointer are both useful and efficiently stated. Every word earns its place.

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

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

For a generic passthrough tool, the description could state what the agent will get back (response shape), whether this tool performs writes, and which paths are valid. The output schema is absent, so the description should have explained return values. It also does not mention that the tool might be unsafe without authentication/permission. Moderate gap for a financial API.

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 high (path and method are documented; body has a minimal generic description). The description adds minimal context but the schema already explains the parameters adequately, including the default behavior for method ('Defaults to the collection method for this path'), which is valuable semantic information beyond the enum itself.

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 ('Call'), resource ('MoiPayWay API collection endpoint'), and mechanism ('by path'). It distinguishes the tool as a low-level HTTP request wrapper rather than a semantic operation, and explicitly points to list_endpoints for discovery, which mitigates sibling ambiguity.

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

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

The description clearly implies when to use this tool: when an agent knows the collection path and needs to execute it. It references list_endpoints as the discovery mechanism, which provides some routing guidance, though it does not explicitly exclude higher-level semantic tools or describe when a semantically-named operation would be preferable.

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 of disclosing behavior, but it only says 'send' — implying a side effect without stating whether the transfer is irreversible, requires authorization, has fees, or returns a confirmation. This is a material gap for a financial 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 sentence is short and front-loaded, but it is under-specified rather than efficiently complete. One clause cannot carry the structural guidance needed for a transfer operation with an opaque request body.

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?

This is a complex financial action with no annotations, no output schema, and an open-ended body parameter. The one-sentence description is far too thin for an agent to know the payload shape, required fields, side effects, or expected response, so correct invocation would require guessing.

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 single parameter 'body' is described in the schema as 'JSON request body' (100% coverage), so the 3 baseline applies. However, the body is free-form with additionalProperties allowed, and the tool description adds no hints about required fields such as amount, destination, or currency.

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

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

The description identifies a clear verb and object ('Send a direct single transfer'), so it is not a tautology, but the modifiers 'direct' and 'single' are not explained and no context is given for what kind of transfer this is. It also does not distinguish the tool from the generic sibling 'request' or other wallet/transfer-related operations.

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

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

No when-to-use or when-not-to-use guidance is present, and no alternative tools are named. An agent cannot tell from the description why it would choose transfer_direct over siblings such as 'request', 'wallet_transactions', or 'collection_initiate'.

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 of behavioral disclosure, but it only says the tool creates a business user. It does not mention side effects, permissions, validation behavior, idempotency, or failure modes.

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 clear sentence with no filler or redundancy. It is appropriately front-loaded, though the brevity comes at the cost of operational detail.

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 an opaque free-form body parameter, no annotations, and no output schema, the one-line description is not enough for an agent to invoke the tool correctly. It communicates intent but leaves the actual request construction undocumented.

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 only defines a free-form 'body' object described as 'JSON request body,' and the description adds no field-level meaning. An agent cannot determine what properties are required or expected to create a business user.

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 a business user.' The business/individual distinction visible in sibling tool names helps differentiate it from user_individual_create, though the description itself does not explicitly call out that contrast.

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

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

No guidance is provided on when to use this tool versus alternatives like user_individual_create. The agent must rely on the tool name and sibling list to infer context, which is not sufficient for confident selection.

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 must disclose behavior. It only restates that this creates an individual user, which is already implied by the tool name. It does not mention required permissions, idempotency, side effects, response behavior, or what data must be supplied.

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, front-loaded sentence with no wasted words. It is appropriately concise for stating the core purpose, though it could have added more guidance without becoming bloated.

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 an opaque object body, no output schema, no annotations, and a list of related sibling tools, the description is too minimal. An agent cannot determine what fields are needed, what the API expects, or even what successful creation returns.

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 describes the sole parameter as 'JSON request body' and coverage is high, so the baseline is 3. The description adds no field-level meaning about what the body should contain or which properties are expected, but it also does not contradict or obscure the schema.

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

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

The description states the action ('Create') and the resource ('an individual user') clearly. It also implicitly distinguishes this from the sibling tool user_business_create, though it does not explicitly contrast 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 word 'individual' implies this tool is for individual users rather than business users, but there is no explicit guidance about when to choose it over alternatives or what conditions apply. The usage context is only implied.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only offers the read-implying verb 'fetch.' It does not disclose error behavior (e.g., 404 when user not found), authentication requirements, or response shape. Minimal behavioral context.

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

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

The four-word description is under-specified rather than appropriately concise. It is short but leaves critical information—parameter format, output, usage context—entirely unaddressed.

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 opaque free-form body parameter, no annotations, and no output schema, the description is inadequate. An agent cannot determine what to place in the body to fetch the right user, making correct invocation impossible without external knowledge.

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 sole parameter 'body' is described only as 'JSON request body,' which is a tautology that adds no meaning. With additionalProperties open and no required fields, an agent has zero guidance on what identifier or fields to include (e.g., user ID). The description does not compensate for this opacity.

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 'Fetch an individual user' uses a specific verb ('fetch') and resource ('user'), making the core action clear. It also differentiates from sibling creation tools (user_individual_create, user_business_create) through the verb contrast, though it does not explicitly distinguish itself from any potential 'details' 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?

No guidance is provided on when to use this tool versus alternatives, nor any prerequisites (e.g., user must exist, needs an ID). The description simply states the action without contextualizing it among the sibling tools.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether this is read-only, whether authentication or prior steps are required, what side effects occur, or how results are returned. The description adds no behavioral transparency beyond the tool's name.

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

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

The description is short, but this is under-specification rather than useful conciseness. The single sentence merely restates the tool name and does not earn its place because it conveys no actionable information.

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

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

For a tool with no annotations, no output schema, one opaque free-form body parameter, and many sibling tools, a one-line restatement is far from complete. An agent lacks enough context to construct a valid request or interpret the result.

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

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

The input schema has one top-level 'body' object, and the schema describes it as 'JSON request body' with additionalProperties allowed. Schema description coverage is 100% at the top level, so the baseline is 3, but the nested request structure is completely undefined and the description adds no parameter meaning.

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

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

The description is essentially a tautology: 'Run a verification lookup' restates the tool name 'verification_lookup' with no indication of what verification means, what entity is being looked up, or how this differs from siblings like verify_webhook. An agent cannot tell what this tool actually 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 provides no guidance on when to use this tool versus alternatives. There are no usage conditions, prerequisites, or comparisons to sibling tools, so an agent cannot decide when verification_lookup is the correct choice.

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 present, so the description should disclose behavioral traits such as whether verification is read-only, what happens on invalid signatures, or what is returned. It only says 'Verify', offering no detail on algorithm, error behavior, or side effects.

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?

Single sentence, front-loaded verb, zero fluff. It is concise, though slightly terse for a security-sensitive verification tool; no structure issue, but a bit more context would make it appropriately sized.

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

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

No annotations and no output schema, yet the description does not explain expected return/outcome, failure behavior, or verification semantics. For a tool that likely gates business logic, an agent cannot confidently interpret the result of invoking it.

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

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

Schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds no semantic detail beyond what the schema already states; it does not harm or compensate.

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

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

Description uses specific verb 'Verify' and specific resource 'MoiPayWay webhook signature', clearly stating exactly what the tool does. Among siblings, no other tool targets webhook signature verification, so it stands apart even without explicit comparison.

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

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

No guidance on when to invoke this versus alternatives or what prerequisites apply. While it implies use after receiving a MoiPayWay webhook, that is only the tool's definition, not explicit usage context; no exclusions or alternative routing are provided.

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 of behavioral disclosure. 'Create a wallet' implies a mutating operation but does not disclose side effects, required permissions, idempotency, or response behavior. This is a significant transparency gap for a creation 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 a single, front-loaded sentence with zero filler or redundant content. It is efficient, though it errs on the side of being too minimal to provide substantive guidance.

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?

This is a mutating tool with no annotations, no output schema, and a generic open-ended body parameter. The description leaves the agent without information about required wallet fields, response format, or prerequisites. More context is needed for an agent to invoke this 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?

The single 'body' parameter is documented in the schema as 'JSON request body' with additionalProperties allowed, so schema coverage is effectively 100%. The description adds no field-level meaning, but the high schema coverage sets the baseline at 3; no compensation is required.

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

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

The description states a clear verb and resource — 'Create a wallet' — which tells the agent what the tool does. It is distinguishable from sibling tools like wallet_details and wallet_transactions by the action verb. However, it adds no detail beyond the tool name itself, so it stops short of the richest possible purpose clarity.

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 guidance about when to use this tool versus alternatives such as the generic 'request' tool or collection/transfer tools. The description provides no context, prerequisites, or exclusions, leaving the agent to infer usage entirely from the tool name.

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?

There are no annotations, so the description carries the full burden of behavioral disclosure. 'Fetch' implies a read operation, but the description does not disclose authentication needs, response format, error behavior, or whether any state changes occur.

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, front-loaded sentence with no filler or redundant wording. It is concise, though the brevity contributes to the overall lack of useful detail.

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 annotations, no output schema, and an opaque body parameter, the description is insufficient for an agent to know how to identify the wallet or what details will be returned. The presence of several wallet-related siblings makes the missing disambiguation more costly.

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% for the single 'body' parameter, so the baseline is 3. However, the schema only describes it as a 'JSON request body' with additionalProperties allowed, and the description adds no further meaning about how to construct or use the body.

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 ('Fetch wallet details'), so it is not a tautology. However, it is generic and does not distinguish what 'wallet details' includes versus related sibling tools like wallet_transactions or wallet_create.

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

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

No usage guidance is provided. The description does not indicate when to use this tool instead of wallet_transactions, wallet_create, or other sibling tools, nor does it mention any prerequisites or filtering 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?

No annotations are provided, and the description only says 'List wallet transactions.' It does not disclose whether results are paginated, what the response format is, whether authentication is required, or what side effects (if any) exist beyond listing.

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 extremely concise and front-loaded with the core action and resource. No wasted words, though it is so brief that it borders on under-specification.

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 annotations, no output schema, and an open-ended request body parameter, the description fails to give an agent enough context to construct a correct invocation. It does not explain what body fields are accepted, how responses are structured, or whether the endpoint requires any specific setup.

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% because the only parameter 'body' has a description ('JSON request body'), but that description is generic and unhelpful. The description adds no additional meaning about what fields or structure the body should have, though it benefits from the baseline because the schema does document the parameter exists.

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

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

The description states a clear verb and resource: 'List wallet transactions.' It distinguishes itself from siblings like wallet_create and wallet_details by indicating a read operation focused on transactions rather than wallet management or creation.

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 guidance on when to use this tool versus alternatives such as wallet_details or collection_info. The description does not specify intended use cases, prerequisites, or exclusions.

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