MAA Intelligence

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

With no annotations provided, the description carries the full behavioral disclosure burden and does so well by detailing the scope and update cadence of each data category, such as ClinicalTrials.gov updated weekly, PubMed daily, KIPRIS monthly, and KRX KIND daily. It is a read-style tool by nature, and the description's inventory makes the behavior predictable, though it does not cover error behavior or response size.

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 dense sentence but front-loads the core purpose and then organizes the profile contents in a logical catalog. Every clause adds concrete information; the only minor weakness is that the long list of parenthetical sources and update frequencies makes it heavier to parse than necessary.

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

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

Given that there is no output schema and no annotations, the description is remarkably thorough about what the returned profile will cover and how current the data is. It also prevents misuse by redirecting live-quote needs to get_stock_quote. It would be more complete with a note on response shape or error conditions, but those are not essential for correct tool selection.

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

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

Schema description coverage is 100%, so the input schema already fully explains 'identifier' and 'language.' The description does not add parameter-level meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Full profile of one company,' and then enumerates what that profile contains (overview, products, R&D, financials, regulatory record, trials, publications, patents, disclosures). It is clearly distinguished from get_stock_quote by naming the sibling explicitly for live quotes.

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 makes the primary use case explicit: retrieve a comprehensive profile of one company. It also provides a direct routing rule by stating 'For the live stock quote use get_stock_quote,' which is an explicit when-not alternative. This is sufficient even though other siblings are not individually 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 carries the behavioral disclosure burden. It goes beyond a simple 'gets a quote' by warning that prices are not durable and should not be treated as lasting values. This is relevant, though it does not mention potential rate limits or data latency beyond 'real-time.'

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

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

The description is compact and front-loaded: it states what the tool returns first, then adds the non-durability caveat. Every sentence carries value, with no redundant wording.

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 single-parameter tool with no output schema, the description covers the key return fields and warns about data freshness. An agent can reasonably infer the expected behavior, though exact output structure and formatting are not specified.

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

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

Schema coverage is 100%, and the identifier parameter is well explained with examples of company names, KRX tickers, and index slugs. The description adds no additional parameter meaning, so the baseline of 3 applies.

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

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

The description clearly identifies the resource ('stock quote for one indexed company') and enumerates the returned fields (price in KRW, daily change, market cap, PER, PBR, 52-week range). This differentiates it from sibling tools like get_company or search_approvals, which serve different purposes.

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

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

It provides useful usage context by stating the data is real-time and advising to call again for current values. However, it does not explicitly state when to prefer this tool over siblings or when not to use it, leaving some inference to the agent.

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

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

No annotations are provided, so the description carries the behavioral burden. It discloses what the tool returns, the sector scope, and clarifies the 'AI visibility' metric. It does not mention data limitations or freshness, but for a zero-parameter aggregate read tool, this is largely sufficient.

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, front-loads the core purpose, enumerates the contents, and ends with usage guidance. Every sentence earns its place with no wasted words.

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

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

For a simple, parameterless aggregate tool with no output schema, the description gives enough to select and invoke it correctly: what it covers, what metrics it returns, and when to prefer it over company-specific tools.

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

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

There are zero parameters, so the baseline is 4. The description adds value by explaining what the no-input call will return, which is all that is needed 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 a specific resource (aggregate sector view), lists concrete contents (company counts, regulatory records, AI visibility), and explicitly distinguishes itself from one-company tools with 'rather than one company.' This makes the tool's purpose unmistakable even among 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?

It gives clear when-to-use guidance: 'Use this for questions about the sector as a whole rather than one company.' This also implies an exclusion, but it does not name sibling alternatives explicitly, so it stops short of a full 5.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It usefully reveals the breadth of sources, the nationwide rarity of MFDS_INNO records, and the pipeline nature of MFDS_TRIAL, but it does not describe what a returned record looks like, result ordering, or pagination 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 compact and front-loaded with the core purpose, followed by source enumeration and specific agency guidance. It is appropriately sized, though the 'strong signal' remark is contextual rather than strictly necessary for invocation.

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 and schema together cover the main invocation needs for a 5-parameter search tool. However, with no output schema, the description leaves return-value shape, result interpretation, and pagination unexplained, which limits completeness.

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

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

Schema coverage is 100%, so the baseline is 3 because the schema already documents all parameters. The description adds genuine value beyond the schema by explaining that MFDS_INNO is a strong signal due to only 136 existing nationwide and that MFDS_TRIAL represents pipeline data.

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

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

The description clearly identifies the tool as searching regulatory records across all indexed companies and enumerates the covered agencies and approval types. It does not explicitly contrast itself with sibling tool search_companies, but the resource type 'regulatory records' makes the distinction implicit.

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 actionable routing guidance for specific agency values, such as using MFDS_INNO for Innovative Medical Device designations and MFDS_TRIAL for pipeline trials. It gives clear context for how to narrow searches, but it does not explicitly state when to choose search_approvals over sibling tools like search_companies.

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 behavioral disclosure burden. It adds meaningful behavior beyond the schema: each result is a summary line, not full detail, and the expected follow-up action is get_company. This is useful and non-obvious from the parameters alone.

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

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

The description is compact, front-loaded with the core purpose, and every sentence contributes: what it searches, how to use it, what it returns, and what to do next. No redundant or filler content.

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

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

For a search tool with no output schema, the description covers the key missing context: result granularity and the next step for full details. It could specify what fields the summary line contains, but the follow-up guidance mitigates that gap.

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

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

Schema description coverage is 100%, so the parameters are already fully documented. The description adds marginal framing (search by name, keyword, sector, or stock exchange) but does not substantially improve on the schema's own parameter 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 uses a specific verb ('search') with a clear resource: Korean listed medical AI, biotech, medical device, pharma, and healthcare infrastructure companies. It also distinguishes itself from get_company by noting it returns summary lines and that full detail belongs elsewhere.

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 tells the agent when to use this tool ('Use this to find companies...') and provides sequencing guidance ('Call get_company afterwards for full detail'). It does not explicitly mention when to prefer siblings like search_approvals or get_stock_quote, so it stops short of a 5.

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