Control GridBot AI spot grids on Aster from an AI assistant: read grid status, orders and history, start paper grids, stop a grid or use the kill switch. Live trading changes need the owner's approval in GridBot AI. Paid plans.
Scored across 8 tools
Each tool targets a distinct facet: permissions (get_assurance_status), configuration (get_config), runtime state (get_status), billing/plan (get_usage), and four clearly separate list resources (audit, history, orders, runtimes). The main soft spot is the cluster of single-runtime 'get_' tools — get_status vs get_config vs get_assurance_status could be briefly confused by an agent skimming names, but the descriptions sharply delineate them.
Every tool follows the same spotgrid.<verb>_<noun> pattern with only two verbs (get_ for singular reads, list_ for collections). No camelCase mixing, no vague verbs, and the verb choice is semantically predictable.
Eight tools is well within the sweet spot and each one covers a genuinely different read surface (permissions, config, state, billing, audit, fills, orders, runtimes). Nothing feels padded or redundant for a read-only observability server.
The surface is entirely read-only: an agent can inspect runtimes, configs, orders, fills and billing but cannot start/stop a runtime, modify grid configuration, cancel or place orders, or approve pending actions — even though get_assurance_status explicitly references actions awaiting approval. This leaves the core trading control lifecycle uncovered and forces agents to dead-end whenever they need to act.
Reports what this connection may do on each grid it was given (permissions, and when each grid's access ends; "*" is grids the account owner creates later) and which of its actions are waiting for the account owner's approval in GridBot AI. Returns no codes and no credentials.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| permissions | Yes | |
| pending_approvals | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds value beyond that by explaining the '*' wildcard meaning and by explicitly stating it returns no codes and no credentials, a useful boundary for an agent deciding whether to spend a call here.
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 the wildcard caveat parenthesized inline, so nothing is buried. Slightly run-on because two distinct result sets (permissions and pending approvals) share one sentence, but 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?
With an output schema present, the description need not enumerate return fields, and it still explains the one thing the schema likely cannot: the '*' wildcard convention and the no-credentials guarantee. For a zero-parameter read tool this is close to complete, missing only guidance on when to call it versus get_status or get_config.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, which sets the baseline at 4. The description correctly requires no input arguments and instead spends its words on explaining output-side semantics, such as the wildcard grid entry.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Reports') and two concrete resources: per-grid permissions/access expiry and actions pending owner approval in GridBot AI. It is clear enough to distinguish from list_orders or get_usage, though it never names a sibling to sharpen the boundary.
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 when-to-use or when-not-to-use statement, and no prerequisites are given; the reader must infer that this is the pre-flight check for access and approvals. The only exclusion is implicit in 'Returns no codes and no credentials', which steers credential lookups elsewhere.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads one runtime's trading configuration: symbol, grid geometry, risk profile, wallet allocation and fee settings. Exchange API credentials are never included in the result. buy_fee_pct and sell_fee_pct are what is CONFIGURED; when fee_mode is auto they are 0 while real fees are still being charged, so effective_buy_fee_pct and effective_sell_fee_pct give the rate actually applied to a fill and fee_source says where it comes from: manual (the configured percentage), manual_fixed (a flat USDT amount per fill), learned (measured from real exchange fills), paper_default (the simulator's rate, before any real fee has been seen) or unobserved (live, no fill measured yet — the rate is not known rather than zero). Under manual_fixed the charge is effective_buy_fee_usdt / effective_sell_fee_usdt, which is exact; the percentage is present only when a price is known to express it against, and is omitted rather than reported as zero when it is not.
| Name | Required | Description | Default |
|---|---|---|---|
| runtime_id | Yes | A Multi Grid runtime id from spotgrid.list_runtimes. The primary grid is the one listed with primary: true. |
| Name | Required | Description |
|---|---|---|
| mode | No | |
| symbol | No | |
| max_buys | No | |
| grid_size | No | |
| fee_source | No | |
| runtime_id | Yes | |
| live_network | No | |
| risk_profile | No | |
| wallet_allocation | No | |
| credentials_present | No | |
| effective_buy_fee_pct | No | |
| effective_buy_fee_usdt | No | |
| effective_sell_fee_pct | No | |
| effective_sell_fee_usdt | No | |
| live_credentials_present | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only and idempotent annotations, the description adds important context: exchange API credentials are excluded, configured fee percentages can be misleading under auto mode, and effective fee fields plus fee_source explain the actual applied rate. It also discloses the nuanced manual_fixed behavior and that unknown percentages are omitted rather than reported as zero.
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 purpose and credential exclusion are front-loaded, but the description then spends most of its length on dense fee-field semantics that may duplicate output-schema documentation. The information is useful, but the result is longer and less scannable than ideal for a single-parameter read tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only configuration getter with a fully described one-parameter schema and an output schema, the description covers the essential purpose, security caveat, and the most easily misinterpreted fee fields. It does not mention sibling routing or error behavior, but the core invocation context is 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?
Schema coverage is 100%, and the runtime_id parameter is already documented with its pattern and source in spotgrid.list_runtimes. The description does not add any runtime_id-specific semantics beyond the schema, so the 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 uses a specific verb and resource: it 'Reads one runtime's trading configuration' and enumerates the configuration areas returned. This clearly distinguishes it from status, order, or history siblings, though it does not explicitly name an alternative tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to call this tool versus siblings such as spotgrid.get_status or spotgrid.get_usage. Usage is only implied by the phrase 'trading configuration', with no alternatives or exclusions stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads one runtime's current state: running or stopped, paper or live mode, network, kill-switch state, open order counts and the latest ticker the bot acted on.
| Name | Required | Description | Default |
|---|---|---|---|
| runtime_id | Yes | A Multi Grid runtime id from spotgrid.list_runtimes. The primary grid is the one listed with primary: true. |
| Name | Required | Description |
|---|---|---|
| mode | Yes | |
| symbol | No | |
| network | No | |
| running | Yes | |
| open_buys | No | |
| last_price | No | |
| open_sells | No | |
| runtime_id | Yes | |
| kill_switch | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered. The description's contribution beyond that is listing the state fields returned, which largely duplicates the output schema. It adds nothing about behavior an agent might need, such as what happens with an unknown or stale runtime_id.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the verb and scope, then the returned state fields. Every clause carries information and there is no filler or repetition.
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, the description does not need to enumerate return values, and the one required parameter is fully documented in the schema. The tool is a simple idempotent read, so the definition is essentially complete; only a note on invalid or missing runtime_id behavior is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single parameter with 100% schema description coverage, and the schema already explains where the id comes from (spotgrid.list_runtimes) and how to identify the primary grid. The description adds no further meaning about runtime_id. Baseline 3 is correct when the schema does the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ("Reads one runtime's current state") and enumerates exactly what that state comprises: running/stopped, paper/live mode, network, kill-switch, open order counts, latest ticker. This implicitly separates it from spotgrid.get_config (static configuration) and spotgrid.get_assurance_status. It stops short of naming a sibling explicitly, so it is clear but not maximally 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?
Usage is only implied: an agent can infer this is the tool for a point-in-time runtime health/state check. There is no statement of when to prefer this over spotgrid.get_config or spotgrid.get_assurance_status, and no exclusions. Adequate for a self-evidently named read tool, but the sibling boundary is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads the account's subscription plan, billable volume used in the current period, the plan cap and which actions are currently permitted. Does not include payment details. Billable volume counts LIVE fills only: PAPER trading and testnet activity are never billed, so an account that trades only on paper correctly reads 0.00 used — that is a bot trading simulated money, not a meter that has stopped. cap_usd is null when the plan has no cap, and pct_used is then 0.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| plan | Yes | |
| status | Yes | |
| cap_usd | No | |
| pct_used | No | |
| used_usd | No | |
| mcp_entitled | Yes | |
| payment_lapsed | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description explains that billable volume counts only LIVE fills, that paper and testnet activity is never billed, and why a paper-only account legitimately reads 0.00 used. It also clarifies the null cap_usd / zero pct_used relationship, which materially changes how an agent should interpret the response.
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?
It is front-loaded with the read scope, followed by the payment exclusion, the billing caveat, and the null-cap rule. The paper-trading explanation is the longest clause, but it earns its place by preventing a common misreading of a 0.00 value.
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?
An output schema exists, so return values need not be enumerated. Given zero parameters and a safe read-only annotation profile, the description covers everything an agent needs: what is read, what is excluded, and how to interpret edge-case values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so the baseline is 4 and there is nothing further for the description to disambiguate on the input side. The description spends its space on response semantics instead, which 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 opens with a specific verb and a concrete list of resources: subscription plan, billable volume used, plan cap, and permitted actions. That is enough for an agent to distinguish it from siblings like get_status or get_config, even though no sibling is named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the resource being read (plan usage and entitlements), and one exclusion is stated: payment details are not included. However, there is no explicit guidance on when to prefer this over get_assurance_status or get_config, so the agent must infer the boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists this account's recent MCP activity: which tool ran, which runtime it touched, which connected client requested it, which connected session it came from and whether it was allowed. conn_id names one session: it stays the same for as long as a client remains connected and differs between two sessions, which client_id cannot show because every connection from one AI platform reports the same client. Scoped to the calling account only.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum events to return (default 25). |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| events | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description's real contribution is the account scoping constraint and the conn_id stability semantics — non-obvious behavior an agent would otherwise have to discover empirically. It says nothing about ordering or whether the window is time-bounded, which is the remaining behavioral 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 result fields are front-loaded, then the clarification that conn_id is session-stable follows as supporting detail. The client_id/conn_id comparison is the longest clause but earns its place by explaining a distinction the reader would otherwise get wrong; minor tightening is possible in "which client_id cannot show because every connection from one AI platform reports the same client."
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?
An output schema exists, so return values need no prose, and the single input parameter is schema-documented. The account scoping line closes the main correctness risk; only the ordering of "recent" events and any pagination beyond limit are left unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single limit parameter is fully documented in the schema including its default of 25 and its 1-100 bounds, so the description owes it nothing. Per the high-coverage baseline this is a 3; the description adds no paging or ordering 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?
"Lists this account's recent MCP activity" pairs a specific verb with a specific resource, then enumerates the returned facets (tool, runtime, client, session, allowed/denied), which makes the tool's scope unmistakable against list_history / list_orders / list_runtimes. It stops short of naming a sibling explicitly, so it sits just under a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No statement of when to reach for this over spotgrid.list_history or spotgrid.get_usage, and no stated prerequisites. Usage is only implied by the conn_id discussion, which suggests it is the tool to use when you need to tell two sessions from the same AI platform apart.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists completed fills for one runtime, newest first, with the profit realised on each. Paginated: has_more says whether rows remain behind this page and next_cursor is present whenever they do — pass it back to continue, and keep going until has_more is false, because one page is not the whole history. realized_pnl is the gross figure the ledger booked for that fill, from the price achieved minus buy_price, the basis actually paid. fee_usdt is the fee recorded for that one fill and realized_pnl_net is the gross less that fee; the paired fill's fee is on its own row. fees_estimated is true when the fee was modelled rather than charged by an exchange, which is always the case in PAPER mode, where mode says so. page_totals sums this page and only this page. On a SELL, expected_pnl is what the rung was designed to make — the grid spacing at that fill times the quantity — so the gap between it and realized_pnl is slippage, a partial fill or a rung that moved; in PAPER the two coincide by construction.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum trades to return (default 50). | |
| cursor | No | The next_cursor from a previous call. Continues that listing where it stopped. | |
| runtime_id | Yes | A Multi Grid runtime id from spotgrid.list_runtimes. The primary grid is the one listed with primary: true. |
| Name | Required | Description |
|---|---|---|
| mode | No | |
| count | Yes | |
| trades | Yes | |
| network | No | |
| has_more | No | |
| runtime_id | Yes | |
| next_cursor | No | |
| page_totals | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so this is a lower bar, yet the description adds substantial behaviour beyond them: pagination loop semantics, the gross/net fee relationship, per-row fee attribution, page_totals being page-scoped, and PAPER-mode behaviour where fees are modelled and expected_pnl coincides with realized_pnl.
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?
Purpose and the pagination contract are front-loaded, and every sentence carries content. The back half is effectively a field glossary that partially duplicates the output schema, and the very long em-dash-chained sentences make it denser than it needs to be.
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 paginated read tool with an output schema and full annotation coverage, the description is complete: an agent knows how to call it, how to exhaust the pages, and how to interpret realized_pnl, the fee fields, page_totals and the expected_pnl gap on SELLs.
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 runtime_id and cursor are already documented, and limit is left entirely to the schema. The description reinforces the cursor/has_more contract but adds no syntax, bounds or defaults beyond what the schema states, 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?
Names a specific verb and resource ('Lists completed fills for one runtime') plus the ordering ('newest first') and the payload ('the profit realised on each'). An agent can tell this apart from spotgrid.list_orders (orders, not fills) without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives strong operational guidance for pagination: pass next_cursor back and keep going until has_more is false, explicitly warning that 'one page is not the whole history'. It does not, however, say when to prefer this over spotgrid.list_orders or spotgrid.list_audit, so tool-selection guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the open BUY and SELL orders resting on one runtime's ladder, highest price first. Optionally filtered to one side. An order's quantity is what was actually submitted to the venue, which is not always the configured template size: configured_quantity gives the template for that side and sizing gives the exchange step, minimum quantity and minimum notional that the submitted size was snapped to. created_ms is absent, never zero, when the order predates a recorded creation time.
| Name | Required | Description | Default |
|---|---|---|---|
| side | No | Which side to return. Defaults to ALL. | |
| limit | No | Maximum orders to return (default 50). | |
| runtime_id | Yes | A Multi Grid runtime id from spotgrid.list_runtimes. The primary grid is the one listed with primary: true. |
| Name | Required | Description |
|---|---|---|
| mode | No | |
| count | Yes | |
| orders | Yes | |
| sizing | No | |
| network | No | |
| runtime_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, open-world behavior, so the description rightly focuses on data semantics instead. It adds genuine context beyond annotations: submitted quantity can differ from the configured template size, sizing carries the exchange step and minimums the size was snapped to, and created_ms is absent rather than zero for older orders.
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 first sentence front-loads the resource, scope, and ordering, and each later sentence targets a distinct semantic subtlety. It is dense but mostly earns its place, though the quantity/sizing explanation is fairly long for what is largely return-value 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 simple three-parameter read tool with full schema coverage and an output schema, the description covers the important ambiguities around order quantity and missing timestamps. It leaves minor gaps such as whether partially filled orders are included and whether limit truncation is signaled, but nothing critical is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so side, limit, and runtime_id are already documented, including the enum and the runtime_id pattern. The description only restates that results can be filtered to one side and adds no new syntax, defaults, or edge-case meaning for the inputs, 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 names a specific verb and resource (open BUY and SELL orders on one runtime's ladder) and adds scope plus ordering (highest price first, optionally filtered to one side). It is clearly distinguishable from siblings like list_history, list_audit, and list_runtimes without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'one runtime's ladder' implies you need a runtime id, and the schema points to spotgrid.list_runtimes for that. But there is no explicit when-to-use versus when-not guidance and no named alternative for retrieving filled or historical orders, so the agent must infer the boundary with list_history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the GridBot AI runtimes this connection may use: the grids where the account owner gave it at least one permission that has not ended. Returns identifiers, labels, symbol, paper/live mode, whether each is running, the permissions held on it and when they end (access_expires_at, null for no end). Does not reveal runtimes outside what was shared — a grid that was not shared is absent, exactly as one that does not exist is. A grid marked primary is the account's included bot; the marker is absent when the primary is not shared.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| runtimes | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the bar is lower, yet the description adds real behavioral substance beyond them: the permission-based visibility filter, the equivalence of 'not shared' and 'does not exist', the meaning of access_expires_at being null, and the conditional presence of the primary marker. These are exactly the non-obvious traits an agent needs to interpret results correctly.
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?
Scope and visibility constraint are front-loaded in the first sentence, and every sentence carries information. Some of the middle content enumerates return fields (identifiers, labels, symbol, mode, running, permissions), which is partly redundant given an output schema exists, so the text runs slightly longer than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only listing tool with annotations and an output schema already in place, the description covers the only remaining risk areas: what is in scope, why something may be missing, and how to read the expiry and primary fields. Nothing an agent needs in order to call it or interpret its output is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. The description correctly spends no words on inputs.
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 ('Lists the GridBot AI runtimes this connection may use') and immediately bounds the scope to grids where the account owner granted a still-active permission. No sibling tool (get_status, list_orders, list_history) overlaps with this resource, so an agent can route to it without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description supplies the essential interpretive context: only shared grids appear, and an unshared grid is indistinguishable from a nonexistent one, which tells the agent how to read an empty or partial result. It does not name alternatives or state an explicit when-not condition, but there is no competing runtimes-listing sibling to disambiguate against.
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.
spotgrid.get_assurance_statusspotgrid.get_configspotgrid.get_statusspotgrid.get_usagespotgrid.list_auditspotgrid.list_historyspotgrid.list_ordersspotgrid.list_runtimes
Add one secure layer between your agents and this server.