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, 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?

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. 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?

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.