Sputnik X: EU trade 63M+, LV customs, salary, sanctions, EU AI Act, SoulLedger + x402 USDC.
Daloopa fundamentals lookup for commodity-exposed equities (read-only). Returns per-ticker structured fundamentals (revenue, opex, segment splits) sourced from issuer filings. Configure DALOOPA_API_URL + DALOOPA_API_KEY in .env; otherwise pass test_mode=true to receive deterministic mock fixtures suitable for CI and demos. No mutation — fail-open with mock if upstream is unreachable.
| Name | Required | Description | Default |
|---|---|---|---|
| metric | No | Optional metric filter (e.g. "revenue", "segment_revenue", "opex"). Omit to return all available metrics. | |
| ticker | Yes | Equity ticker symbol (e.g. "CLF", "X", "FCX"). 1..16 chars, uppercase recommended. | |
| periods | No | How many fiscal periods to return (default 4, max 20). | |
| test_mode | No | When true, return deterministic mock fixtures and skip the external API call entirely. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so well. It discloses read-only behavior, no mutation, fail-open behavior with mock fixtures when upstream is unreachable, deterministic test-mode output, and the underlying data source. This gives an agent an unusually complete safety and failure-mode picture.
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 compact and front-loaded, with the core purpose in the first sentence. The following sentences each carry useful operational information. There is minor redundancy between 'read-only' and 'No mutation,' but it is not distracting.
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 4-parameter, no-output-schema, no-annotation tool, the description covers purpose, data source, configuration, test mode, and failure behavior. It does not detail the exact shape or units of returned fundamentals, but the mention of revenue, opex, and segment splits gives an agent enough expectation to invoke and interpret the result reasonably.
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 already documents all four parameters with 100% coverage, so the baseline is 3. The description adds mild context for ticker and metric via 'per-ticker structured fundamentals' and example metrics, and it reinforces test_mode's purpose for CI/demos, but it does not add substantial new semantic meaning beyond 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 opens with a specific verb and resource: 'Daloopa fundamentals lookup for commodity-exposed equities.' It immediately clarifies the return payload ('per-ticker structured fundamentals') and the data source ('issuer filings'), which distinguishes it from sibling price/news 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?
The intended use case is clear: retrieve fundamentals for commodity-exposed equities. It also gives actionable setup guidance with concrete alternatives ('Configure DALOOPA_API_URL + DALOOPA_API_KEY... otherwise pass test_mode=true'), and explicitly marks the operation as read-only. It does not name alternative sibling tools, but none appear to be close substitutes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Top-5 front-running signals (policy event + trade spike 30d prior). Updated weekly Mon 07:00 UTC. Returns signal_id, policy_date, hs_code, spike_multiple, confidence. FREE (lead magnet, public — signals delayed 7 days from detection).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max signals to return (default: 5, max: 50) | |
| since | No | Filter signals on/after date, YYYYMMDD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full transparency burden. It discloses the update schedule, public access, and delayed signals, and enumerates the returned fields, which is solid behavioral disclosure. It doesn't mention rate limits or explicitly say it's read-only, but the operation is clearly a query.
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 dense sentences, each contributing new information: what the signals are, when they refresh, and what payload/access conditions to expect. 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 or annotations, the description still covers key returned fields, access conditions, and freshness, which an agent needs for decision-making. It doesn't clarify sorting when limit > 5 or field interpretation, but those are minor for selecting and invoking the 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 coverage is 100%, so the schema already fully documents limit and since parameters. The description adds no parameter-level semantics beyond implying default top-5 selection; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description identifies tool as providing top-5 front-running signals and explains the signal criteria (policy event + trade spike 30 days prior). It clearly states the resource and context but does not explicitly differentiate from sibling tools like wave_portfolio or wave_signal.
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?
States update cadence (weekly Mon 07:00 UTC) and public/free access with a 7-day delay, giving an agent clear context on data freshness and availability. No explicit 'use instead of X' guidance or exclusion conditions, but the context is enough to infer when to call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available Fusion Engine data sources, dimensions, metrics, and operations. Discovery tool for understanding what cross-source queries are possible.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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. It clearly indicates a read-only listing operation ('List all'), but it does not describe the output format, size limits, or any prerequisites. This is minimally sufficient but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The first names the action and scope, and the second adds the discovery purpose. Every clause contributes useful decision 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 zero-parameter discovery list, the description covers what it lists and why to use it. It does not specify the return structure, but for a capabilities endpoint this is largely inferable. It is complete enough for correct invocation while leaving minor room for extra detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description cannot add parameter-level meaning. The baseline for zero-parameter tools is 4, and the description appropriately focuses on what the tool returns rather than input configuration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and names the exact resources covered ('Fusion Engine data sources, dimensions, metrics, and operations'). It also identifies itself as a 'Discovery tool', making its introspective role clear and distinguishing it from the sibling query/action 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?
The phrase 'Discovery tool for understanding what cross-source queries are possible' gives clear context for when to use it: before constructing cross-source queries. However, it does not explicitly state when not to use it or name alternative tools, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current product prices with calculated price_per_kg. Returns EUR pricing for all in-stock products.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Tenant slug | |
| product_slug | No | Specific product slug (optional — omit for all) | |
| response_format | No | Response detail level: "concise" (default, key fields only) or "detailed" (all fields) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden and does disclose key behaviors: it returns only in-stock products, prices are in EUR, and price_per_kg is calculated. It does not explicitly state read-only behavior, but 'Get' strongly implies it, and no side effects are implied.
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, tight sentence with no filler. It front-loads the action and immediately specifies the output characteristics, every word earning 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 simple read with no output schema, the description explains the return scope (all in-stock products), currency (EUR), and computed field (price_per_kg). It does not spell out the exact response structure or default response_format behavior, but the schema covers those; this is adequate.
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 all three parameters (slug, product_slug, response_format), so the schema fully documents parameter meaning. The description adds no extra parameter-level detail, thus 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 description uses the specific verb 'Get' with resource 'current product prices', adding scope ('all in-stock products'), currency ('EUR'), and a calculated field ('price_per_kg'). This clearly differentiates it from siblings like search_products, which focuses on product search rather than price retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when current product prices are needed) but provides no explicit when-not-to-use guidance or reference to alternatives. Sibling tools such as search_products could be relevant, yet no routing or exclusion is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
MT Newswires commodity headlines (read-only). Pulls the configured RSS or JSON feed (MT_NEWSWIRES_RSS_URL / MT_NEWSWIRES_API_URL), parses up to limit items, and returns {title, pubDate, link, summary, source}. Use as a low-latency news ticker for commodity-trader agents. Pass test_mode=true for deterministic mock fixtures; the tool auto-falls back to mocks if the feed is unreachable.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max headlines to return (default 10, max 50). | |
| since | No | Optional ISO 8601 cutoff (e.g. "2026-05-16T00:00:00Z"). Only items with pubDate >= since are returned. | |
| topic | No | Optional case-insensitive keyword filter applied to title+summary (e.g. "oil", "copper", "wheat"). Omit for unfiltered feed. | |
| test_mode | No | When true, return deterministic mock fixtures and skip the external feed entirely. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it delivers: it discloses read-only behavior, feed configuration, item limit handling, return fields, test_mode mocking, and automatic fallback to mocks when the feed is unreachable. This is strong behavioral coverage for a simple query 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 compact and front-loaded: it states what the resource is, what the tool does, what it returns, and when to use it. No sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, behavior, return shape, use case, and failure/mock behavior. With 100% schema description coverage for parameters, the absence of extra parameter detail is not a gap, and there is no output schema to compensate for, yet the return fields are explicitly listed.
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 each parameter already has a useful description, so the baseline is 3. The tool description adds no meaningful extra semantics for since or topic, and only restates limit and test_mode behavior already present in 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 clearly identifies the tool as an MT Newswires commodity headline reader, with a specific verb (pulls/parses/returns) and a concrete output shape. It does not explicitly contrast with sibling tools, but the resource and scope are 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 gives a clear usage context: 'Use as a low-latency news ticker for commodity-trader agents.' It does not mention exclusions or alternatives, so it falls just short of fully explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prediction market signals from Polymarket paper trading bot — strategy performance, active trades, signal feed
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | View type: stats (strategy performance), trades (recent trades), prediction (active signals) | |
| limit | No | Max results for trades view (default: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the burden of behavioral disclosure. It indicates this is a data/signal feed from a paper trading bot and lists output categories, which implies a read-oriented monitoring tool. It does not explicitly state read-only behavior, freshness, pagination, or whether any side effects occur, so some gaps remain.
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, tightly written sentence with no filler. It front-loades the key domain and source, then uses an em dash to enumerate the main output categories. 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 simple tool with two optional parameters and no output schema, the description plus schema provide sufficient context to select and invoke correctly. The enum view values align well with the output categories. A small gap is the lack of stated default behavior when 'view' is omitted, and no explicit mention of read-only safety, but overall it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both parameters: 'view' has an enum with explanatory descriptions, and 'limit' states max results and default. The description adds no parameter-level detail, but because schema coverage is 100%, the baseline 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 identifies the resource—prediction market signals from a Polymarket paper trading bot—and names the content categories (strategy performance, active trades, signal feed). It lacks a specific verb like 'retrieve' or 'list', and it does not explicitly contrast with sibling tools, though the domain specificity makes its purpose clear.
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: an agent would call this tool to inspect Polymarket paper trading strategy stats, recent trades, or active signals. However, the description does not explicitly state when to prefer this over sibling tools or provide any exclusions, leaving some inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search products in a tenant catalog. Returns safe columns only (no cost_price/markup). Filter by type, category, name, or in_stock status.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Tenant slug | |
| type | No | Product type filter (e.g., granulas, briketes, saplaksnis) | |
| limit | No | Max results (default: 50, max: 100) | |
| search | No | Search text (matches name, type, category) | |
| in_stock_only | No | Only show in-stock products (default: true) | |
| response_format | No | Response detail level: "concise" (default, key fields only) or "detailed" (all fields) |
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. It explicitly warns that the tool returns only safe columns, excluding cost_price/markup, which is valuable behavioral context beyond what the schema offers. It does not mention other behaviors like response format or pagination, but the safe-column disclosure is a strong transparency signal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero filler. The main purpose and the critical safe-column caveat are front-loaded, followed by a concise list of filter dimensions. 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?
Given the moderate complexity (6 params, no output schema) and 100% schema coverage, the description is largely complete. It covers what the tool does, what it returns (and excludes), and how to narrow results. The only minor gap is no explicit guidance on when not to use it, but the safe-column note and sibling context partially cover this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all six parameters effectively. The description's mention of filters ('by type, category, name, or in_stock status') adds a compact summary but no new semantic detail beyond what each parameter description already states.
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 ('Search') and resource ('products in a tenant catalog'), making the tool's purpose immediately clear. It also distinguishes itself from siblings like get_prices by noting it returns safe columns only, which prevents confusing it with price-related 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?
The description clearly states the context: searching products within a tenant catalog with filters by type, category, name, or in-stock status. It does not explicitly name alternatives or exclusions, but the context is sufficiently clear for an agent to decide when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse open agent bounties — tasks with USDC rewards that agents can claim and complete
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default: 20) | |
| status | No | Bounty status filter (open, awarded, expired) |
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. 'Browse' implies a read-only operation, but the description does not clarify default behavior (e.g., whether all statuses are returned or only open ones), and the phrase 'open agent bounties' conflicts somewhat with the schema's broader status options. It also does not mention sorting, pagination, or claim mechanics.
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, well-structured sentence that is front-loaded with the primary action and resource, followed by the reward context. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description conveys the core purpose and reward mechanism but omits the important nuance that the `status` filter allows viewing awarded and expired bounties, not just open ones. Given the absence of an output schema, the description also does not mention what fields each bounty result will contain, which could be relevant for an agent deciding whether to call the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both `limit` and `status`. The description adds no parameter-specific meaning beyond what the schema already provides, which aligns with 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 uses a specific verb ('Browse') and resource ('agent bounties'), and adds useful context that these are tasks with USDC rewards. However, the word 'open' ambiguously suggests only open-status bounties, while the schema allows filtering by awarded and expired statuses, creating mild potential for misinterpretation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a general sense that this tool is for browsing bounties, but it provides no guidance on when to use this tool versus alternatives, no exclusions, and no mention of how the status filter could be used. No sibling differentiation or selection conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse marketplace insights from AI agents — analysis findings available for purchase
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default: 20, max: 100) | |
| category | No | Filter by insight category (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. It indicates these are analysis findings 'available for purchase', implying a commercial transaction, but does not disclose whether calling the tool triggers a purchase, requires payment, returns only metadata, or has any side effects. For a tool involving commerce, this is a significant transparency 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?
The description is a single, concise sentence with no fluff. It front-loads the primary verb and resource, and includes the key commercial aspect ('available for purchase'). It earns its place, though it could be slightly more structured by breaking out the purchase condition.
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 is a marketplace tool with commercial implications, the description should clarify whether browsing is free, what happens when purchasing, and what the output looks like (especially with no output schema). The absence of any guidance on the purchase flow or result format leaves an agent uncertain about side effects and follow-up actions.
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 both 'limit' and 'category' are already documented with their types and constraints. The description adds no meaning beyond what the schema provides; it doesn't clarify valid category values or how category interacts with the results. Baseline 3 is appropriate since the schema does the heavy lifting.
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 clear verb ('Browse') and resource ('marketplace insights'), and mentions they are for purchase. It distinguishes the tool as a marketplace listing/browsing operation, but doesn't explicitly contrast with siblings like search_products or soul_bounties, so it's clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Browse marketplace insights' implies a read-only listing use case, and the category filter parameter suggests browsing by category. However, there is no explicit guidance on when to use this vs. a search tool like search_products, nor any mention of purchase flow prerequisites or auth requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Agent trust leaderboard — ranked by trust score with DNA summaries
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max agents to return (default: 10, max: 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full behavioral burden. It does add useful traits by stating the output is ranked by trust score and includes DNA summaries, but it omits the scope of ranked agents, data freshness, and whether the operation is read-only.
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 11-word sentence with no filler; the key discriminator, trust leaderboard, is front-loaded and 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 low-complexity tool with one optional parameter and no nested objects, the description adequately conveys what is returned. However, with no output schema and no annotations, the agent universe and the meaning of DNA summaries remain unstated, leaving some room for improvement.
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% for the single optional limit parameter, including its default (10) and max (50) values. The description adds no additional parameter-level meaning, so the baseline of 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 description identifies a specific resource (an agent trust leaderboard) and specifies its ordering (by trust score) and content (DNA summaries). It is clearly distinct from sibling tools like soul_profile and soul_verify, though it relies on a noun phrase rather than an explicit verb such as retrieve.
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 is given on when to use this tool versus alternatives, and no sibling tools are named for comparison. The intended use case is only implied by the phrase agent trust leaderboard, so an agent must infer when this is the right choice among the many soul_* siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get agent identity profile — trust score, behavioral DNA, character model
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | Agent identifier (e.g., oracle, spider, strategist) |
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. 'Get' implies read-only behavior, but the description does not disclose error behavior, unknown agent_id handling, access requirements, or whether the profile reflects the current agent or any agent. It only lists the returned fields.
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 wasted words. It states the action, resource, and key output fields efficiently, and every phrase contributes meaning.
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 simple getter with one fully documented parameter and no output schema, so the description's enumeration of the returned profile components (trust score, behavioral DNA, character model) is reasonably complete for invocation. It could go further by explaining value types or ranges, but for its low complexity the coverage is solid.
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 parameter includes useful examples ('oracle, spider, strategist'). The description adds little beyond the schema, but the schema already sufficiently explains the agent_id parameter, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('agent identity profile'), and it names the contained fields (trust score, behavioral DNA, character model), making the purpose clear. It does not explicitly differentiate from sibling tools like soul_insights or soul_verify, but the resource is specific enough to be distinct.
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 its siblings, no explicit prerequisites, and no stated exclusions. The verb 'Get' implies a read operation, but the description does not help an agent choose between soul_profile and other soul_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse the SoulLedger Stack feed — published insights from AI agents with trust scores and trending ranking
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default: 20, max: 50) | |
| agent_id | No | Filter by specific agent | |
| category | No | Filter by category (revenue, risk, supply_chain, trade, general) | |
| trending | No | Use trending algorithm instead of chronological (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. 'Browse' implies a read-only operation, and the mention of trust scores and trending ranking gives some idea of what results contain. However, it does not disclose ordering defaults, pagination behavior, or whether results are limited in any way.
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 that efficiently communicates the resource, content type, and key distinguishing features. 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?
For a tool with four optional parameters and no required fields, the description plus schema is adequate for basic invocation. However, there is no output schema and no explanation of how 'trust scores' are presented or how this feed relates to other soul_* tools, which leaves some situational ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters are already fully described in the input schema. The description adds no extra parameter-level meaning beyond framing the feed context, which is the baseline expectation.
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 ('Browse') and resource ('SoulLedger Stack feed'), and adds distinguishing detail about trust scores and trending ranking. It clearly indicates this is a read-oriented feed of published agent insights, though it doesn't explicitly contrast with closely related soul_* 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?
The description implies this is the tool for browsing the feed, but provides no explicit guidance on when to choose it over siblings like soul_insights, soul_leaderboard, or soul_profile. There are no usage conditions, exclusions, or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify agent's hash chain integrity — cryptographic proof of untampered history
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | Agent identifier to verify |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It implies a read-only verification but does not state side effects, required permissions, failure behavior, or what the response actually contains beyond the vague 'cryptographic proof'.
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 front-loaded sentence stating the action and its significance, with no filler or redundant clauses. 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?
The tool is simple with one required parameter, but the description does not state output format, when to prefer this over sibling soul_* tools, or what happens on failed verification. The absence of annotations and output schema leaves these gaps meaningful.
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, agent_id, is already fully described in the schema as 'Agent identifier to verify'. The description adds no further parameter semantics beyond linking the id to the agent's hash chain, so the schema-coverage baseline of 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?
Description uses a specific verb 'Verify' with a specific resource 'agent's hash chain integrity', and clarifies via 'cryptographic proof of untampered history'. It is clearly distinct from sibling soul_* tools, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended scenario—checking that an agent's history was not tampered with—is implied but never stated as direct guidance. No alternatives, exclusions, or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pause and reason about a situation. No side effects, no data changes — just structured thinking. Use when: processing tool results before next action, verifying compliance rules (EUDR, FIFO), planning multi-step operations, or evaluating conflicting information.
| Name | Required | Description | Default |
|---|---|---|---|
| thought | Yes | Your reasoning, analysis, or plan. Write out your thinking step by step. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and clearly discloses that the tool has no side effects and no data changes. It also clarifies that it is a non-observable reasoning action. Only minor extras, such as whether it consumes context or waits for external state, are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences front-load the core purpose and then immediately provide actionable use cases. Every sentence earns its place, with no filler or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description fully covers what the tool does, when to use it, and its safety profile. Nothing essential is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the 'thought' parameter is well-documented in the schema as reasoning, analysis, or plan with step-by-step writing guidance. The description adds the 'structured thinking' framing but does not substantially expand on the parameter meaning, 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?
The description uses a specific verb ('Pause and reason') and clearly defines the resource ('a situation') with the qualifier 'structured thinking.' It distinguishes itself from sibling data-query tools by explicitly stating it has no side effects and no data changes, making its unique role unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit 'Use when:' list covering four distinct scenarios: processing tool results, verifying compliance rules, planning multi-step operations, and evaluating conflicting information. This gives an agent clear conditions for selecting this tool rather than a data-fetching sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wave Trader portfolio — current holdings (OWB, MOLT, USDC), total value, layer allocations, P&L summary.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It conveys that this is an informational snapshot ('current holdings... total value... P&L summary'), implying read-only usage, but it does not explicitly state that it has no side effects, how current the data is, or any auth/data-source caveats.
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, dense sentence that front-loads the resource and then lists concrete metrics. There is no filler, repetition, or unnecessary 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?
For a zero-input tool with no output schema, the description is complete enough: it states exactly what data will be returned and in what categories, and nothing required to invoke 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 has zero parameters and the schema already covers everything, so the baseline is 4. The description reinforces that no input is needed by specifying the output dimensions an agent can expect.
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 the resource as the Wave Trader portfolio and lists the exact contents: current holdings (OWB, MOLT, USDC), total value, layer allocations, and P&L summary. This is clearly distinct from siblings like get_prices or wave_signal, though it lacks an explicit verb such as 'returns' or 'lists'.
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 content makes the use case obvious—querying the user's current portfolio overview—and helps differentiate it from price, news, or signal tools. However, it gives no explicit when-to-use guidance, exclusions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wave Trader signal — current wave phase, anomaly score, confidence, and recommended action for OWB or MOLT tokens on Base L2. Real-time market analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Token symbol: OWB or MOLT |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the full burden is on the description. It discloses the signal payload (wave phase, anomaly score, confidence, recommended action) but does not define what output shape looks like or what the values mean. For a real-time market signal tool, agents need unit/threshold context to act on results; without an output schema, the description should disclose more.
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, direct, and front-loaded with the core purpose. Wastes no tokens. The second sentence adds a small amount of useful 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?
Description covers what data comes back (signal fields) but not the output structure, threshold interpretation, or urgency. For a decision-support tool, agents need more context on how to interpret the recommended action and what to do with a NON-urgent signal.
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 a clear enum description. The description repeats that the tokens are OWB or MOLT but adds no additional context about the parameter beyond 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?
States a specific action (signal analysis) and resource (OWB/MOLT tokens on Base L2). Clear distinction from generic market tools. However, does not explicitly differentiate from prediction_signals 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?
Implied usage: for tokens OWB or MOLT; use when real-time wave analysis needed. Does not state when NOT to use it or name alternatives like prediction_signals or get_prices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
calculatorcheck_availabilitycreate_quotedaloopa_queryfront_run_watchfusion_capabilitiesget_prices3 fields changedInput schema / properties / response_formatAdded value: +{
+ "description": "Response detail level: \"concise\" (default, key fields only) or \"detailed\" (all fields)",
+ "enum": [
+ "detailed",
+ "concise"
+ ],
+ "type": "string"
+}Input schema / properties / slugAdded value: +{
+ "description": "Tenant slug",
+ "enum": [
+ "siltums",
+ "woodpoint"
+ ],
+ "type": "string"
+}Input schema / requiredAdded value: +[
+ "slug"
+]mt_newswires_queryorder_statusplace_orderprediction_signalsquery_tradesalary_ai_risksalary_overviewsalary_wagessearch_products6 fields changedInput schema / properties / in_stock_onlyAdded value: +{
+ "description": "Only show in-stock products (default: true)",
+ "type": "boolean"
+}Input schema / properties / limitAdded value: +{
+ "description": "Max results (default: 50, max: 100)",
+ "type": "number"
+}Input schema / properties / response_formatAdded value: +{
+ "description": "Response detail level: \"concise\" (default, key fields only) or \"detailed\" (all fields)",
+ "enum": [
+ "detailed",
+ "concise"
+ ],
+ "type": "string"
+}Input schema / properties / slug / descriptionPrevious value: -"Specific product slug for single-product lookup"New value: +"Tenant slug"Input schema / properties / slug / enumAdded value: +[
+ "siltums",
+ "woodpoint"
+]Input schema / requiredAdded value: +[
+ "slug"
+]soul_analyticssoul_badgessoul_bounties3 fields changedInput schema / properties / limit / descriptionPrevious value: -"Max results (default: 20, max: 50)"New value: +"Max results (default: 20)"Input schema / properties / status / descriptionPrevious value: -"Bounty status filter (default: open)"New value: +"Bounty status filter (open, awarded, expired)"Input schema / properties / status / enumPrevious value: -[
- "open",
- "claimed",
- "completed"
-]New value: +[
+ "open",
+ "awarded",
+ "expired"
+]soul_compliancesoul_compliance_checksoul_insights1 field changedInput schema / properties / category / descriptionPrevious value: -"Filter by category"New value: +"Filter by insight category (optional)"soul_leaderboard1 field changedInput schema / properties / limit / descriptionPrevious value: -"Max results (default: 10, max: 50)"New value: +"Max agents to return (default: 10, max: 50)"soul_profile1 field changedInput schema / properties / agent_id / descriptionPrevious value: -"Agent identifier (e.g., \"oracle\", \"spider\", \"diplomat\")"New value: +"Agent identifier (e.g., oracle, spider, strategist)"soul_stacksoul_stack_feedsoul_verify1 field changedInput schema / properties / agent_id / descriptionPrevious value: -"Agent identifier"New value: +"Agent identifier to verify"thinktrade_alertstrade_concentrationtrade_corridortrade_forecasttrade_macrotrade_pricetrade_seasonalitywave_portfoliowave_signalsalary_ai_risksalary_overviewsalary_wagessoul_analyticssoul_badgessoul_bountiessoul_compliancesoul_compliance_checksoul_insightssoul_leaderboardsoul_profilesoul_stacksoul_verifytrade_alertstrade_concentrationtrade_corridortrade_forecasttrade_macrotrade_pricetrade_seasonalitycalculatorcheck_availabilitycreate_quoteget_pricesorder_statusplace_orderquery_tradesearch_productsClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
x402-paid tools: EU company & sanctions data, web search, LLM chat, crypto intel, x402 monitoring.
8 EU accounting (x402 USDC on Base): reconcile, VAT, invoicing. Free health.
Free EU VAT (VIES) + pan-EU company data (10 registers), payable in EURC/USDC via x402.
EUR settlement + trust for AI agent commerce: budgets, KYA, merchant discovery. 22 tools.
Add one secure layer between your agents and this server.
Multiple signal tools (front_run_watch, prediction_signals, wave_signal) serve similar purposes and could be confused, though each has a distinct data source. Similarly, soul_insights and soul_stack_feed both present agent-generated content, creating some ambiguity.
All names use snake_case, but there's no consistent pattern: some are verb-first (get_prices, search_products), some are brand-prefixed nouns (soul_bounties, wave_portfolio), and mixed usage like daloopa_query and soul_verify. The inconsistency is readable but not predictable.
16 tools for a multi-source market data server is reasonable; there are no outright redundant tools, though a few (think, fusion_capabilities) feel auxiliary. The count is slightly above ideal but well within acceptable bounds.
The server provides extensive read-only browsing (soul_bounties, soul_insights) but lacks corresponding action tools like claiming a bounty or purchasing insights, creating dead ends. For a 'market', there are no execute/trade/buy operations, leaving significant gaps for agent workflows.