NOMOS Cross-Border Broker

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It mentions caching and cost ('Cached daily — no extra API cost'), which is helpful, but it does not explicitly confirm the operation is read-only, state whether it is destructive, or disclose any rate limits or authentication needs. The description implies a read operation but lacks the explicit safety cues an agent needs to make informed 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?

The description consists of two concise sentences. The first sentence front-loads the core purpose and output, listing regions and result types. The second sentence adds valuable operational context (caching and cost). Every sentence earns its place with no redundancy, making it easy for an agent to quickly grasp the tool's function.

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 that an output schema exists, the description does not need to detail return fields. It covers regions, result types, caching behavior, and cost. However, it lacks information on data freshness beyond 'daily' and does not mention pagination (though limit parameter may suffice). The tool name 'asia' slightly misaligns with included non-Asia regions, but the description corrects this. Overall, it is largely complete but has minor 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 coverage is 100% with descriptions for all three parameters, setting a baseline of 3. The description adds value by explaining that the 'tag' filter corresponds to 'MCP-ready companies, funded entities, compliance signals', which directly maps to the enum values. It also provides regional context. However, it does not elaborate on the 'limit' or 'region' beyond what the schema provides, so the enhancement is moderate.

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

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

The description clearly states the tool provides daily market intelligence from 6 specific regions, listing them explicitly. It specifies the types of entities returned (MCP-ready companies, funded entities, compliance signals), which aligns with the tag parameter enum. The tool is distinct from its siblings, which focus on crossborder preflight, tool discovery, receipt verification, and x402 quotes, so purpose is clear and unambiguous.

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

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

The description does not provide any guidance on when to use this tool versus alternatives. While siblings are in different domains, there is no explicit statement about when this tool is appropriate or when to consider other tools. The absence of usage context leaves the agent to infer applicability solely from the tool name and description, which is insufficient for optimal 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 carry the burden of behavioral disclosure. It describes the action as a check/reference operation and lists output fields, but does not explicitly confirm it is non-destructive (read-only), nor does it mention authentication or rate limits.

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

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

The description is two sentences: one stating the purpose and one listing the outputs. It is direct and efficient with no wasted words.

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

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

Given the parameter count, full schema coverage, and presence of an output schema (though not shown in input), the description provides a good summary of purpose and output. It could be slightly more complete by explicitly stating it is a read-only check.

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 provides full coverage with enums and descriptions for all 3 parameters. The description does not add additional meaning beyond summarizing what the parameters represent, so it meets the baseline of 3.

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 that the tool performs a cross-border regulatory preflight check. It specifies the inputs (jurisdiction pair and data category) and outputs (verdict, blocked_fields, sccs_required, evidence_hash). This is distinct from the sibling tools which are focused on market scanning, tool discovery, receipt verification, and quoting.

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 usage for preflight checks before agent data flows but does not explicitly state when to use or not use this tool compared to siblings. No alternatives or exclusions are mentioned.

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 bears full responsibility. It states the tool discovers tools and returns metadata, but does not explicitly declare it as read-only or detail any side effects. The nature of a search tool is safe but more explicit behavioral traits would be helpful.

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 that front-loads the purpose and lists capabilities, but it could be slightly more structured to align parameters exactly.

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 an output schema present, return values need not be detailed. The description covers purpose and search options adequately, but the mention of 'jurisdiction' without a corresponding parameter creates a gap. Lacks details on pagination or limits.

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 parameters are already described. However, the description introduces 'jurisdiction' as a search dimension, which is not a parameter in the input schema, potentially confusing agents. This reduces clarity beyond what the schema provides.

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

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

The description uses a specific verb ('Discover') and resource ('MCP-compatible tools in the OracleNet mesh'), and lists search dimensions and return fields, clearly distinguishing it from sibling tools like asia_market_scan or crossborder_preflight.

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 usage for finding tools by keyword, category, or jurisdiction, but does not explicitly state when to use this tool over alternatives or provide exclusions, though the context 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?

With no annotations, the description must convey behavioral traits. It states what is returned (verification status, operation details, timestamp, chain position) but does not disclose side effects (read-only assumed but not stated), authentication needs, rate limits, or potential failure modes. This is insufficient for a verification 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 one clear sentence that front-loads the purpose and succinctly lists the return contents. Every phrase earns its place with no 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?

The tool has one simple parameter and an output schema, so the description is adequate but not thorough. It lacks guidance on when verification is appropriate and does not address prerequisites (e.g., need for a previous NOMOS operation). For a straightforward verification, it meets the minimum but has clear 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 coverage is 100% (one parameter fully documented). The description adds 'by hash' which echoes the schema. It does not provide additional semantic context like format constraints or examples, so baseline score of 3 is appropriate.

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

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

The description clearly states the action ('verify') and the resource ('NOMOS signed evidence receipt') with the specific method ('by hash'). This directly matches the tool name and is distinct from sibling tools which are for scanning, preflight, discovery, and quoting.

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 explicit guidance on when to use or avoid this tool is provided. The usage is implied from the description: use when you have a receipt hash to verify. However, no alternatives or prerequisites are mentioned, so it's only minimally adequate.

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 provided, so description carries full burden. It discloses the return fields (payTo address, network, amount in USDC atomic units) and pricing tiers, but does not mention idempotency, authorization needs, or whether it is a read-only operation.

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 purpose and structured with tier details. No unnecessary words; every sentence provides essential 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?

Given output schema exists, description does not need to explain return values, but it already does. It covers pricing tiers and service list implicitly via schema. Minor missing guidance on sequencing (use before other tools).

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

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

Schema coverage is 100% with descriptions, but description adds significant value by providing concrete prices and explaining what each tier includes (e.g., simple verdict vs with evidence), which exceeds the schema's enum labels.

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 it gets a signed x402 payment quote for NOMOS services, listing tiers with specific prices and what each covers. It distinguishes from sibling tools (which are actual service executions) by being the prerequisite for payment.

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 use before other service tools but does not explicitly state when to use vs alternatives, nor provide exclusions. It would benefit from an indication that this should be called before executing services like crossborder_preflight.

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