Public.com MCP Server

Official

by PublicDotCom

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.6.1
Disambiguation5/5
Each tool has a clearly distinct purpose. Preflight vs place pairs are separated by operation type, and spread-specific tools are named with the strategy (call/credit/debit). No two tools could be easily confused.
Naming Consistency5/5
All tools follow verb_noun snake_case pattern consistently (e.g., get_accounts, preflight_order, place_call_credit_spread). No mixing of conventions or erratic naming.
Tool Count4/5
35 tools is somewhat high but each serves a necessary role in a full-featured brokerage MCP: market data, orders, options strategies, tax lots, and account management. The count is appropriate for the scope.
Completeness4/5
Covers core trading workflows (single-leg, multi-leg, spreads, short sales) with preflight checks, order placement, cancellation/replacement, tax lots, and market data. Minor gaps like no detailed single-account view, but overall comprehensive.
Average 4.4/5 across 35 of 35 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- Last stable release on August 11, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to repeat safety traits. It adds no behavioral details beyond stating that it retrieves Greeks, which is consistent with the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a one-line purpose statement followed by a structured Args section. It is front-loaded with the main action. Every sentence provides useful information, though the Args formatting is slightly more verbose than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (not shown), the description need not detail return values. It covers input parameters adequately but omits information about error handling, rate limits, or behavior for invalid symbols. The description is adequate for a simple 2-parameter tool but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides a meaningful explanation of 'osi_symbols' with an example format ('OSI-normalized option symbols') and clarifies that 'account_id' is optional if the environment variable is set. This adds significant value over the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns option Greeks (delta, gamma, theta, vega, rho, IV) for option symbols. It uses specific verb 'Get' and resource 'option Greeks.' However, it does not explicitly differentiate from its sibling 'get_option_greek' (singular), though the plural name and array parameter imply batch usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as the singular 'get_option_greek' or other option-related tools. There is no discussion of prerequisites, scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=false. The description adds what the tool returns (trading status, fractional trading, option capabilities) but does not disclose other behaviors like error handling or data freshness. It adds some context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear structure: purpose, return summary, then arguments. Every sentence adds value without fluff. Slight improvement possible by integrating argument explanations more seamlessly, but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to detail return format. It covers the tool's purpose, key arguments, and what categories of data are returned. It is adequate for a simple getter tool, though it lacks mention of possible error cases or limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining symbol as "Ticker symbol (e.g. "AAPL")" and instrument_type as "One of EQUITY, CRYPTO, OPTION, INDEX, ALT, BOND, TREASURY. Default is EQUITY." This adds examples and enum values that the schema alone does not provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states "Get details about a specific tradeable instrument" with a specific verb-resource pair. It distinguishes from sibling get_all_instruments by specifying "specific" and listing returned fields like trading status and option capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need details on one instrument but does not explicitly state when to use versus alternatives like get_all_instruments or get_option_chain. There is no when-not or exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description adds that it returns calls and puts but does not elaborate on error handling, authentication needs, or response structure. Adequate but not enhanced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with a front-loaded purpose and a well-structured argument list. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema covering return values, the description is nearly complete. It explains parameters well but could mention that account_id may be required despite being optional. Still, it is sufficient for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the tool description provides clear explanations for all parameters, including format, default, and optionality, compensating fully for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool gets the full option chain (calls and puts) for a symbol and expiration. Differentiates from siblings like get_option_expirations and get_option_greek by specifying 'full option chain'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs. siblings such as get_option_expirations or get_option_greek. The description lacks context on prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. Description adds valuable context about asynchronous indexing and potential error, enhancing transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is relatively short but includes a code-like 'Args' section; overall efficient and front-loaded with purpose. Minor redundancy acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get tool with output schema, description covers async behavior and error case. Adequate given complexity and existing schema/annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains order_id as UUID and account_id as optional with env var fallback, adding some meaning but not full details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get the status and details of a specific order,' with a specific verb and resource. It distinguishes from sibling tools like 'get_orders' (list) and order mutation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies use when fetching a specific order by ID, but does not explicitly state when to use or not use alternatives among many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds value by noting that account_id is optional if PUBLIC_COM_ACCOUNT_ID is set, revealing an authentication behavior. However, no further behavioral details are given beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear front-loaded purpose and parameter explanations in a structured list. Every sentence adds value, though it could be slightly more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to explain return values. It covers the tool's purpose, all parameters with context, and an authentication nuance. The tool is simple and the description is complete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 0%, the description adds meaning to parameters: symbol is an underlying ticker, instrument_type has two specific values (EQUITY or UNDERLYING_SECURITY_FOR_INDEX_OPTION), and account_id is optional under a specific condition. This provides clarity beyond the schema's type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get available option expiration dates for a symbol.' This specific verb and resource distinguish it from siblings like get_option_chain or get_option_greek, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description does not mention when not to use it or provide context for tool selection among siblings like get_option_chain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already declare readOnlyHint=true and destructiveHint=false, the description adds valuable behavioral context by specifying the return contents (per-lot unrealized gain/loss, holding term, cost basis, aggregate totals) and the authentication requirement (API key must have 'trading.read' scope). This goes beyond what annotations provide, without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first sentence states the primary purpose, the second details the return contents, and the Args section efficiently covers the one parameter. There is no superfluous text; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simple one-parameter interface and the presence of an output schema, the description adequately covers what it returns, the auth requirement, and parameter optionality. It doesn't need to explain return values in depth because an output schema exists, but it could have benefited from a brief note on when to choose this over the symbol-specific or CSV variants. Still, it is largely complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a default null and anyOf type for account_id, with 0% description coverage. The description fully compensates by explaining that account_id is 'Optional if PUBLIC_COM_ACCOUNT_ID is set,' thereby providing essential context about when it can be omitted and how the environment variable factor works. This is complete and clear for the sole parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Get') and a precise resource: 'unrealized tax-lot summary for the account.' It further details what the summary includes (per-lot gains/losses, holding term, cost basis, aggregate totals), making its purpose unambiguous and distinguishing it from siblings like get_tax_lots_for_symbol and get_tax_lots_csv.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus its alternatives. The description does not mention the sibling get_tax_lots_for_symbol for symbol-specific queries or get_tax_lots_csv for CSV export, nor does it provide context about typical use cases. It only mentions the required scope, which is a prerequisite, not a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that it estimates costs and does not place an order, but provides no additional behavioral context (e.g., authentication, rate limits, or error behavior). The added value over annotations is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and a clear disclaimer. The argument list is structured but duplicates some schema information. It is slightly verbose but efficiently communicates essential details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a multi-leg options tool, the description covers the input parameters well and the presence of an output schema compensates for lack of return value explanation. It lacks edge case or error handling details, but overall is sufficiently complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It gives a detailed example and structure for the 'legs' parameter, including required fields and optional fields with defaults. Other parameters like 'limit_price' and 'time_in_force' receive only brief explanations. Overall adds meaningful context beyond the schema, but could be more thorough for all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Estimate costs for a multi-leg (options strategy) trade before placing it.' and explicitly notes 'Does NOT place an order.' This distinguishes it from sibling tools like place_multileg_order and specific preflight functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use (before placing a multi-leg order to estimate costs) and what it does not do (place the order). However, it lacks explicit guidance on when to use this tool versus the more specific preflight call/put spread tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, so description adds value by specifying the return format (account IDs and types). No contradiction, and no additional behavioral details needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action, no wasted words. Ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, presence of output schema, and annotations, the description covers the essential information. Could be slightly more explicit about scope (e.g., 'all accounts for API key'), but it's sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so baseline 4 applies. The description correctly adds no parameter information beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and resource (brokerage accounts), and mentions the return value (account IDs and types). This distinguishes it from sibling tools like get_portfolio or get_orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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 guidance. However, the purpose is clear and context implies it's for enumerating accounts, which is adequate for a simple list tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior, and the description adds parameter-specific constraints (valid enum values), which is sufficient beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured with clear parameter descriptions, and front-loads the purpose in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description is complete enough for a listing tool; it omits potential concerns like result size but is adequate for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description fully documents all three parameters, listing valid values for type_filter and trading_filter, and explaining account_id's optionality relative to an environment variable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all available tradeable instruments') and resource, distinguishing it from sibling tools like 'get_instrument' which retrieves a single instrument.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing instruments with optional filters but does not explicitly contrast with siblings like 'get_instrument' or specify when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by specifying the types of data returned (trades, money movements, adjustments) and pagination behavior, which goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a brief introductory sentence, a list of return types, and then parameter documentation in a clean Args block. No unnecessary information, and the most important details are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality, return types, and parameter semantics. However, it lacks behavioral details like default date ranges, default page_size, and behavior when parameters are omitted. Output schema exists, which supplements completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description fully explains each parameter: account_id (optional with env var fallback), start/end (ISO 8601 format), page_size (max records), next_token (pagination). This is excellent for agent understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves account transaction history and lists the types of transactions included (trades, money movements, adjustments). This distinguishes it from sibling tools like get_orders and get_portfolio.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool instead of alternatives, such as get_orders for orders or get_portfolio for positions. The usage is implied by the purpose, but no direct guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds that it returns specific fields (last price, bid, ask, volume) but no behavioral traits beyond what annotations suggest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded with purpose, and includes an Args section. Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers parameters and return data well for a read-only tool with output schema. Could mention potential limitations like rate limits or pagination, but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description fully explains each parameter: symbols (list of tickers), instrument_type (with allowed values), account_id (optional with env var fallback). Adds significant meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Get', resource 'real-time quotes', and scope 'one or more symbols'. Distinguishes from sibling tools like get_historic_bars or get_instrument.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on using the tool for mixed instrument types by calling multiple times. Does not explicitly state when not to use or compare to alternatives like get_all_instruments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds key behavioral disclosure: 'executes a real trade' and 'Receive a net credit'. Annotations are minimal (destructiveHint=false, readOnlyHint=false) but description warns of trade execution, adding context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with a clear structure: purpose, warning, then args list. Every sentence adds value. Minor room for tighter phrasing but highly effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all 7 parameters with context, provides a warning and prerequisite, mentions net credit. Output schema exists but unnecessary to describe return values. Complete for an execution tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage; the description compensates fully by explaining each parameter: sell_contract_osi (higher strike), buy_contract_osi (lower strike), quantity, limit_price (minimum net credit), time_in_force, expiration_time, account_id. This adds significant meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool places a Bull Put Spread, explains the mechanics (sell higher-strike put, buy lower-strike put, net credit), and distinguishes it from siblings like place_put_debit_spread and place_call_credit_spread.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends running preflight_put_credit_spread first, guiding when to use this execution tool versus a simulation. Lacks explicit when-not-to-use but the preflight suggestion provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds that no order is placed, which is consistent and slightly reinforces the behavior. No additional details on auth, rate limits, or side effects, but adequate for a read-only estimation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is brief but complete: a clear opening sentence, a concise strategy explanation, and a well-structured bullet list of parameters. No wasted words; front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, an output schema (presumably describing cost estimate), and sibling tools, the description covers purpose, parameters, and key behavior. It meets the needs for a preflight check tool, though it does not detail what the output contains (but output schema handles that). Minor gap: no mention of prerequisites like market data availability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description provides clear explanations for all 7 parameters, including OSI symbols, quantity, limit price as net debit, time_in_force options, expiration_time format, and account_id optionality. Adds significant value beyond schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool estimates costs for a Bear Put Spread, explains the strategy (buy higher strike, sell lower strike), and explicitly says it does not place an order. Distinguishes well from sibling preflight and order placement tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Estimate costs before placing it' and 'Does NOT place an order', implying use before order placement. Sibling tools include 'place_put_debit_spread' for actual order placement, making usage context clear. No explicit when-not-to-use but sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: cancellations may not be immediate during market hours, and confirmation via get_order is recommended. This complements the destructiveHint and idempotentHint annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a header, a brief note, and parameter docs. No extraneous text. Front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists (though not detailed), the description covers key behavioral aspects (non-immediate cancellation, confirmation). It might lack details on edge cases (already cancelled order), but is sufficient for a simple cancel tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides essential context: order_id is the UUID, account_id is optional if PUBLIC_COM_ACCOUNT_ID is set. This meaningfully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Cancel an existing order.' This is a specific verb and resource, and it distinguishes from siblings like 'cancel_and_replace_order' by implication. The note about non-immediate cancellation adds clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using get_order to confirm cancellation, providing a clear after-use action. It does not explicitly list when not to use, but the note about non-guaranteed immediate cancellation sets expectations. Sibling 'cancel_and_replace_order' exists but is not contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description doesn't need to repeat safety. It adds minimal behavioral context beyond purpose, such as mentioning the specific Greeks returned. No contradictions, and the presence of an output schema reduces the need to describe return values, but no additional traits (e.g., rate limits, caching) are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences and a parameter list. Every sentence adds value, with no redundancy or fluff. It is front-loaded with the main action and then details the parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool (get greeks for one symbol), the presence of an output schema (reducing need to describe returns), and good parameter coverage, the description is complete. It covers all necessary input details for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so effectively by explaining 'osi_symbol' as an OSI-normalized option symbol with an example ('AAPL260320C00280000') and clarifying that 'account_id' is optional if the environment variable is set. This adds significant meaning beyond the schema's type-only definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves option Greeks (delta, gamma, theta, vega, rho, IV) for a single option symbol. It distinguishes itself from sibling tools like 'get_option_greeks' (likely bulk) and 'get_option_chain' (full chain) by specifying 'single option symbol' and listing specific Greeks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit parameter guidance: 'osi_symbol' is required and shown with an example, 'account_id' is optional if PUBLIC_COM_ACCOUNT_ID is set. This indicates when to use the tool (when you have a single OSI symbol). It does not explicitly state when not to use or mention alternatives, but the sibling context makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description reinforces that the tool does not place an order, but adds no further behavioral context (e.g., authorization needs, rate limits). With annotations present, the description's added value on behavior is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a brief purpose statement followed by a well-organized Args list. Every sentence adds value, and there is no extraneous content. It is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (not shown but provided), the description does not need to explain return values. It covers the tool's purpose, all parameters, and its non-destructive nature. For a tool with 9 parameters, this is complete and sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description includes a detailed Args section explaining each parameter's purpose, examples, defaults, and conditions (e.g., 'limit_price: Required for LIMIT and STOP_LIMIT orders'). This adds significant meaning beyond the schema's type-only definitions for all 9 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Estimate costs for a short-sale equity order before placing it', which is a specific verb+resource. It distinguishes from sibling tools like place_short_order (which places the order) and other preflight tools (for spreads or generic orders).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Returns estimated commission, fees, and buying power impact. Does NOT place an order.' This clearly indicates when to use it (before placing a short order) and what it does not do. It does not explicitly mention alternatives or when not to use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful context beyond the annotations: the warning '⚠️ This modifies an existing order' reinforces the destructiveHint, and it states atomicity, supported asset types (equity, option, crypto), and parameter mutual exclusivity. These are useful behavioral details not present in the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-sentence purpose, a clear warning, a supported-assets line, and a compact Args list. Every element serves a purpose, and the front-loaded purpose ensures the agent immediately understands the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, no schema descriptions) and the presence of an output schema, the description is quite thorough. It covers all parameters, conditions, and constraints. It lacks explicit failure behavior (e.g., what if the original order cannot be cancelled), but the atomicity hint partially addresses this. Minor gap prevents a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries full responsibility for parameter explanation. The Args section covers all 9 parameters with enums (order_type), defaults (time_in_force), mutual exclusivity (quantity vs amount), conditional requirements (expiration_time when GTD), and context (account_id optional if env var set). This fully compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Atomically cancel an existing order and replace it with new parameters,' which is a specific verb+resource statement that clearly distinguishes this tool from siblings like cancel_order and place_order. The atomicity qualifier adds valuable scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While it doesn't explicitly mention alternatives like 'use this instead of cancel_order then place_order,' the phrase 'Atomically cancel an existing order and replace it' provides clear context for when this tool is appropriate. However, there are no explicit exclusions or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by detailing that it checks an environment variable and attempts authentication. Annotations already indicate readOnlyHint=true, but the description gives concrete behavioral context about what is actually verified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is just two sentences, front-loads the purpose, and contains no fluff. Every sentence is necessary and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, has an output schema, and annotations are present, the description is complete. It explains what the tool does, what it checks, and when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and schema description coverage is 100% (trivially). The description does not need to add parameter information, and with zero parameters a baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool verifies Public.com API credentials, checks the PUBLIC_COM_SECRET environment variable, and attempts authentication. This is a specific verb-resource pair that clearly distinguishes it from sibling tools, which focus on orders, accounts, and other operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Run this first to confirm connectivity,' providing clear context for when to use the tool as a prerequisite. It does not explicitly list exclusions or alternatives, but the guidance is sufficient for a setup validation tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint. Description adds details on returned data (including open orders, cash figures) and the non-IRA constraint, providing useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short paragraphs: first sentence states purpose, bullet-like list of returns, constraint, then parameter explanation. No fluff, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, description focuses on high-level return categories (positions, equity, etc.) and the IRA constraint. Also documents optional parameter behavior. Fully covers what an agent needs to decide usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter account_id is explained: it is optional if PUBLIC_COM_ACCOUNT_ID is set. This adds meaning beyond the schema (which only defines type and nullability) by specifying default behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get a snapshot of the account portfolio' and lists specific returned data (positions, equity, buying power, etc.), distinguishing it from sibling tools that handle orders, quotes, or accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly notes that only non-IRA accounts are supported, providing a clear exclusion. Alternatively, could mention that get_accounts is for account list, but not required. Context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false; description adds 'executes a real trade' warning and references preflight, providing useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and warning, then clear parameter breakdown with example; every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all parameters with explanations and example, references relevant sibling tool (preflight_multileg_order), and output schema exists so return format is not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description extensively documents each parameter (e.g., limit_price meaning, leg structure with example), adding significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Place a multi-leg order (options strategies: spreads, straddles, etc.)' – specific verb and resource, and distinguishes from siblings like place_order and specific spread tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly warns about real trade execution and recommends running preflight_multileg_order first, providing clear context for when to use this tool vs. the preflight alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, but description adds the explicit warning '⚠️ This executes a real trade.' which is critical for a trade execution tool. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with a brief intro, a warning, and a bulleted Args list. It is clear and informative without being verbose. Could potentially trim minor redundancy, but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters and 4 required, the description covers all parameters and provides crucial context (real trade, preflight suggestion). An output schema exists (though not shown), so return behavior is likely documented elsewhere. The description is complete for the agent's needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, requiring the description to explain all 7 parameters. The Args section provides clear semantics: sell_contract_osi (lower strike), buy_contract_osi (higher strike), quantity, limit_price (max net debit), time_in_force (DAY or GTD), expiration_time (ISO 8601), account_id (optional with env var). Adds significant value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Place' with specific resource 'Put Debit Spread'. Explains strategy (buy high strike, sell low strike) and net debit nature. Distinct from sibling tools like place_call_credit_spread, place_put_credit_spread, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends running preflight_put_debit_spread first. Warns that it executes a real trade. Does not specify when NOT to use, but the preflight suggestion and context imply careful consideration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description warns 'This executes a real trade.' beyond annotations (destructiveHint=false). However, it does not detail risks like margin requirements or potential losses.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a brief intro, a warning, and a bulleted parameter list. Every element adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the essential: action, parameters, and warning. Given an output schema exists, return values need not be explained. Could add more context about market conditions for shorting.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description provides exhaustive parameter explanations (symbol, quantity, order_type, etc.), adding significant meaning beyond the schema's bare names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Place an equity short-sale order.' and distinguishes from siblings like preflight_short_order and place_order (which may be for long orders). The warning about real trade adds clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends running preflight_short_order first, providing a clear alternative. It does not explicitly state when not to use, but the warning implies caution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. Description reinforces non-destructive nature and adds context about the spread strategy. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured: a short purpose paragraph followed by a clear args list. Front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, strategy, and all parameters. Lacks details about the output format, but an output schema exists to provide that information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides meaningful explanations for all 7 parameters, including defaults and conditional requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it estimates costs for a Bull Call Spread (call debit spread), with specific verb+resource. Distinguishes from sibling preflight tools for other spread types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains it is for estimating costs before placing an order and explicitly says 'Does NOT place an order.' Implicitly contrasts with order placement tools, but could be more explicit about when to use vs. other preflight tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish read-only behavior via readOnlyHint=true and destructiveHint=false. The description adds behavioral detail by specifying the content domains (pricing, ratings, coupon schedule, maturity, call information) and the symbol format requirement. It does not contradict the annotations and provides context beyond what annotations convey, though it omits edge-case behavior like not-found handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a two-sentence overview followed by an Args section. It is front-loaded with purpose and return categories, contains no filler, and every sentence contributes to understanding the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only two parameters (one required), a read-only annotation, and an output schema, this description is fully adequate. It explains both parameters, lists the return categories, and fits within the broader tool context. No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero descriptions (0% coverage), so the description carries the full burden. It explains symbol format with a concrete example ('912810TM0-BOND') and clarifies that account_id is optional if PUBLIC_COM_ACCOUNT_ID is set. This turns otherwise opaque schema properties into actionable parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Get comprehensive details for a single bond.' It also enumerates the specific types of information returned (pricing, ratings, coupon schedule, maturity, call info), which distinguishes it from sibling tools like search_bonds or get_instrument. The scope ('single bond') and identification method ('by its symbol') are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is clear: this tool is for when you already have a bond symbol and need comprehensive details. It mentions the optional account_id and the environment variable fallback, which is practical guidance. However, it does not explicitly name alternative tools or state when not to use this tool, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds value by explaining it fetches the portfolio and returns only the orders list, and lists specific return fields. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tight sentences with no fluff: purpose, operation, return details, args. Front-loaded with clear action. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and an output schema, the description provides all needed context: what it does, scope, return contents, and parameter explanation. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage, so description bears full burden. It explains the single parameter account_id, its purpose, and the conditional optionality (if PUBLIC_COM_ACCOUNT_ID is set), adding significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get all open/active orders on the account', using a specific verb and resource. It distinguishes from sibling 'get_order' (single order) and other order tools by specifying 'all open/active orders'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description tells when to use (to get open/active orders) and what it returns. It implies not for single order or other operations, but does not explicitly mention alternatives. The parameter guidance (optional if env var set) helps usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful context beyond annotations: it states the required API scope, explains that price is optional and defaults to current market price, and describes what fields are returned. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-sentence summary, a return-detail line, a scope requirement, then a concise Args list. Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, return values are already partially documented. The description adds sufficient context: what lots are returned (gain/loss, term, cost basis), scope requirement, and parameter behavior. It is complete for a read-only single-symbol lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully compensates with an Args section. It explains symbol with an example, price as an optional numeric string with omission behavior, and account_id as optional if a default is set. This goes well beyond the basic schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb+resource: 'Get the unrealized tax-lot detail for a single symbol.' It clearly distinguishes from sibling tools like get_tax_lots (all lots) and get_tax_lots_csv (export) by emphasizing the single-symbol scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: it returns open lots with cost basis, can accept an optional price, and requires trading.read scope. It does not explicitly mention alternatives or when-not-to-use, but the single-symbol restriction is implied. Lacks explicit exclusion guidance for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description warns that this executes a real trade, which is critical behavioral information beyond annotations. It also details the complex tax_lot_matching_instructions constraints. Annotations already indicate readOnlyHint=false and destructiveHint=false, so description adds useful context without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a concise one-line summary, a critical warning, then a detailed but organized Args list. Every sentence provides necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 14 parameters and the existence of an output schema, the description covers all parameter details, constraints, and usage nuances. It does not need to describe return values because the output schema exists. The description is complete for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully explains each parameter's meaning, constraints (e.g., mutual exclusivity of quantity/amount, required prices for certain order types), and special rules like tax lot matching. This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it places a single-leg order for stocks, crypto, or options, with a specific verb 'place' and resource. It distinguishes from sibling tools like place_multileg_order and preflight_order by mentioning single-leg and suggesting preflight first.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using preflight_order first for safety, and implies this is for single-leg orders (contrasting with place_multileg_order). However, it does not explicitly state when not to use this tool (e.g., for multi-leg orders or other non-single-leg scenarios).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true and destructiveHint=false. The description adds that the tool returns estimated fees, buying power, and margin impact, and emphasizes no order placement. This contextualizes the read-only behavior well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by a summary of outputs, then a well-organized parameter list. Every sentence adds value; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 params, 4 required) and the presence of an output schema, the description fully covers all parameters and their constraints. It provides necessary context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the full burden. It provides detailed inline explanations for all 14 parameters, including defaults, mutual exclusivity (quantity vs amount), required conditions (e.g., limit_price for LIMIT), and constraints on tax_lot_matching_instructions. This adds significant meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Estimate costs and impact of a potential single-leg trade before placing it.' This clearly identifies the verb (estimate), resource (costs/impact), and distinguishes from sibling tools like place_order (which places) and preflight_multileg_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains it returns estimates and does NOT place the order, providing clear context. However, it does not explicitly exclude other preflight tools or specify when not to use; sibling differentiation is implied by 'single-leg trade'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description reinforces that it is a side-effect-free estimation tool and adds that it 'Does NOT place an order.' It also explains the credit received nature. No contradictions exist, and the description adds context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a clear one-line purpose, a brief strategy explanation, a key behavioral note, and a bulleted list of parameters. It is concise with no unnecessary text. The critical information is front-loaded, and the format is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
All 7 parameters are described, with 4 required parameters clearly noted. The tool's read-only nature, credit computation, and order prevention are covered. An output schema exists (as per context signals), so the return value is handled externally. The description is complete for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates fully. It provides detailed explanations for each parameter in the Args section, including the role of sell_contract_osi (higher strike) and buy_contract_osi (lower strike), limit_price semantics (positive = credit received), time_in_force options (DAY or GTD), and conditional requirements for expiration_time. This adds substantial meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Estimate costs for a Bull Put Spread (put credit spread) before placing it.' It clearly identifies the action (estimate), the resource (put credit spread), and the context (before placing). The title 'Preflight Put Credit Spread' aligns with the purpose, and the sibling set distinguishes it from other preflight and placement tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Does NOT place an order,' guiding when not to use this tool. It explains the mechanics (sell higher-strike, buy lower-strike) and mentions receiving a net credit. While it does not explicitly compare to other preflight tools, the pair structure and type are clearly defined, making the usage context reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and destructiveHint annotations, the description adds useful behavioral details: it returns a page object with content, totalElements, and totalPages, notes that min_maturity_date defaults server-side to today + 14 days, and specifies default page_number, page_size, and sort_direction. This provides context beyond annotations, though it does not mention rate limits or max page size.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description opens with a one-sentence summary, then a brief note on filter combination and return object, followed by a well-structured list of all 28 parameters with one-line explanations. It is long but every line adds value, and the formatting is consistent and front-loaded with the summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 28 parameters, no schema descriptions, and an output schema, the description is complete: it covers all parameters, valid values, defaults, return shape, and the fact that all filters are optional. The output schema exists, so the return structure need not be detailed further. No significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining every parameter with examples (e.g., issuer_symbol ['AAPL']), valid enum values (e.g., bond_status list), defaults (page_number, page_size, sort_direction, min_maturity_date), and type constraints (numeric string). This is essential for correct invocation and is exemplary given the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Filtered, paged search for fixed income (bond) instruments' with a specific verb and resource, making it clear this tool searches bonds with filtering and pagination. This distinguishes it from siblings like get_bond_details (which likely fetches a single bond) and get_all_instruments (which may list all instruments).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'All filters are optional; combine them to narrow down results' and describes pagination, giving clear context on when to use this tool for finding bonds that meet certain criteria. However, it does not explicitly name alternative tools or state when not to use this tool, which could improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint=true), the description reveals it's a two-step non-atomic workflow with potential market changes between steps, and that both orders execute as real trades. It also clarifies the skip behavior for missing long positions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a clear purpose statement, a warning paragraph, and a parameter list. It is front-loaded. Some redundancy could be trimmed (e.g., 'Args' header), but overall efficient for a complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (two-step workflow, 10 params) and presence of an output schema, the description covers the workflow, safety warnings, and parameter roles comprehensively. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning no parameter descriptions in the schema. The description provides meaningful explanations for all 10 parameters (e.g., 'short_quantity: Number of shares to short after flattening'), adding essential context beyond titles and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Sell any existing long position in a symbol, then place a short-sale order', which is a specific verb+resource combination. It distinguishes from sibling tools like 'place_short_order' that presumably do not flatten first.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that if no long position exists, the flatten step is skipped. It warns about the non-atomic experimental nature. However, it does not explicitly state when to use this tool versus alternatives (e.g., 'place_short_order'), though the context implies it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description reinforces this by stating it is 'a read-only quote — it does NOT place or preflight an order,' adding behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening and parameter breakdown. While comprehensive, it is slightly lengthy; some details could be tightened without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of multi-leg options, the description covers all necessary aspects: parameters, optional fields, leg structure, and the read-only nature. An output schema exists, so return values need not be explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully documents all parameters, including the complex option_legs structure with required fields, optional fields, and an example. It explains each parameter's role clearly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Get a consolidated quote for a multi-leg option strategy.' It distinguishes itself from siblings by clarifying it is a read-only quote and does not place or preflight orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use (for pricing strategies) and explicitly states what it does not do (place/preflight order). However, it does not provide explicit when-not-to-use guidance or list alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the return is a file object with fileName and base64Data, that the CSV is Base64-encoded, and that the API key must have trading.read scope. This adds significant behavioral context beyond the readOnlyHint and destructiveHint annotations and does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tight and front-loaded: purpose, return format, encoding, auth requirement, and parameter fallback are each covered in a few clear sentences with no filler. It earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter export tool, the description fully covers purpose, output shape, encoding, auth, and optional parameter resolution. The output schema exists, but the return-format detail is still beneficial and does not leave gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter with no description, and schema description coverage is 0%. The description's Args section compensates by noting account_id is optional and falls back to PUBLIC_COM_ACCOUNT_ID when set, adding operational meaning beyond the schema's default:null.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Export the unrealized tax lots as a CSV file', using a specific verb and resource. The 'CSV' format clearly distinguishes it from sibling tools like get_tax_lots and get_tax_lots_for_symbol.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: to export unrealized tax lots as a CSV file. It also states the required trading.read scope. However, it does not explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Warns that the tool executes a real trade, which is critical behavioral context beyond annotations (which only indicate not read-only or destructive). Additional details like net credit are helpful; could elaborate on trade irreversibility but sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured: title, strategy explanation, warning, then parameter list. No wasted words; each sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the essential aspects: what it does, how to use it, and when to use preflight. Could mention that this is a bearish strategy, but the title implies it. Output schema exists, so return values are covered. Complete for the task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter's meaning, constraints (e.g., 'lower strike' for sell, 'minimum net credit' for limit_price), and optionality, adding significant value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states it places a Bear Call Spread, describes the mechanics (sell lower strike, buy higher strike, net credit), and is distinct from sibling tools like call debit spreads or put spreads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly warns that this executes a real trade and recommends running preflight_call_credit_spread first, providing explicit when-to-use and alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-read-only, non-destructive, non-idempotent, open world. The description adds critical context: 'executes a real trade', which goes beyond the annotations by alerting about real financial risk. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (under 100 words), uses bullet points for args, and front-loads the purpose. Every sentence adds value, and the structure is clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, real trade execution) and that output schema exists, the description covers behavior, all parameters, and critical usage warnings. No gaps were identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It explains each parameter's role (e.g., sell_contract_osi: call to sell, higher strike; quantity: number of spreads) and provides defaults for time_in_force and expiration_time, effectively compensating for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as placing a Bull Call Spread, specifying the action (buy lower strike, sell higher strike) and distinguishing it from credit spreads. The title also reinforces this.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It warns that this executes a real trade and explicitly suggests using preflight_call_debit_spread first for testing, providing clear when-to-use and when-not-to-use guidance. Sibling tools are listed for context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds that it estimates costs and does not place an order, reinforcing safety. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with a brief overview followed by parameter list. Every sentence adds value. Could potentially shorten the parameter descriptions slightly, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description doesn't need to explain return values. All parameters are documented with semantics, usage guidance clear, and no behavioral gaps. Completely adequate for a 7-param tool with rich annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 7 parameters are described with meaning beyond schema: sell_contract_osi is lower strike, buy_contract_osi higher strike, limit_price is net credit (positive), time_in_force defaults to DAY, expiration_time required for GTD, account_id optional. Schema coverage 0% but description fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it estimates costs for a Bear Call Spread (call credit spread) before placing. Specifies sell lower-strike, buy higher-strike, net credit. Distinct from siblings like preflight_call_debit_spread and place_call_credit_spread.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'before placing it' and 'Does NOT place an order.' This distinguishes it from place_call_credit_spread. Also indicates when to use: to estimate costs, not to execute. No confusion with other preflight tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and non-destructive, but the description adds substantial behavioral detail: OHLCV bars split into sessions, previous close, total gain/loss, default trading session, and the leadingFill behavior for IPO assets. This goes well beyond the annotations and clarifies edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with an intro, purpose, and a clear Args list. While lengthy, each sentence provides necessary detail—from session definitions to IPO edge-case behavior—with no filler. The front-loaded purpose and organized parameter breakdown make it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, multiple session modes, IPO special cases) and the presence of an output schema, the description covers all essential usage context. It also distinguishes this tool from close siblings and explains conditional requirements, making it fully self-sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, so the description carries the full burden of explaining parameters. It thoroughly explains every parameter, including valid values, defaults, and dependencies (e.g., IPO date behavior, aggregation constraints, trading session options). This fully compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Get historical OHLCV price bars for a symbol over a time period,' using a specific verb and resource. It further distinguishes itself from siblings by explicitly contrasting with get_quotes (current price only) and get_history (account activity), making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('for trend analysis and historical prices') and names alternatives with their different scopes. It also provides operational guidance, such as preferring to omit aggregation and noting the purchase_date requirement for SINCE_PURCHASE.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![publicdotcom-mcp-server MCP server](https://glama.ai/mcp/servers/PublicDotCom/publicdotcom-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/PublicDotCom/publicdotcom-mcp-server)

Score Badge

Copy to your README.md:

[![publicdotcom-mcp-server MCP server](https://glama.ai/mcp/servers/PublicDotCom/publicdotcom-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/PublicDotCom/publicdotcom-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/PublicDotCom/publicdotcom-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server