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

No annotations are present, so the description bears the full burden. 'Get' implies a read-only operation, and the content of results is stated, but the description does not disclose how the optional portfolio_id behaves (e.g., what null means), whether any rate limits or auth requirements exist, or any limitations of the analytics data.

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

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

A single sentence that front-loads the action and resource, then lists concrete facets of the result. No wasted words or redundant restatements.

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

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

An output schema exists, so return values are covered. The tool is simple with one optional parameter, but the missing parameter semantics and lack of differentiation from sc_overview leave an agent with enough ambiguity that the definition is merely adequate, not complete.

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

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

Schema description coverage is 0%, and the description never mentions portfolio_id or its meaning. The parameter name is self-explanatory, and there is only one optional parameter, but the description fails to clarify what a null value or omitted parameter resolves to, leaving the agent to guess.

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

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

The description uses a specific verb ('Get') and resource ('Scalable Capital portfolio analytics') and enumerates precise deliverables: allocation breakdowns, sector/region exposure, and performance attribution. This clearly distinguishes it from siblings like sc_holdings and sc_overview.

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

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

The description implies when to use the tool: whenever portfolio-level analytics are needed. However, it provides no explicit guidance about when not to use it or how it differs from sc_overview, which could also plausibly provide portfolio-level data.

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

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

With no annotations provided, the description carries the full burden. It discloses that it retrieves version, supported commands, exit codes, and local trade controls, which are behavioral details. However, it does not mention aspects like whether it requires authentication, any side effects, or data freshness. A bit more context on behavior would be beneficial.

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

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

The description is extremely concise, just one sentence that front-loads the purpose and succinctly lists the contents. Every word adds value; there is no redundancy or filler.

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

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

Given the tool has no parameters, an output schema exists, and it's a simple informational retrieval tool, the description is quite complete. It covers what the tool returns and is sufficient for an agent to understand its use. A little more detail on the format or when to use it would push to a 5, but it's adequate.

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

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

The tool has zero parameters and schema description coverage is 100%, so there is no parameter information needed. With no params, a baseline of 4 is appropriate, and the description does not add extra parameter semantics because none are required.

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

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

The description starts with a clear verb 'Get' and specifies the exact resource 'Scalable Capital CLI capability dump'. It lists the contents: version, supported commands, exit codes, and local trade controls, making the tool's purpose unmistakable. It also differentiates itself from sibling tools that focus on other aspects like watchlist, holdings, or transactions.

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

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

The description implies usage context by stating it gets the CLI capability dump, which is informational for understanding tool capabilities. However, it does not explicitly say when to use this tool versus alternatives, nor does it provide any exclusions or scenarios where it should be avoided.

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

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

No annotations are provided, so the description carries the full burden. It states the output components and that the response is 'compact,' but does not disclose whether data is real-time or cached, access prerequisites, rate limits, or side effects. Minimal but acceptable for a read-only tool.

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

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

Two sentences effectively front-load the purpose and a usage tip. Every sentence earns its place with no superfluous content.

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

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

An output schema exists, so return values are partially covered. The description lists the key fields (buying power, cash, credit, derivatives). However, the single parameter is not addressed, reducing completeness. With many sibling tools, the description provides enough context to distinguish this one.

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

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

The input schema has one optional parameter (portfolio_id) with 0% schema description coverage. The description completely omits any mention of this parameter, failing to add meaning beyond the schema. It does not explain what the parameter does or its default behavior, leaving a gap for the agent.

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

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

The description clearly states the tool 'Get Scalable Capital cash breakdown' and lists specific components (buying power, available cash, credit, derivatives availability). This verb+resource combination is distinct and unambiguous among the sibling tools, none of which overlap with this function.

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

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

The description explicitly advises 'Use before placing orders to check available funds,' providing a clear use case. It does not mention when not to use or alternatives, but the context is sufficient for an AI agent to understand the primary scenario.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It correctly indicates this is a data retrieval operation ('Get historical chart data'), but does not explicitly state that it is read-only or non-destructive. There is no mention of authentication requirements, rate limits, or what happens if the ISIN is invalid. The description is adequate but not thorough.

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

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

The description is two sentences totaling about 30 words, front-loading the main action and then providing use cases. Every sentence adds value, but the second sentence could be more specific (e.g., listing example timeframes). It is otherwise concise and well-structured.

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

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

Given the tool's moderate complexity (3 params, 1 required, output schema exists), the description is minimally complete. It explains what data is returned (OHLCV) and the identifying parameter (ISIN), but omits parameter details for timeframe and portfolio_id. The output schema presumably describes the return structure, but the description should still mention key aspects like time periods or data frequency.

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

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

Schema description coverage is 0%, so the description must add meaning for all 3 parameters. It only mentions 'by ISIN' for the required isin parameter, providing no details about the 'timeframe' (e.g., valid values like '1d', '1w') or 'portfolio_id' (its purpose or when to use). The description fails to compensate for the lack of schema descriptions.

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

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

The description clearly states the tool retrieves 'historical chart data (OHLCV) for a security by ISIN' from Scalable Capital, specifying the use cases of technical analysis, trend detection, and price history review. It distinguishes itself from siblings like sc_quote (likely current price) and sc_search (finding securities). A slight deduction for not clarifying that it's read-only, which is implicit but could be more explicit given the output schema.

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

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

The description mentions using it 'for technical analysis, trend detection, or price history review,' which gives context on when to invoke it. However, it does not explicitly state when not to use it (e.g., for real-time quotes vs. historical data) or mention alternatives among siblings like sc_quote for current pricing. No explicit exclusion or alternative guidance.

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

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

With no annotations, the description carries full burden but only discloses that the tool returns derivative ISINs (implied by 'Use returned derivative ISIN'). It does not state read-only nature, error behavior, pagination (despite limit/offset parameters), or authentication requirements. The hint about requiring a 'known underlying ISIN' is helpful but insufficient.

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

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

Two sentences: one for purpose, one for next step. No redundancy, every word adds value. Perfectly front-loaded with the core action and context.

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

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

Despite an output schema existing, the description omits explanation of 6 parameters (3 required) and their acceptable values. The lack of schema descriptions places the burden entirely on the descriptive text, which fails to cover the input requirements needed for correct invocation.

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

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

Schema description coverage is 0%, yet the description provides no parameter-level details. It mentions 'underlying ISIN' but does not explain derivative_type, strategy, limit, offset, or portfolio_id. The agent must infer acceptable values from the separate example parenthetical, which is ambiguous.

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

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

The description clearly states the tool searches for derivatives (knockouts, warrants, factors) on a known underlying ISIN, using a specific verb ('Search') and resource. It distinguishes from siblings like sc_search by narrowing the scope to derivatives and explicitly connecting to sc_quote for pricing.

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

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

The description specifies the context: search for derivatives given a known underlying ISIN, and advises using sc_quote for pricing. However, it does not explicitly contrast with alternatives (e.g., when to use sc_search instead), nor does it mention prerequisites or exclusions.

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

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

With no annotations, the description carries the full burden, but it only states that data is live and includes prices, quantities, and market values. It does not disclose authentication needs, rate limits, error behavior, pagination, or how optional parameters affect the response.

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

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

The description is two tight sentences with the core action and payload front-loaded. Every clause earns its place, and there is no redundant filler.

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

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

Although an output schema exists, the description omits critical context for two optional parameters and gives no usage guidance versus sibling tools. For a broker data tool with no annotations, this is too thin to fully support correct invocation.

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

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

Schema description coverage is 0%, and the description adds no meaning for include_ytd or portfolio_id. Both parameters are left entirely undocumented, so an agent cannot infer what values to provide or what effect they have.

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

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

The description uses a specific verb and resource: 'Get Scalable Capital portfolio holdings' and clarifies the payload with 'all positions with current prices, quantities, and market values.' It is clear enough to distinguish from siblings like sc_transactions or sc_quote, though it does not explicitly name those alternatives.

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

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

The description implies the tool should be used when portfolio position data is needed, especially with 'Live broker data' signaling current values. However, it does not provide explicit guidance about when to choose this over sc_overview, sc_analytics, or sc_quote, nor does it mention any exclusions.

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

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

Without annotations, the description clearly discloses the auto-resolution behavior, which is a key behavioral trait. It does not mention any destructive effects, authentication needs, or rate limits—but none are expected for a read-only summary tool, so the disclosure is adequate.

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

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

The description is extremely concise: two sentences, zero filler. The first sentence states the core purpose, and the second sentence adds a critical behavioral clarification. Every word earns its place.

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

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

Given that the tool has only one optional parameter and an output schema exists, the description is nearly complete. It covers purpose, auto-resolution behavior, and expected return data. A minor gap is not explaining the output schema's structure, but that's mitigated by the schema itself.

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

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

Schema description coverage is 0%, so the description should compensate. The description mentions that an account ID can be omitted for auto-resolution, which adds meaning beyond the schema's nullable optional parameter. However, it does not explain how to find the ID if needed, leaving the parameter semantics partially underdefined.

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

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

The description clearly states the verb 'Get', the resource 'Scalable Capital overnight savings account summary', and the specific data returned ('balance and interest rate'). It also includes an automatic resolution behavior that distinguishes it from siblings.

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

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

The description explicitly mentions that the account is auto-resolved when exactly one active account is accessible, which helps the agent understand when no parameter is needed. However, it does not explicitly describe when not to use this tool or mention alternatives among siblings.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the tool lists transactions with filters, but does not mention read-only nature, authentication requirements, rate limits, pagination details, or data freshness. The schema implies pagination via cursor and page_size, but the description does not explain this behavior.

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

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

The description is extremely concise: two sentences, front-loaded with the main purpose, and no superfluous words. Every sentence adds value, meeting the 'earn its place' criterion.

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

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

Given the tool has 7 parameters, no schema descriptions, and an output schema, the description is far from complete. It does not explain pagination, time filtering, search, or the return format. The output schema exists but the description offers no hints about what the tool returns.

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

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

Schema description coverage is 0%, so the description must compensate. It only mentions type_filter='interest' as an example, but leaves 6 other parameters (cursor, to_time, from_time, page_size, search_term, savings_account_id) completely unexplained. The description adds minimal value beyond the schema field names.

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

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

The description clearly states the tool lists overnight savings account transactions with filters, using a specific verb ('List') and resource ('overnight savings account transactions'). The example with type_filter='interest' further clarifies the purpose. It distinguishes from sibling tools like sc_transactions by specifying 'overnight savings account'.

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

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

The description provides a concrete usage example ('Use type_filter='interest' to review interest payment history'), which implies a scenario. However, it does not explicitly state when to use this tool versus alternatives (e.g., sc_transactions for general transactions), nor does it offer exclusions or prerequisites. The guidance is helpful but sparse.

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

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

With no annotations provided, the description carries the burden of behavioral context. It adds useful information by stating that data is live and comes directly from the broker, and 'Get' implies a read operation. However, it does not disclose auth requirements, caching behavior, or how optional parameters affect the behavior.

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

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

The description is two sentences with no filler: it front-loads the resource and core fields, then adds a useful behavioral note about live data. Every sentence earns its place.

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

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

The tool has low complexity and an output schema, so the description does not need to document return values. However, it is incomplete regarding parameter behavior and portfolio selection, and it offers no hints about when this overview is the right choice among sibling tools. It is adequate for a basic read, but still has clear gaps.

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

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

Schema description coverage is 0%, so the description must compensate for the two undocumented parameters, but it does not explain include_ytd or portfolio_id. The schema titles are self-explanatory to a degree, but the description adds no meaning beyond them, leaving agents to guess how these options shape the request or response.

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

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

The description clearly states the tool fetches a Scalable Capital broker portfolio overview and names its key contents: total value, cash, and performance. It does not explicitly distinguish itself from siblings like sc_holdings or sc_analytics, but the word 'overview' and listed fields make the aggregate-level purpose reasonably clear.

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

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

No guidance is given for when to prefer this tool over siblings such as sc_holdings, sc_transactions, or sc_analytics. The description implies it is for high-level portfolio summaries, but it never states exclusions or alternatives, leaving selection to inference.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It reveals an important side effect ('auto-removes from other groups') and a prerequisite (environment variable). However, it does not mention what happens if the group does not exist, whether the operation is reversible, or any validation behavior. This is adequate but incomplete.

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

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

Two sentences with no filler: first sentence states the action and key behavior, second states a requirement. This is efficient and front-loaded. Could be improved by adding parameter context without becoming verbose, but overall it is well-structured.

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

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

The tool has 3 parameters, no annotations, and an output schema. The description covers the core action and a side effect, but omits parameter meanings and usage conditions. An agent would need to guess or rely on parameter names alone, which is insufficient for confident invocation. Completeness is notably lacking.

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

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

Schema description coverage is 0%, so the description must compensate. It does not explain any parameter: 'isins', 'group_id', or 'portfolio_id' are left undefined. The term 'holdings' in the description loosely maps to 'isins', but the connection is not explicit. No parameter-level semantic help is provided.

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

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

The description clearly states 'Assign holdings to a portfolio group' which uses a specific verb and resource. The added note 'auto-removes from other groups' distinguishes it from siblings like sc_portfolio_group_unassign and sc_portfolio_group_create, making the purpose unambiguous.

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

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

No explicit guidance on when to use this tool versus alternatives (e.g., sc_portfolio_group_unassign). The auto-removal hint implies a moving use case, but there is no direct comparison or scenario description. The agent must infer usage context from the bare action description.

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

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

No annotations are provided, so the description fully carries the burden of behavioral disclosure. It conveys that the tool is a write operation but lacks details on side effects, authentication needs, or any constraints beyond the env variable.

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

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

The description is a single, concise sentence with no wasted words. It front-loads the core purpose and adds necessary usage context efficiently.

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

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

With 3 parameters, no annotations, and an output schema present, the description is too sparse. It does not address what the output schema returns or clarify semantics of missing parameter details, leaving significant gaps for a creation tool.

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

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

Schema description coverage is 0%, so the description must compensate but does not explain any parameter meaning. It does not mention that 'name' is required or what 'description' or 'portfolio_id' represent, leaving the agent to infer from parameter names alone.

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

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

The description clearly states 'Create a new portfolio group', using a specific verb and resource. It distinguishes from siblings like sc_portfolio_group_update and sc_portfolio_group_delete, though it does not explicitly differentiate from other create tools.

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

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

The description mentions an environment requirement ('Requires SC_MCP_ENABLE_WRITES=true'), which provides context for when to use this tool, but it offers no guidance on when not to use it or alternatives.

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

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

The description discloses the behavioral effect of the deletion ('Holdings return to ungrouped'), which is important context beyond a simple delete. No annotations are provided, so the description carries the full burden; it does well but could add more about irreversibility or authorization scope.

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

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

The description is two concise sentences, front-loading the action and effect, and adding the prerequisite in the second sentence. Every word earns its place.

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

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

Given the low parameter count, no nested objects, and the presence of an output schema (implying return structure documented elsewhere), the description covers the key need. It misses a bit on completeness by not explaining the optional portfolio_id parameter, but overall is sufficient.

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

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

Schema description coverage is 0%, so the description must compensate. The description does not detail the two parameters (group_id, portfolio_id) or explain the optional portfolio_id parameter's role. However, with only 2 parameters and 1 required, the simple action is somewhat self-explanatory, so a baseline of 3 is appropriate.

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

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

The description clearly states 'Delete a portfolio group' which is a specific verb and resource. It also provides a side-effect ('Holdings return to ungrouped') that distinguishes this from other related sibling tools like sc_portfolio_group_create or sc_portfolio_group_update.

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

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

The description explicitly notes a prerequisite: 'Requires SC_MCP_ENABLE_WRITES=true', warning the agent that this is a write operation and needs an environment flag enabled. This provides clear guidance on when the tool can be used.

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

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

With no annotations provided, the description carries the full burden of disclosing behavioral traits. It mentions the tool returns performance attribution and an ungrouped list, but does not state whether it is read-only (implied by 'Get'), whether it requires any authentication scopes, or what happens if parameters are omitted. Adequate but not thorough.

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

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

The description is a single, information-dense sentence that conveys the key purpose and output features without any filler. Every phrase adds value.

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

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

The tool is relatively simple (get operation, 2 optional params, output schema exists). The description adequately covers what is returned (custom groups with performance, ungrouped list), though parameter details are missing. Given the presence of an output schema that likely details the return structure, this is sufficient.

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

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

Schema description coverage is 0%, and the description does not explain what 'group_id' or 'portfolio_id' mean, their valid formats, or their effect on the response. Baseline 3 is given due to 0% coverage; the description could have compensated with parameter details but did not.

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

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

The description clearly states the tool retrieves Scalable Capital portfolio groups, including custom groupings with since-buy performance attribution and an ungrouped holdings list. It distinguishes itself from siblings like sc_holdings (which likely just lists holdings without grouping) and the mutating sc_portfolio_group_* tools.

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

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

The description does not specify when to use this tool versus alternatives like sc_holdings for raw holdings, sc_overview for portfolio summary, or sc_portfolio_group_create for modifying groups. No exclusions or prerequisites are mentioned.

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

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

With no annotations provided, the description bears the full burden. It discloses that the tool performs a write operation that removes a holding from a group. However, it does not mention error conditions (e.g., if the holding is not in the group), side effects, or reversibility. The existence of an output schema somewhat compensates, but the description offers minimal behavioral context beyond the operation's basic effect.

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

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

The description is two sentences totalling under 25 words. Every word is functional: the first states the operation, the second states a prerequisite. There is no redundancy or fluff.

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

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

Given the tool has 3 parameters (2 required) and an output schema, the description covers the core operation and a key requirement. However, it does not explain parameter meaning or error handling. For a simple mutation tool, this is minimally adequate but leaves gaps that the agent must infer from parameter names alone.

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

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

Schema description coverage is 0%, so the description must add meaning to the three parameters. The description does not explain what 'isin', 'group_id', or 'portfolio_id' represent. For example, it is unclear whether 'portfolio_id' is needed when unassigning from a group or what its relation is to the group. This omission limits the agent's ability to use the tool correctly.

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

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

The description clearly states the verb 'Remove' and the resource 'a holding from a portfolio group', with the clarifying parenthetical 'returns it to ungrouped'. This differentiates from sibling tools like sc_portfolio_group_assign (which does the opposite) and sc_portfolio_group_delete (which deletes the group itself).

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

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

The description provides a clear prerequisite (requires SC_MCP_ENABLE_WRITES=true), but it does not explicitly state when to use this tool versus alternatives like sc_portfolio_group_assign or when not to use it. The context is clear, but exclusions or comparative guidance are missing.

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

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

The description explicitly states this is a write operation by requiring SC_MCP_ENABLE_WRITES=true, which is important for the agent to know. However, with no annotations provided, the description does not disclose other behavioral aspects such as whether the update is partial or complete replacement, what happens to fields not mentioned (e.g., portfolio_id, clear_description), or any side effects (e.g., cascading updates).

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

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

The description is a single sentence followed by a critical prerequisite, which is efficient and well-structured. It front-loads the main action. Minor points: could be slightly more verbose to cover the missing parameters, but not significantly padded.

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

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

The tool has 5 parameters with zero schema coverage, no annotations, and an output schema exists but is not described. The description only covers 2/5 parameters and omits explanation of clear_description, portfolio_id, and the partial-update behavior. For a write/mutation tool in a system with several sibling portfolio operations, this is insufficient for the agent to use it correctly without guessing.

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

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

Schema description coverage is 0%, so the description must compensate but only mentions 'name/description'. The schema has 5 parameters (name, group_id, description, portfolio_id, clear_description) with complex types (anyOf, defaults). The description does not explain the purpose of portfolio_id or clear_description, nor does it clarify that group_id is required while others are optional with defaults. This leaves significant ambiguity for the agent.

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

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

The description clearly states the verb 'Update' and the resource 'portfolio group', and specifies the modifiable fields 'name/description'. It distinguishes this from siblings like sc_portfolio_group_create and sc_portfolio_group_delete, though it could explicitly name the create/delete siblings for comparison.

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

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

The description provides one essential usage prerequisite: the environment variable 'SC_MCP_ENABLE_WRITES=true' must be set. However, it does not guide on when to use this update tool versus alternatives like sc_portfolio_group_assign/unassign, nor does it mention any context-specific conditions (e.g., does the user need to be owner/admin?).

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

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

With no annotations, the description carries the full burden. It mentions the write permission requirement, but does not describe side effects, error handling, or what happens if both or neither isin/ticker are provided. Partial transparency.

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

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

Two concise sentences with no filler. Directly states purpose, usage condition, and permission requirement. Excellent structure.

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

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

Tool is simple, and output schema exists, so return values need not be explained. However, the description omits the portfolio_id parameter and does not clarify error scenarios or mutual exclusivity of isin/ticker, making it incomplete for full usage.

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

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

Schema coverage is 0%, so description must compensate. It explains isin and ticker partially (must provide one), but does not explain price (units, meaning) or portfolio_id. Compensation is insufficient.

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

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

Clearly states the action ('Add a price alert') and resource ('price alert'), distinguishing it from sibling tools like sc_price_alert_remove. The description is unambiguous.

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

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

Provides a condition for usage ('Provide either isin or ticker') and a prerequisite (SC_MCP_ENABLE_WRITES=true). However, it does not explicitly mention alternatives or when to use this tool over others, though the name and purpose make it implicit.

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

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

No annotations are provided, so the description carries full burden. It only mentions the write-env requirement and the destructive action. It does not disclose resuls on success/failure, irreversibility, permission needs, or any side effects beyond the obvious removal.

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

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

Two short sentences: the first states the action, the second notes a required environment variable. No filler, perfectly front-loaded, and every sentence earns its place.

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

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

For a simple removal tool with an output schema, the description is adequate but not complete. It doesn't mention irreversibility, what happens if the alert doesn't exist, or when the portfolio_id parameter is needed. Given the tool's low complexity, this is minimally sufficient but has clear gaps.

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

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

Schema description coverage is 0%, meaning the input schema has no parameter descriptions. The description adds no explanation for alert_id or portfolio_id beyond their names. It fails to compensate for the missing schema-level documentation, leaving ambiguity about the portfolio_id field.

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

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

The description clearly states the verb 'Remove' and the resource 'price alert by ID'. This distinguishes it from sibling tools like sc_price_alert_add (add) and sc_price_alerts (list), making the purpose immediately obvious.

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

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

The description includes a clear prerequisite (requires SC_MCP_ENABLE_WRITES=true) and implies usage for deleting specific alerts. No explicit when-not or alternatives, but the name and sibling context provide sufficient guidance.

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

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

No annotations provided, so the description carries full burden. It only states 'get' and 'optionally filtered', with no mention of authorization, side effects, response behavior, or what happens with invalid parameters.

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

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

The description is a single, concise sentence. It front-loads the core action. Could be improved by adding a brief usage note, but it is not verbose.

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

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

Given the presence of an output schema, return value details are not required, but the tool has two optional parameters and many sibling tools. The description lacks disambiguation, guidance on portfolio_id, and any usage context, leaving gaps for an AI agent.

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

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

Schema description coverage is 0%, so the description should compensate. It implicitly references 'active ones' for active_only but does not explain the portfolio_id parameter or its effect, adding minimal value beyond the schema itself.

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

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

The description clearly states it is a read operation ('Get Scalable Capital price alerts') and mentions optional filtering. It distinguishes from sibling mutation tools like sc_price_alert_add and sc_price_alert_remove, but doesn't differentiate from other read tools.

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

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

No guidance on when to use this tool versus alternatives. It does not explain when to filter by active_only or portfolio_id, nor does it mention any prerequisites or exclusions.

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

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

With no annotations, the description carries the full burden. It clearly implies a read-only quote lookup, but it does not disclose quote freshness, data source, authentication expectations, or error behavior. The core behavior is transparent enough for a simple lookup, but additional context is missing.

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

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

One concise sentence, front-loaded with the action and resource, with no filler or redundant information.

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

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

The description covers only the core lookup behavior and the required parameter. It omits any explanation of the two optional parameters and does not provide enough context for an agent to know when to set them. Though an output schema exists, the optional-parameter gap leaves the definition incomplete.

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

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

Only the 'isin' parameter is meaningfully explained, and only incidentally through the phrase 'by ISIN.' The optional 'include_ytd' and 'portfolio_id' parameters are completely undocumented, and schema description coverage is 0%, so the description does not compensate for the gap.

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

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

The description specifies a clear verb and resource: 'Get the current Scalable Capital quote for a security by ISIN.' It is distinct from the sibling tools in function, but it does not explicitly differentiate itself from alternatives like sc_search or sc_holdings.

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

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

Usage is only implied: if an agent needs a current quote by ISIN, this is the tool. There is no explicit guidance on when to use this over siblings, nor any mention of related lookup tools such as sc_search.

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

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

Annotations are absent, so the description carries the full burden. It explicitly states 'Read-only,' which is a key behavioral trait for an AI agent deciding whether to call safely. It does not disclose any side effects, auth requirements, rate limits, or what happens if the isin is invalid. The description adds 'Read-only' value but is sparse on other behavioral details.

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

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

The description is two short sentences—no wasted text. The first sentence defines the action, the second clarifies read-only behavior and intended timing. Every word earns its place.

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

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

The tool has an output schema (not shown in detail), so return value explanation is partially covered there. However, the description does not explain what 'ex-ante fee disclosure' means or what happens if isin is missing or invalid. Given the complexity (2 params, output schema exists), the description is minimally complete but lacks detail on error conditions or default behavior for portfolio_id.

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

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

Schema description coverage is 0%, meaning the description must compensate for the two parameters (isin, portfolio_id). The description does not mention either parameter by name, but it implies isin via 'for a security.' portfolio_id (optional, default null) is not addressed at all. Given 0 coverage, the description should provide more param context, but the tool is simple enough that the schema itself (with types and required flag) does some work. I credit it partially for implying isin's role, leading to 4.

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

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

The description states it gets 'valid savings-plan configuration and ex-ante fee disclosure' for a security, which is a clear verb and resource. It distinguishes from siblings—none of the sibling tools (e.g., sc_watchlist, sc_transactions) mention savings plans, so this tool is uniquely positioned.

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

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

The description says 'use before deciding on a savings plan,' giving clear timing context. However, it does not explicitly mention when not to use it or compare to alternative tools for savings plan actions (like creating or modifying plans), which might exist outside the sibling list. Usage guidance is implied but lacks exclusion criteria.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states a scope and gives no information about search semantics, authentication, rate limits, result format, pagination, or side effects. The word 'Search' implies a safe read, but that is not made explicit.

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

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

The description is a single concise sentence with no filler or repetition. It is appropriately short for a simple tool, though the brevity comes at the cost of missing useful behavioral and parameter detail.

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

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

Given that the tool has only two parameters and an output schema, the description is not overly complex to write, yet it leaves key context unexplained. An agent would not know what kind of security identifiers to pass, how portfolio_id modifies the search, or what type of results to expect beyond what the output schema might provide.

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

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

Schema description coverage is 0%, and the description mentions neither 'query' nor 'portfolio_id'. It does not explain what 'query' should contain, whether it matches ticker names, company names, or other identifiers, or what effect the optional portfolio_id has on the search.

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

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

The description states a specific verb and resource: 'Search securities' within the 'Scalable Capital broker portfolio context.' This clearly conveys the core action, though it does not explicitly differentiate the tool from siblings like sc_quote or sc_holdings.

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

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

The phrase 'within the Scalable Capital broker portfolio context' implies a scoped search use case, but no explicit guidance is given about when to use this tool versus alternatives such as sc_quote or sc_holdings. There are no stated exclusions or conditions that would help an agent choose between siblings.

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

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

With no annotations provided, the description must carry the behavioral disclosure burden. 'Get' implies read-only behavior and 'latest news summary' implies a return type, but the description does not disclose behavior around empty results, locale effects, staleness, or any operational constraints.

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

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

The description is a single, well-structured sentence that front-loads the action and resource. Every word contributes meaning, with no redundancy or filler.

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

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

The tool is relatively simple and has an output schema, so return values need not be described. Still, the absence of usage guidance, behavioral details, and locale semantics leaves some gaps for an agent invoking this tool in an unfamiliar context.

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

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

The description adds meaning to the primary parameter by saying the security is identified 'by ISIN'. However, schema description coverage is 0% and the locale parameter is not addressed beyond its schema default, leaving its purpose and accepted values under-specified.

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

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

The description states a specific verb ('Get'), a clear resource ('latest news summary'), and the key input ('by ISIN'), which makes the tool's purpose immediately obvious. It also distinguishes itself from siblings like sc_quote and sc_overview by targeting news rather than quotes or holdings.

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

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

The description implies when to use the tool: when a news summary for a security is needed. However, it provides no explicit guidance on when not to use it or which alternative sibling tool might be more appropriate in other scenarios.

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

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

With no annotations provided, the description carries the full burden. 'Get details' clearly conveys a non-mutating read operation, but there is no mention of permission requirements, response behavior, or any edge cases. This is adequate for a simple getter but not richly transparent.

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

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

The description is a single clear sentence with no filler. It immediately states the action, the object, the scope, and the lookup key, making it easy for an agent to parse.

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

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

The tool is simple and an output schema exists, so return-value details are not required. However, with no annotations and no usage guidance for the optional portfolio_id or the distinction from sc_transactions, the description leaves some gaps that an agent would need to infer.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies that transaction_id is the lookup key via 'by ID', but it does not explain the optional portfolio_id parameter or its purpose. Only one of two parameters receives semantic meaning.

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

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

The description uses a specific verb and resource: 'Get details for a single Scalable Capital broker transaction by ID.' It clearly distinguishes this singular fetch-by-ID tool from the sibling sc_transactions list tool, even without naming it explicitly.

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

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

The description implies the tool is for fetching one transaction when its ID is known, but it does not explicitly state when to prefer this over sc_transactions or how portfolio_id relates to use. Usage context is present but not elaborated.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It conveys a read-only 'List' operation but does not disclose pagination behavior, sorting, time formatting, or scope despite parameters like cursor, page_size, and to_time/from_time. This is minimal for a no-annotation tool.

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

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

Two sentences with no filler. The primary action is front-loaded and the use cases are concise. Every sentence earns its place.

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

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

While an output schema exists, the description is incomplete for a 7-parameter tool. It lacks parameter semantics, pagination guidance, and disambiguation from the similarly named sibling sc_transaction. An agent would need to inspect the schema deeply and still might not understand expected date or filter formats.

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

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

Schema description coverage is 0% and the description does not explain any of the seven parameters. The phrase 'optional filters' only hints at their existence and provides no meaning for isin, cursor, to_time, from_time, page_size, type_filter, or portfolio_id.

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

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

The description clearly states the verb 'List' and the resource 'Scalable Capital broker transactions', with optional filters. It is specific and actionable, but it does not explicitly differentiate itself from the sibling tool 'sc_transaction', which could plausibly be the single-transaction counterpart.

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

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

The description explicitly says when to use this tool: 'Use for reconciliation, tax analysis, or reviewing trade history.' This gives clear context and target use cases, though it does not mention alternatives or exclusions versus sc_transaction.

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

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

With no annotations, the description must disclose behavioral traits, but it only states the basic action. It does not mention data freshness, required permissions, side effects, or what the optional parameters influence.

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

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

The description is a single sentence with no wasted words. However, it is so minimal that it sacrifices useful information; slightly more detail would improve value without losing conciseness.

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

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

The tool has two optional parameters and an output schema, but the description provides no parameter explanations, usage context, or behavioral details. It is not complete enough for an agent to use correctly without further probing.

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

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

Schema description coverage is 0%, so the description should explain the parameters. However, it does not mention include_ytd or portfolio_id at all, leaving their meaning and impact unclear.

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

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

Description uses a specific verb ('Get') and resource ('Scalable Capital broker watchlist') and clearly distinguishes from sibling tools like sc_watchlist_add and sc_watchlist_remove by stating it retrieves 'all tracked securities.'

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

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

No guidance on when to use this tool versus alternatives like sc_holdings or sc_overview. Also lacks explanation of the optional parameters (include_ytd, portfolio_id) and their effect on the result.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It correctly indicates this is a write operation via the prerequisite, but does not describe side effects (e.g., whether adding duplicates fails silently or errors, whether it triggers any notifications, or if it requires user confirmation). The description adds value by requiring a write flag, but omits details about mutation consequences. Score 3 for adequate but not comprehensive behavioral coverage.

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

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

The description is two sentences long, directly front-loaded with the action, and includes critical prerequisite information without any unnecessary words. Every sentence serves a purpose. Score 5 for maximal efficiency.

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

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

The tool is moderately simple (2 parameters, 1 required, no nested objects) and has an output schema. The description covers the essential purpose and a prerequisite but lacks details on parameter semantics and behavioral nuances (e.g., error handling for invalid ISIN, duplicate detection). Given the availability of an output schema, the description could be leaner, but missing parameter explanations and behavioral context reduce completeness. Score 3: adequate but with clear gaps.

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

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

The schema description coverage is 0%, meaning the description must compensate. However, the description does not explain the parameters 'isin' or 'portfolio_id' beyond their names and types. It adds no meaning about what ISIN represents (e.g., International Securities Identification Number) or the role of portfolio_id (e.g., which watchlist to target if multiple exist). Baseline 3 is appropriate given no parameter info, and the description fails to add value here.

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

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

The description states the specific action ('Add a security to the Scalable Capital watchlist'), clearly identifying the verb (add) and resource (watchlist). However, it does not differentiate from sibling tools like sc_watchlist_remove or sc_watchlist (which might be a list view), missing an opportunity to distinguish itself. Score 4 because it's clear but lacks sibling differentiation.

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

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

The description includes an explicit prerequisite: 'Requires SC_MCP_ENABLE_WRITES=true', which informs the agent when this tool is usable. It does not specify when to use it versus alternatives like sc_price_alert_add or sc_transaction, but the prerequisite provides context for execution. Score 4 because it offers clear context without explicit exclusions or alternative guidance.

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

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

No annotations are provided, so the description must carry the full burden. It correctly indicates this is a write operation ('Remove') and discloses the required environment variable. However, it does not mention whether the operation is idempotent, what happens if the ISIN is not on the watchlist, or whether the output schema contains confirmation data. The minimal transparency is adequate but not thorough.

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

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

The description is two sentences with no wasted words. The first sentence states the tool's exact purpose, and the second covers a critical prerequisite. Every sentence earns its place, and the entire description is front-loaded and to the point.

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

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

Given the tool's two parameters (one optional), 0% schema coverage, and no annotations, the description is insufficient. It lacks context on the optional 'portfolio_id' parameter (e.g., default behavior, relationship to portfolios), does not address error scenarios (e.g., removing a non-existent entry), and does not leverage the existence of an output schema to set expectations. The description is too sparse for an agent to use this tool reliably without additional context.

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

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

Schema description coverage is 0%, so the description must compensate for explaining parameters. It does not mention 'isin' or 'portfolio_id' at all, nor explain their roles or defaults. While 'isin' is a standard identifier, the optional 'portfolio_id' is left entirely unexplained (e.g., what does null mean? Which watchlist does it affect?). This is a significant gap.

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

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

The description clearly states the verb ('Remove') and the resource ('security from the Scalable Capital watchlist'). This directly distinguishes it from sibling tools like 'sc_watchlist_add' (adds a security) and 'sc_watchlist' (presumably views the watchlist). The purpose is unambiguous and specific.

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

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

The description includes a prerequisite ('Requires SC_MCP_ENABLE_WRITES=true'), which is a usage guideline. However, it does not provide explicit guidance on when to use this tool versus alternatives (e.g., 'Use this to remove a single security; to add one, use sc_watchlist_add'). The context is implied by the tool name and siblings, but no direct instruction is given.

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